|
Our goal is to develop a comprehensive framework for technology-agnostic professional development within the information technology industry.
The Advanced Practice Area (APA) research focuses on the most important factor in any profession, its people. It focuses on the transformation and formalization of roles, responsibilities, and practice areas. As information systems becoming larger and more complex with a greater requirement for integration, an increased degree of specialization and optimization of the practice area model is required.
The conventional approach to information technology solutions has been technology-centric rather than solution-centric. This means that we have focused on improving technology rather than improving our use of technology. Most teams are comprised of technologists who are tied to specific technologies (i.e. JAVA, .NET, etc.) rather than designers that are focused on design-first, and then on a selective application of those technologies based upon sensible alternatives analysis principles. For example, if you ask a carpenter what kind of building you need, they will tell you a wood structure, a mason - a masonry structure, a steel worker - as steel structure, and so on. The challenge is that there are a lack of technology-agnostic information system designers.
The Advanced Practice Area (APA) model reflects more than fifteen years of research into the evolving roles and responsibilities involved in building large scale information for businesses and organizations throughout the public and private sectors.
The Advanced Practice Area (APA) Model
The Advanced Practice Area (APA) Model includes six primary practice areas.These include Managers, Architects, Engineers, Analysts, Technologies, Support. These are further categorized into professional versus technical. Briefly, these can be described as follows:
The Advanced Practice Areas
| The Practice Area |
Brief Description |
Primary Responsibilities |
Professional Practice Areas |
| Manager |
Should have extensive experience in one or more of the professional practice areas. |
Scheduling, Resource Allocation, Client Communications, and Risk Management |
| Architect |
Should have extensive training and experience regarding information systems planning, architecture, analysis, and design. |
Planning, Blueprint Development, Alternatives Analysis, Client Communications, and Risk Management |
| Engineer |
Should have extensive training and experience using design patterns, integration and data migration planning, and integration testing |
Design, Quality Assurance, Data Modeling, Data Migration, Systems Integration, and Risk Management |
| Analyst |
Should have extensive training and experience in requirements analysis, quality assurance, training, configuration management, and enterprise architecture techniques. |
Analysis, Configuration Management, Enterprise Architecture, Transition Planning, and Risk Management |
Technical Practice Areas |
| Technologist |
Should have extensive training and experience in specific technologies and unit testing, including programming, configuration, and administration in those specific technologies. |
Programming, Product Configuration, and Systems Administration |
| Support |
Should have extensive training and experience in their specific practice area and technology. Support can include testers, trainers, graphics artists, technical writers. |
Varies based upon discipline |
Disciplines Versus Practice
Disciplines further break down a practice into distinct areas of specialization within that practice. Each practice area may have one or more disciplines, and a practitioner may focus on one or more disciplines. Each discipline requires a basic level of experience and training within the practice (i.e. a doctor who is a specialist such as a surgeon, still needs to understand the basics of medicine.).
Managers and Disciplines
Management disciplines break down into project and progam management. While a project manager may focus specifically on a single project, the program manager will focus on specific functions the apply to multiple integrated projects.
Architects and Disciplines
The existence of the architect is to span disciplines and to leverage the capabilities of the other disciplines into a cohesive solution. Therefore, there are not specific disciplines for the architect. The architects primary responsibility is to ensure that a comprehensive business solution is delivered to the customer encompassing business, organizational, and environmental factors. The architects ultimate responsibilities is to ensure that the solution fulfills the needs of the business or organization, from project inception to deployment. The architects responsibility does not end until the system is officially adopted and end-user community is fully trained and supported.
Engineer and Disciplines
The disciplines within information systems engineering includes dissecting the architecture into various similar design categories based on cross-sections of an architecture. This is required to maintain the technology-agnostic approach to design that is the premise for maintaining solution flexibility and "best use" of technology during design. Through specialization, the engineer should understand how to apply service oriented architecture principles within their area of specialization. Additionally, each discipline should be able to perform comprehensive audits of design against requirements as well as the components that are produced during construction.
This groups information system engineering disciplines into six primitive groups. These groups include:
- Application Systems Engineering* - focuses on standard design patterns that application layout and flow, application rules, navigation, behavior, security, and exception handling. This discipline should include expertise in modeling both web-based and rich-client application systems. An application system, in short, includes any user-facing components of a system such as user entry, informational, or reporting systems.
- Middleware Systems Engineering* - focuses on standard design patterns that apply to middleware workflow, rules, and integration platforms. This should include a detailed understanding of integration with external systems, security, and exception handling within middleware systems. Middleware systems include non-user facing shared services that are consumed by an application system. These can include local or remote application programming interfaces (API). The middleware systems engineer must be well versed in standard application of communication protocols (i.e. HTTP, XML, SOAP, etc.).
- Data Systems Engineering* - focuses on standard data modeling practices (i.e. entity relational modeling) and data/systems migration efforts. Should be an expert in data access and transactional models. The data systems engineer must be an expert in identification of data patterns and utilization throughout all levels of a system and develop common data or object models which can be used as reference by application and middleware system engineers. In addition, the data systems engineer is responsible for identifying and preparing data samples for use in test preparation. This includes statistical and exception analysis of data populations.
- Hardware and Network Systems Engineering* - focuses on standard approaches to modeling hardware and network solutions including network and platform security (i.e. standard approaches to locking down servers and services).
* - A single cross-discipline exists regarding systems security, since each discipline requires a comprehensive understanding of security practices and principles within their domain of expertise.
Analyst and Disciplines
The disciplines within business systems analyst includes various process areas that are required to support the advanced lifecycle. The four primitive disciplines within business systems analysis include:
- Requirements Analysis - focuses on requirements elicitation through the use of standard gathering and analysis techniques such as workshops, user surveys, shadowing, or other applicable techniques. Documentation techniques can include conventional mechanisms and/or enterprise architecture (EA) approaches. In addition, use case modeling is an essential part of this discipline.
- Quality Assurance - focuses on the development of comprehensive test plans and scenarious, translation of use cases into test cases based upon data samples delivered by the data systems engineer. In addition, the quality assurance analyst must be able to perform extensive audits of requirements against the proposed design.
- Configuration Management - focuses on the management and alignment of all system related artifacts and versioning including requirements, design, code components, user materials, administration materials, and training information.
- Transition Management - focuses on the preparation of the organization for any changes resulting from the new system. This includes process re-engineering (including as-is and to-be analysis), training, and event coordination. This may involve the interrogation of "As-Is" and "To-Be" models to understand major differences in business processes and technical infrastructure and to ensure that all affected parties are properly prepared for this change.
Technologist and Disciplines
The technologists are the coders, configurations specialists, and administrators on the team. An experienced technologist may be identified as a foreman on a project, responsible for the quality and efficient delivery of build components.
- Programming - focuses on programming related processes, approaches, and technologies used in the development of information systems. These include indepth knowledge of programming languages such as JAVA, C#, C, VB, SQL and others.
- Product Configuration - focuses on specific 3rd party technology platforms. These platforms may include products provided by industry vendors such as Oracle, Microsoft, Sun, BEA, or others.
- Administration - focuses on the administration of operating systems and technology platforms, including user administration, service optimization, etc.
Support Disciplines
The support staff are the individuals that put the final touches on documents, systems references, system interfaces and other activities that result in greater receival of the system into its final environment. This can include individuals such as graphics artists, testers, technical writers, trainers or other specialist that provide specific capabilities to a project team.
|