This is a generic process which will enable Enterprise Architects to create composite information systems views.
The purpose of Phase A-C-C is to develop an Information Systems view which is a composite architecture drawn from the Business, Data, and Applications Architecture views. The resultant composite view is intended to meet specific business needs.
For example, the Information Architecture is drawn from the Data Architecture in a business context and is a view of the enterprise architecture.
The process can be applied when there is no specific set of building blocks available to create the composite view.
The objective of Phase A-C-C is to develop the combination views and viewpoints of the business and information systems to be able to create a unique architecture to meet business needs. For example:
Security Architecture
Knowledge Management Architecture
To re-use the building blocks from the Business, Data, and Applications Architecture views to create composite building blocks so that a library of open source specifications can be built.
INSERT NEW GRAPHIC HERE
The process steps will include:
- Information Architecture view
- Knowledge Architecture view
- Security Architecture view, etc.
Architecture View Baseline Description: Develop a Baseline Description of the existing architecture, to the extent necessary to support the Target Architecture. The scope and level of detail to be defined will depend on the extent to which existing components are likely to be carried over into the Target Architecture, and on whether existing architectural descriptions exist. Define for each architecture view:
Name (short and long)
Who maintains
Owner(s)/business unit(s) responsible for requirements
Other users
Plain language description of what the architecture view does (not how it does it)
Status (planned, operational, obsolete)
Business functions supported
Organizational units supported
Hardware/software platform(s) on which it runs
Networks used
Precedent and successor architecture views
To the extent possible, identify the relevant Architecture Building Blocks, drawing on the Architecture Continuum.
Principles, Reference Models, Viewpoints, and Tools:
Review and validate (or generate, if necessary) the set of Application Principles.
These will normally form part of an overarching set of Architecture Principles. Guidelines for developing and applying principles are given in Book 3: Architecture Principles.
Select relevant architecture view resources (reference models, patterns, etc.) from the Architecture Continuum, on the basis of the business drivers, and the stakeholders and concerns.
Select relevant architecture viewpoints (for example, stakeholders - viewpoints relevant to functional and individual users of the architecture view, Software Engineering view, Application-to-Application Communication view, Software Distribution view, Enterprise Manageability view, etc.); i.e., those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the architecture view.
Identify appropriate tools and techniques to be used for capture, modeling, and analysis, in association with the selected viewpoints. Depending on the degree of sophistication warranted, these may comprise simple documents or spreadsheets, or more sophisticated modeling tools and techniques.
Consider using platform-independent descriptions of business logic. For example, the OMG's Model-Driven Architecture (MDA) offers an approach to modeling architectures that preserves the business logic from changes to the underlying platform and implementation technology.
Architecture Model(s):
For each viewpoint, create the model for the specific view required, using the selected tool or method.
Assure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models (see above).
** In following text, replace "application" with "view" - NOT DONE. **
Relate the application systems to the business functions in the Business Architecture.
For each application, identify each lowest-level business function that it supports in the Business Architecture.
Generate application-business function matrices tabulating all the relationships.
Review and validate the application-business function matrices. In cases where a business function is supported by more than one application, check for any unnecessary duplication of functionality (and if found, eliminate it by redefining the applications concerned).
Identify any business functions not supported by an application, and rationalize: either provide application support by amending or updating the set of application definitions, iterating Steps 1 to 3; or else document the reason why no application support is warranted.
Use the application-business function matrices generated above, and the business function-to-organizational-unit mappings (business functions cross-linked to the organizational units that perform them) contained in the Business Architecture, to relate the application systems to the organizational units that they support.
Ensure that all information requirements in the Business Architecture are met.
Perform trade-off analysis to resolve conflicts (if any) among the different views.
One method of doing this is CMU/SEI's Architecture Trade-off Analysis (ATA) Method (refer to www.sei.cmu.edu/ata/ata_method.html).
Validate that the models support the principles, objectives, and constraints.
Note changes to the viewpoint represented in the selected models from the Architecture Continuum, and document.
Test architecture models for completeness against requirements.
Identify candidate application systems:
Review the re-usable Architecture Building Blocks and re-usable Solution Building Blocks from the enterprise's Architecture Continuum, the Business Scenario description, and the Baseline Description, and list all the potential application systems.
If available, review the entity-to-business-function matrices from the Data Architecture, and identify potential applications to perform the required data management functions, and/or to automate particular business functions.
Even if a complete Data Architecture is not available, review whatever lists of data exist.
Develop a user location/applications matrix.
Brainstorm other potential application systems based on innovative use of new developments in technology.
Merge all lists into a single, de-duplicated list of candidate application systems, including for each a brief description of business function(s) supported and data/information managed.
Create application definitions for all candidate application systems. For each application:
Assign a unique name and identifier.
Write a brief description of what the application does (not how it works).
Write a brief description of the business benefits arising from the application.
Simplify complicated applications by decomposing them into two or more applications.
Ensure that the set of application definitions is internally consistent, by removing duplicate functionality as far as possible, and combining similar applications into one.
Identify technology requirements and candidate technology building blocks, where this affects the applications design, including re-usable solution building blocks from the Architecture Continuum, and external software packages.
Identify any critical infrastructure dependencies (e.g., operating system and network services required).
Identify any critical application dependencies, and minimize as far as possible.
Time permitting, relate the applications to the files and databases described in the Baseline Description, and/or to the data entities defined in the Data Architecture (if available).
Time permitting, draw simple diagrams to illustrate views of the Applications Architecture relevant to different stakeholders.
Conduct a formal checkpoint review of the architecture model and building blocks with stakeholders.
Review the application-business function matrices generated in Step 3, and the Business Architecture generated in Phase A-B.
Review the qualitative criteria (e.g., security, availability, performance, costs), providing as many measurable criteria as possible (e.g., privacy/confidentiality, reliability, minimum tolerable outages, cycle requirements and transaction volume requirements at peak and mean times, numbers and locations of users, etc.). Use to specify required service levels for applications services (for example, via formal Service Level Agreements (SLAs)).
The goal here is to guide the Data and Technology Architecture efforts as to the qualities required in the data, and the underlying technology, that support and are processed by the application.
Complete the Architecture View:
Select standards for each of the Architecture Building Blocks, re-using as much as possible from the reference models selected from the Architecture Continuum.
Fully document each Architecture Building Block.
Final cross-check of overall architecture against business requirements. Document rationale for building block decisions in architecture document.
Document final requirements traceability report.
Document final mapping of the architecture within the Architecture Continuum. From the selected Architecture Building Blocks, identify those that might be re-used, and publish via the architecture repository.
Document rationale for building block decisions in architecture document.
Prepare Architecture View Report. Generate the Architecture View document. If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the Architecture View document for review by relevant stakeholders, and incorporate feedback.
Checkpoint/Impact Analysis: Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Architecture View. Conduct an Impact Analysis to:
Identify any areas where the Business Architecture (e.g., business practices) may need to change to cater for changes in the Architecture View (for example, changes to forms or procedures, application systems, or database systems).
If the impact is significant, this may warrant the Business Architecture being revisited.
Identify any areas where the Data Architecture (if generated at this point) may need to change to cater for changes in the Architecture View (or to identify constraints on the Data Architecture, if about to be designed).
If the impact is significant, this may warrant the Data Architecture being revisited, if already developed in this cycle.
Identify any constraints on the Technology Architecture about to be designed.
Refine the proposed Architecture View only if necessary.
Gap Analysis and report:
Create gap matrix as described above.
Identify building blocks to be carried over, classifying as either changed or unchanged.
Identify eliminated building blocks.
Identify new building blocks.
Identify gaps and classify as those that should be developed and those inherited.
Add applications architecture process model here - new material.