Views by MSA Section

Architecture Phase: Conceptual
MSA Section View TOGAF Phase Security related? Mandatory Description
1.1.1 Stakeholders and their Concerns Stakeholder Catalogue Phase A - Architecture Vision No The purpose of the Stakeholder catalog is to identify the stakeholders for the architecture engagement, their influence over the engagement, and their key questions, issues, or concerns that must be addressed by the architecture framework. Understanding stakeholders and their requirements allows an architect to focus effort in areas that meet the needs of stakeholders (see the TOGAF Standard — ADM Techniques). Due to the potentially sensitive nature of stakeholder mapping information and the fact that the Architecture Vision phase is intended to be conducted using informal modeling techniques, no specific metamodel entities will be used to generate a Stakeholder catalog.
1.1.2 Problem Analysis Business Model Diagram Phase A - Architecture Vision No No A model describing the rationale for how an enterprise creates, delivers, and captures value. Business Capability Map A diagram that shows the business capabilities that an enterprise needs to meet its purposes.
1.2.4 Detailed Objectives (Desired Outcomes) Detailed Objectives analysis/capture Phase A - Architecture Vision No No
1.3.1 Architecture Scope Architecture Scope analysis/capture Phase A - Architecture Vision No Yes
1.3.2 Solution Concept Diagram Solution Concept Diagram Phase A - Architecture Vision No Yes A Solution Concept diagram provides a high-level orientation of the solution that is envisaged in order to meet the objectives of the architecture engagement. In contrast to the more formal and detailed architecture diagrams developed in the following phases, the solution concept represents a "pencil sketch" of the expected solution at the outset of the engagement. This diagram may embody key objectives, requirements, and constraints for the engagement and also highlight work areas to be investigated in more detail with formal architecture modeling. Its purpose is to quickly on-board and align stakeholders for a particular change initiative, so that all participants understand what the architecture engagement is seeking to achieve and how it is expected that a particular solution approach will meet the needs of the enterprise.
1.3.3 Architecture Principles Principles Catalog Requirements Yes No The Principles catalog captures principles of the Business and Architecture Principles that describe what a "good" solution or architecture should look like. Principles are used to evaluate and agree an outcome for architecture decision points. Principles are also used as a tool to assist in architectural governance of change initiatives. The Principles catalog contains the following metamodel entities: Principle
1.3.4 Constraints Application Portfolio Catalog Phase A - Architecture Vision No Yes The purpose of this catalog is to identify and maintain a list of all the applications in the enterprise. This list helps to define the horizontal scope of change initiatives that may impact particular kinds of applications. An agreed Application Portfolio allows a standard set of applications to be defined and governed. The Application Portfolio catalog provides a foundation on which to base the remaining matrices and diagrams. It is typically the start point of the Application Architecture phase. The Application Portfolio catalog contains the following metamodel entities: Application Service Logical Application Component Physical Application Component
1.3.5 Policies and Standards Technology Standards Catalog Phase A - Architecture Vision Yes Yes The Technology Standards catalog documents the agreed standards for technology across the enterprise covering technologies, and versions, the technology lifecycles, and the refresh cycles for the technology. Depending upon the organization, this may also include location or business domain-specific standards information. This catalog provides a snapshot of the enterprise standard technologies that are or can be deployed, and also helps identify the discrepancies across the enterprise. The Technology Standards catalog contains the following metamodel entities: Technology Service Logical Technology Component Physical Technology Component If technology standards are currently in place, apply these to the Technology Portfolio catalog to gain a baseline view of compliance with technology standards.
1.3.6 Architecture Summary Location Catalogue Phase B - Business Architecture Yes Yes The Location catalogue provides a listing of all locations where an enterprise carries out business operations or houses architecturally relevant assets, such as data centers or end-user computing equipment. Maintaining a definitive list of locations allows change initiatives to quickly define a location scope and to test for completeness when assessing current landscapes or proposed target solutions. For example, a project to upgrade desktop operating systems will need to identify all locations where desktop operating systems are deployed. Similarly, when new systems are being implemented a diagram of locations is essential in order to develop appropriate deployment strategies that comprehend both user and application location and identify location-related issues, such as internationalization, localization, time zone impacts on availability, distance impacts on latency, network impacts on bandwidth, and access. The Location catalogue contains the following metamodel entities: Location
1.3.7 Requirements Mapped to Target Architecture Requirements Target Architecture mapping analysis/capture Yes No
1.4 Architecture Decisions Scope phase architecture decisions analysis/capture Phase A - Architecture Vision No No
1.5 Risks, Issues, Assumptions and Dependencies Scope phase risk/issues/dependencies/assumptions analysis/capture Phase A - Architecture Vision No Yes
2.1 Mapping to Architecture Repository Architecture Repository analysis/capture Requirements No No
2.1.1 Artifacts Business Glossary Catalog Requirements No No
2.2 Baseline Architecture Baseline Architecture views analysis/capture Phase A - Architecture Vision No No
Reference Value Stream/Capability Matrix Phase A - Architecture Vision No The purpose of this matrix is to show the capabilities required to support each stage of a value stream.
1.2.3 Change Drivers and Opportunities Change drivers and opportunities analysis/capture Phase A - Architecture Vision No No Creation of content for the Master Solution Architecture that is not specifically related to sections that have views associated with them.
1.2.1 Business Vision Statement Driver/Goal/Objective Catalog Phase B - Business Architecture No The purpose of the Driver/Goal/Objective catalog is to provide a cross-organizational reference of how an organization meets its drivers in practical terms through goals, objectives, and (optionally) measures. Publishing a definitive breakdown of drivers, goals, and objectives allows change initiatives within the enterprise to identify synergies across the organization (e.g., multiple organizations attempting to achieve similar objectives), which in turn allow stakeholders to be identified and related change initiatives to be aligned or consolidated. The Driver/Goal/Objective catalog contains the following metamodel entities: Organization Unit Driver Goal Objective Measure (may optionally be included)
1.2.2 Business Vision Diagram Goal/Objective/Business Service Diagram Phase A - Architecture Vision No No The purpose of a Goal/Objective/Business Service diagram is to define the ways in which a business service contributes to the achievement of a business vision or strategy. Business services are associated with the drivers, goals, objectives, and measures that they support, allowing the enterprise to understand which business services contribute to similar aspects of business performance. The Goal/Objective/Business Service diagram also provides qualitative input on what constitutes high performance for a particular business service.
3.1 Conceptual Requirements Summary (Conceptual) Architecture Requirements analysis/capture Requirements No Yes Analysis / capture requirements from conceptual phase of architecture development
Architecture Phase: Logical
MSA Section View TOGAF Phase Security related? Mandatory Description
2.4 Gap Analysis Solution Options Report Requirements No The purpose of this section is to define the gap between the current (as-is) and target (to-be) state business architectures. Mandatory/optional: This section is optional as not all the domain teams need to produce a business architecture for their respective domains. However, it can also be used by the domains that do not produce a full (current and target) or current state business architecture but still want to know the (priority) areas on which to concentrate, and thus minimise effort. In terms of quality criteria, this section should make clear: • Description of the gap between the current (as-is) and target (to-be) state business architectures. This difference, or delta, defines the scope of work that needs to be undertaken in order to transition from the current to the target business architecture. This scope is thus the scope of the program(s) or project(s) that need to be completed in order to reach the target business architecture. The suggested steps are as follows: • Draw up a matrix with all the Architecture Building Blocks (ABBs) of the baseline architecture on the vertical axis, and all the ABBs of the target architecture on the horizontal axis. • Add to the baseline architecture axis a final row labeled ‘‘New’’, and to the target architecture axis a final column labeled ‘‘Eliminated’’. • Where an ABB is available in both the baseline and target architectures, record this with ‘‘Included’’ at the intersecting cell. • Where an ABB from the baseline architecture is missing in the target architecture, each must be reviewed. If it was correctly eliminated, mark it as such in the appropriate ‘‘Eliminated’’ cell. If it was not, an accidental omission in the target architecture has been uncovered that must be addressed by reinstating the ABB in the next iteration of the architecture design – mark it as such in the appropriate ‘‘Eliminated’’ cell. • Where an ABB from the target architecture cannot be found in the baseline architecture, mark it at the intersection with the ‘‘New’’ row as a gap that needs to filled, either by developing or procuring the building block. When the exercise is complete, anything under ‘‘Eliminated’’ or ‘‘New’’ is a gap, which should either be explained as correctly eliminated, or marked as to be addressed by reinstating or developing/procuring the function. Potential sources of gaps include: • Business domain gaps: o People gaps (e.g., cross-training requirements) o Process gaps (e.g., process inefficiencies) o Tools gaps (e.g., duplicate or missing tool functionality) o Information gaps o Measurement gaps o Financial gaps o Facilities gaps (buildings, office space, etc.) • Data domain gaps: o Data not of sufficient currency o Data not located where it is needed o Not the data that is needed o Data not available when needed o Data not created o Data not consumed o Data relationship gaps • Applications impacted, eliminated, or created • Technology impacted, eliminated, or created
3.2 Logical Requirements Summary (Logical) Architecture Requirements analysis/capture Requirements No Yes Update of Architecture requirements at end of Logical architecture development
Architecture Phase: Physical
MSA Section View TOGAF Phase Security related? Mandatory Description
2.3.1 Business Architecture Models Process/Event/Control/Product Catalog Phase B - Business Architecture No The Process/Event/Control/Product catalog provides a hierarchy of processes, events that trigger processes, outputs from processes, and controls applied to the execution of processes. This catalog provides a supplement to any Process Flow diagrams that are created and allows an enterprise to filter, report, and query across organizations and processes to identify scope, commonality, or impact. For example, the Process/Event/Control/Product catalog allows an enterprise to see relationships of processes to sub-processes in order to identify the full chain of impacts resulting from changing a high-level process. The Process/Event/Control/Product catalog contains the following metamodel entities: Process Event Control Product
2.3.2 Data Architecture Models Data Migration Diagram Phase C - Information Architecture No No This diagram shows how data is extracted from baseline or source location(s) and loaded into target location(s). It may show where data is transformed and/or cleansed on the way. In Phase C of the ADM, the diagram is likely to be at an overview level. Later, it may be elaborated to show which source data items map to which target data items.
2.3.3 Application Architecture Models Application and User Location Diagram Phase C - Application Architecture Yes Yes The Application and User Location diagram shows the geographical distribution of applications. It can be used to show where applications are used by the end user; the distribution of where the host application is executed and/or delivered in thin client scenarios; the distribution of where applications are developed, tested, and released; etc. Analysis can reveal opportunities for rationalization, as well as duplication and/or gaps. The purpose of this diagram is to clearly depict the business locations from which business users typically interact with the applications, but also the hosting location of the application infrastructure. The diagram enables: Identification of the number of package instances needed to sufficiently support the user population that may be spread out geographically Estimation of the number and type of user licenses for the package or other software Estimation of the level of support needed for the users and the location of the support center Selection of system management tools, structure, and management system required to support the enterprise users/customers/partners both locally and remotely Appropriate planning for the technological components of the business, namely server sizing and network bandwidth, etc. Performance considerations while implementing application and technology architecture solutions Users typically interact with applications in a variety of ways; for example: To support the operations of the business day-to-day To participate in the execution of a business process To access information (look-up, read) To develop the application To administer and maintain the application
2.3.4 Technology Architecture Models Network and Communications Diagram Phase D - Technology Architecture Yes Yes The Network and Communications diagram describes the means of communication — the method of sending and receiving information — between these assets in the Technology Architecture; insofar as the selection of package solutions in the preceding architectures put specific requirements on the communications between the applications. The Network and Communications diagram will take logical connections between client and server components and identify network boundaries and network infrastructure required to physically implement those connections. It does not describe the information format or content but will address protocol and capacity issues.
3.3 Physical Requirements Summary (Physical) Architecture Requirements analysis/capture Requirements No Yes Update of Architecture requirements at end of Physical architecture development to support creation of solution implementation work packages.
Architecture Phase: Contextual
MSA Section View TOGAF Phase Security related? Mandatory Description
2.1.3 Mapping to Reference Models Principles Catalogue No Yes The Principles catalog captures principles of the Business and Architecture Principles that describe what a "good" solution or architecture should look like. Principles are used to evaluate and agree an outcome for architecture decision points. Principles are also used as a tool to assist in architectural governance of change initiatives. The Principles catalog contains the following metamodel entities: Principle