Views by MSA Section
| 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 | 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.1.2 Problem Analysis | Strategy/Capability Matrix | Phase A - Architecture Vision | No | The purpose of this matrix is to show the capabilities required to support specific strategy statements. | |
| 1.1.2 Problem Analysis | Business Capability Map | Phase A - Architecture Vision | No | No | |
| 1.1.2 Problem Analysis | Capability/Organization Matrix | Phase A - Architecture Vision | No | No | The purpose of this matrix is to show the organization elements that implement each capability. The Capability/Organization matrix includes the following metamodel entities: Business Capability Value Stream Organization Unit |
| 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 | Business Footprint Diagram | Phase B - Business Architecture | No | A Business Footprint diagram describes the links between business goals, organizational units, business functions, and services, and maps these functions to the technical components delivering the required capability. A Business Footprint diagram provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified. A Business Footprint diagram demonstrates only the key facts linking organization unit functions to delivery services and is utilized as a communication platform for senior-level (CxO) stakeholders. | |
| 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 | Technology Portfolio Catalog | Phase D - Technology Architecture | Yes | The purpose of this catalog is to identify and maintain a list of all the technology in use across the enterprise, including hardware, infrastructure software, and application software. An agreed technology portfolio supports the lifecycle management of technology products and versions and also forms the basis for the definition of technology standards. The Technology Portfolio catalog provides a foundation on which to base the remaining matrices and diagrams. It is typically the start point of the Technology Architecture phase. Technology registries and repositories also provide input into this catalog from a baseline and target perspective. Technologies in the catalog should be classified against the defined taxonomy in use in the enterprise, such as the TOGAF TRM — see the TOGAF® Series Guide: The TOGAF® Technical Reference Model (TRM) — adapted as necessary to fit the classification of technology products in use. The Technology Portfolio catalog contains the following metamodel entities: Technology Service Logical Technology Component Physical Technology Component | |
| 1.3.4 Constraints | Non-Functional Requirements | Requirements | Yes | Yes | Catalogue of non-functional (quality) requirements to be considered. NFRs |
| 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 | Business Use-Case Diagram | Phase B - Business Architecture | No | A Business Use-Case diagram displays the relationships between consumers and providers of business services. Business services are consumed by actors or other business services and the Business Use-Case diagram provides added richness in describing business capability by illustrating how and when that capability is used. The purpose of the Business Use-Case diagram is to help to describe and validate the interaction between actors and their roles to processes and functions. As the architecture progresses, the use-case can evolve from the business level to include data, application, and technology details. Architectural business use-cases can also be re-used in systems design work. | |
| 1.3.6 Architecture Summary | Organization Decomposition Diagram | Phase B - Business Architecture | No | An Organization Decomposition diagram describes the links between actor, roles, and location within an organization tree. An organization map should provide a chain of command of owners and decision-makers in the organization. Although it is not the intent of the Organization Decomposition diagram to link goal to organization, it should be possible to intuitively link the goals to the stakeholders from the Organization Decomposition diagram. | |
| 1.3.6 Architecture Summary | Data Entity/Business Function Matrix | Phase C - Information Architecture | Yes | No | The purpose of the Data Entity/Business Function matrix is to depict the relationship between data entities and business functions within the enterprise. Business functions are supported by business services with explicitly defined boundaries and will be supported and realized by business processes. The mapping of the Data Entity-Business Function relationship enables the following to take place: Assign ownership of data entities to organizations Understand the data and information exchange requirements business services Support the gap analysis and determine whether any data entities are missing and need to be created Define application of origin, application of record, and application of reference for data entities Enable development of data governance programs across the enterprise (establish data steward, develop data standards pertinent to the business function, etc.) The Data Entity/Business Function matrix shows the following entities and relationships: Data Entity Business Function Data Entity relationship to owning Organization Unit |
| 1.3.6 Architecture Summary | Business Service/Function Catalog | Phase B - Business Architecture | Yes | Yes | The purpose of the Business Service/Function catalog is to provide a functional decomposition in a form that can be filtered, reported on, and queried, as a supplement to graphical Functional Decomposition diagrams. The Business Service/Function catalog can be used to identify capabilities of an organization and to understand the level that governance is applied to the functions of an organization. This functional decomposition can be used to identify new capabilities required to support business change or may be used to determine the scope of change initiatives, applications, or technology components. The Business Service/Function catalog contains the following metamodel entities: Organization Unit Business Function Business Service Application Service (may optionally be included here) |
| 1.3.6 Architecture Summary | Business Service/Information Diagram | Phase B - Business Architecture | Yes | Yes | The Business Service/Information diagram shows the information needed to support one or more business services. The Business Service/Information diagram shows what data is consumed by or produced by a business service and may also show the source of information. The Business Service/Information diagram shows an initial representation of the information present within the architecture and therefore forms a basis for elaboration and refinement within Phase C (Data Architecture). TOGAF ref |
| 1.3.6 Architecture Summary | Conceptual Data Diagram | Phase C - Information Architecture | Yes | Yes | The key purpose of the Conceptual Data diagram/Information Structure View is to depict the relationships between critical data entities within the enterprise. This diagram is developed to address the concerns of business stakeholders. Refer to DoE Conceptual Information Asset Model (16/489129) and develop project specific view. This view also needs to be included as part of the Information Security Assessment (ISA) |
| 1.3.6 Architecture Summary | Role Catalog | Phase B - Business Architecture | Yes | Yes | The purpose of the Role catalog is to provide a listing of all authorization levels or zones within an enterprise. Frequently, application security or behavior is defined against locally understood concepts of authorization that create complex and unexpected consequences when combined on the user desktop. If roles are defined, understood, and aligned across organizations and applications, this allows for a more seamless user experience and generally more secure applications, as administrators do not need to resort to workarounds in order to enable users to carry out their jobs In addition to supporting security definition for the enterprise, the Role catalog also forms a key input to identifying organizational change management impacts, defining job functions, and executing end-user training. As each role implies access to a number of business functions, if any of these business functions are impacted then change management will be required, organizational responsibilities may need to be redefined, and retraining may be needed. The Role catalog contains the following metamodel entities: Role |
| 1.3.6 Architecture Summary | Functional Decomposition Diagram | Phase B - Business Architecture | No | Yes | The purpose of the Functional Decomposition diagram is to show on a single page the capabilities of an organization that are relevant to the consideration of an architecture. By examining the capabilities of an organization from a functional perspective, it is possible to quickly develop models of what the organization does without being dragged into extended debate on how the organization does it. Once a basic Functional Decomposition diagram has been developed, it becomes possible to layer heat maps on top of this diagram to show scope and decisions. For example, the capabilities to be implemented in different phases of a change program. |
| 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 Catalog | Phase A - Architecture Vision | No | A listing of end-to-end collections of value-adding activities that create an overall result for a customer, stakeholder, or end user. | |
| Reference | Business Capabilities Catalog | Phase A - Architecture Vision | No | A listing of abilities that a business may possess to achieve specific purposes. | |
| Reference | Value Stream Stages Catalog | Phase A - Architecture Vision | No | A listing of end-to-end collections of the different stages for the value-adding activities that create an overall result for customer, stakeholder, or end user. The Value Stream Stages catalog includes the following metamodel entities: Business Capability Value Stream | |
| 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 | Value Stream Map | Phase A - Architecture Vision | No | A diagram representing an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user. The value stream map includes the following metamodel entities: Business Capability Value Stream | |
| 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 |
| MSA Section | View | TOGAF Phase | Security related? | Mandatory | Description |
|---|---|---|---|---|---|
| 2.3.1 Business Architecture Models | Product Lifecycle Diagram | Phase B - Business Architecture | No | This diagram shows the possible state transitions of a business product, from its creation or receipt to its sale, disposal, or destruction. The product may be a product of any kind (physical, software, or service). | |
| 2.3.1 Business Architecture Models | Business Event Diagram | Phase B - Business Architecture | No | The purpose of the Business Event diagram is to depict the relationship between events and process. Certain events — such as arrival of certain information (e.g., customer submits sales order) or a certain point in time (e.g., end of fiscal quarter) — cause work and certain actions need to be undertaken within the business. These are often referred to as "business events" or simply "events" and are considered as triggers for a process. It is important to note that the event has to trigger a process and generate a business response or result. | |
| 2.3.1 Business Architecture Models | Business Interaction Matrix | Phase B - Business Architecture | No | The purpose of this matrix is to depict the relationship interactions between organizations and business functions across the enterprise. Understanding business interaction of an enterprise is important as it helps to highlight value chain and dependencies across organizations. The Business Interaction matrix shows the following metamodel entities and relationships: Organization Business Function Business Service Business Service communicates with Business Service relationships Business Service is dependent on Business Service relationships | |
| 2.3.1 Business Architecture Models | Process Flow Diagram | Phase B - Business Architecture | Yes | No | The purpose of the Process Flow diagram is to depict all models and mappings related to the process metamodel entity. Process Flow diagrams show sequential flow of control between activities and may utilize swim-lane techniques to represent ownership and realization of process steps. For example, the application that supports a process step may be shown as a swim-lane. In addition to showing a sequence of activity, process flows can also be used to detail the controls that apply to a process, the events that trigger or result from completion of a process, and also the products that are generated from process execution. Process Flow diagrams are useful in elaborating the architecture with subject specialists, as they allow the specialist to describe "how the job is done" for a particular function. Through this process, each process step can become a more fine-grained function and can then in turn be elaborated as a process. |
| 2.3.1 Business Architecture Models | Actor/Role Matrix | Phase B - Business Architecture | Yes | Yes | The purpose of this matrix is to show which actors perform which roles, supporting definition of security and skills requirements. Understanding Actor-to-Role relationships is a key supporting tool in definition of training needs, user security settings, and organizational change management. The Actor/Role matrix shows the following metamodel entities and relationships: Actor Role Actor performs Role relationships |
| 2.3.1 Business Architecture Models | Contract/Measure Catalog | Phase B - Business Architecture | Yes | Yes | The Contract/Measure catalog provides a listing of all agreed service contracts and the measures attached to those contracts. It forms the master list of service levels agreed to across the enterprise. The Contract/Measure catalog contains the following metamodel entities: Business Service Application Service (optionally) Contract Measure |
| 2.3.2 Data Architecture Models | Data Entity/Data Component Catalog | Phase C - Information Architecture | Yes | This catalog identifies and maintains a list of the data used across the enterprise, relating data entities to data components showing how data entities are structured. Its purpose is to: Identify all data used in the enterprise Encourage effective data use The Data Entity/Data Component catalog contains the following metamodel entities: Data Entity Logical Data Component Physical Data Component | |
| 2.3.2 Data Architecture Models | Logical Data Diagram | Phase C - Information Architecture | Yes | The key purpose of the Logical Data diagram is to show logical views of the relationships between critical data entities within the enterprise. This diagram is developed to address the concerns of: Application developers Database designers | |
| 2.3.2 Data Architecture Models | Application/Data Matrix | Phase C - Information Architecture | Yes | Yes | The purpose of the Application/Data matrix is to depict the relationship between applications (i.e., application components) and the data entities that are accessed and updated by them. Applications will create, read, update, and delete specific data entities that are associated with them. For example, a Customer Relationship Management (CRM) application will create, read, update, and delete customer entity information. The data entities in a package/packaged services environment can be classified as master data, reference data, transactional data, content data, and historical data. Applications that operate on the data entities include transactional applications, information management applications, and business warehouse applications. The mapping of the Application Component-Data Entity relationship is an important step as it enables the following to take place: Assign access of data to specific applications in the organization Understand the degree of data duplication within different applications, and the scale of the data lifecycle Understand where the same data is updated by different applications Support the gap analysis and determine whether any of the applications are missing and as a result need to be created The Application/Data matrix is a two-dimensional table with Logical Application Component on one axis and Data Entity on the other axis. |
| 2.3.2 Data Architecture Models | Data Lifecycle Diagram | Phase C - Information Architecture | Yes | No | The Data Lifecycle diagram is an essential part of managing business data throughout its lifecycle from conception until disposal within the constraints of the business process. The data is considered as an entity in its own right, decoupled from business process and activity. Each change in state is represented on the diagram which may include the event or rules that trigger that change in state. The separation of data from process allows common data requirements to be identified which enables resource sharing to be achieved more effectively. |
| 2.3.2 Data Architecture Models | Data Security Diagram | Phase C - Information Architecture | No | Yes | This diagram shows which data is accessed by which roles, organization units, and applications. It may be shown as a diagram or presented as a matrix. Its purpose is to: Demonstrate compliance with data privacy laws and regulations Show security threats arising as a result of data access Show which parties outside of the organization have access to data Show security measures applied to data access |
| 2.3.3 Application Architecture Models | Enterprise Manageability Diagram | Phase C - Application Architecture | No | The Enterprise Manageability diagram shows how one or more applications interact with application and technology components that support the operational management of a solution. This diagram is really a filter on the Application Communication diagram, specifically for enterprise management class software. Analysis can reveal duplication and gaps, and opportunities in the IT service management operation of an organization. Example | |
| 2.3.3 Application Architecture Models | Role/Application Matrix | Phase C - Application Architecture | Yes | The purpose of the Role/Application matrix is to depict the relationship between applications and the business roles that use them within the enterprise. People in an organization interact with applications. During this interaction, these people assume a specific role to perform a task; for example, product buyer. The mapping of the Application Component-Role relationship is an important step as it enables the following to take place: Assign usage of applications to the specific roles in the organization Understand the application security requirements of the business services and processes supporting the function, and check these are in line with current policy Support the gap analysis and determine whether any of the applications are missing and as a result need to be created Define the application set used by a particular business role; essential in any move to role-based computing The Role/Application matrix is a two-dimensional table with Logical Application Component on one axis and Role on the other axis. | |
| 2.3.3 Application Architecture Models | Software Engineering Diagram | Phase C - Application Architecture | No | The Software Engineering diagram breaks applications into packages, modules, services, and operations from a development perspective. It enables more detailed impact analysis when planning migration stages, and analyzing opportunities and solutions. It is ideal for application development teams and application management teams when managing complex development environments. | |
| 2.3.3 Application Architecture Models | Application/Function Matrix | Phase C - Application Architecture | No | The purpose of the Application/Function matrix is to depict the relationship between applications and business functions within the enterprise. Business functions are performed by organizational units. Some of the business functions and services will be supported by applications. The mapping of the Application Component-Function relationship is an important step as it enables the following to take place: Assign usage of applications to the business functions that are supported by them Understand the application support requirements of the business services and processes carried out Support the gap analysis and determine whether any of the applications are missing and as a result need to be created Define the application set used by a particular business function The Application/Function matrix is a two-dimensional table with Logical Application Component on one axis and Function on the other axis. The relationship between these two entities is a composite of a number of metamodel relationships that need validating: Function is bounded by Service Services are realized by Logical/Physical Application Components | |
| 2.3.3 Application Architecture Models | Application Use-Case Diagram | Phase C - Application Architecture | No | An Application Use-Case diagram displays the relationships between consumers and providers of application services. Application services are consumed by actors or other application services and the Application Use-Case diagram provides added richness in describing application functionality by illustrating how and when that functionality is used. The purpose of the Application Use-Case diagram is to help to describe and validate the interaction between actors and their roles with applications. As the architecture progresses, the use-case can evolve from functional information to include technical realization detail. Application use-cases can also be re-used in more detailed systems design work. | |
| 2.3.3 Application Architecture Models | Application Communication Diagram | Phase C - Application Architecture | Yes | Yes | The purpose of the Application Communication diagram is to depict all models and mappings related to communication between applications in the metamodel entity. It shows application components and interfaces between components. Interfaces may be associated with data entities where appropriate. Applications may be associated with business services where appropriate. Communication should be logical and should only show intermediary technology where it is architecturally relevant. |
| 2.3.3 Application Architecture Models | Application Interaction Matrix | Phase C - Application Architecture | Yes | Yes | The purpose of the Application Interaction matrix is to depict communications relationships between applications. The mapping of the application interactions shows in matrix form the equivalent of the Interface Catalog or an Application Communication diagram. The Application Interaction matrix is a two-dimensional table with Application Service, Logical Application Component, and Physical Application Component on both the rows and the columns of the table. The relationships depicted by this matrix include: Application Service consumes Application Service Logical Application Component communicates with Logical Application Component Physical Application Component communicates with Physical Application Component |
| 2.3.3 Application Architecture Models | Process-Application Realisation | Phase C - Application Architecture | No | No | The purpose of the Process/Application Realization diagram is to clearly depict the sequence of events when multiple applications are involved in executing a business process. It enhances the Application Communication diagram by augmenting it with any sequencing constraints, and hand-off points between batch and real-time processing. It would identify complex sequences that could be simplified, and identify possible rationalization points in the architecture in order to provide more timely information to business users. It may also identify process efficiency improvements that may reduce interaction traffic between applications. |
| 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 |
| MSA Section | View | TOGAF Phase | Security related? | Mandatory | Description |
|---|---|---|---|---|---|
| 2.3.1 Business Architecture Models | Organization/Actor Catalog | Phase B - Business Architecture | No | The purpose of the Organization/Actor catalog is to capture a definitive listing of all participants that interact with IT, including users and owners of IT systems. The Organization/Actor catalog can be referenced when developing requirements in order to test for completeness. For example, requirements for an application that services customers can be tested for completeness by verifying exactly which customer types need to be supported and whether there are any particular requirements or restrictions for user types. The Organization/Actor catalog contains the following metamodel entities: Organization Unit Actor Location (may be included in this catalog if an independent Location catalog is not maintained) | |
| 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 Dissemination Diagram | Phase C - Information Architecture | Yes | Yes | The purpose of the Data Dissemination diagram is to show the relationship between data entity, business service, and application components. The diagram shows how the logical entities are to be physically realized by application components. This allows effective sizing to be carried out and the IT footprint to be refined. Moreover, by assigning business value to data, an indication of the business criticality of application components can be gained. Additionally, the diagram may show data replication and application ownership of the master reference for data. In this instance, it can show two copies and the master-copy relationship between them. This diagram can include services; that is, services encapsulate data and they reside in an application, or services that reside on an application and access data encapsulated within the application. |
| 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 Migration Diagram | Phase C - Application Architecture | No | The Application Migration diagram identifies application migration from baseline to target application components. It enables a more accurate estimation of migration costs by showing precisely which applications and interfaces need to be mapped between migration stages. It would identify temporary applications, staging areas, and the infrastructure required to support migrations (for example, parallel run environments, etc). | |
| 2.3.3 Application Architecture Models | Interface Catalog | Phase C - Application Architecture | No | The purpose of the Interface catalog is to scope and document the interfaces between applications to enable the overall dependencies between applications to be scoped as early as possible. Applications will create, read, update, and delete data within other applications; this will be achieved by some kind of interface, whether via a batch file that is loaded periodically, a direct connection to another application's database, or via some form of API or web service. The mapping of the Application Component-Application Component entity relationship is an important step as it enables the following to take place: Understand the degree of interaction between applications, identifying those that are central in terms of their dependencies on other applications Understand the number and types of interfaces between applications Understand the degree of duplication of interfaces between applications Identify the potential for simplification of interfaces when considering the target Application Portfolio Support the gap analysis and determine whether any of the applications are missing and as a result need to be created The Interface catalog contains the following metamodel entities: Logical Application Component Physical Application Component Application communicates with application relationship | |
| 2.3.3 Application Architecture Models | Application/Organization Matrix | Phase C - Application Architecture | Yes | The purpose of this matrix is to depict the relationship between applications and organizational units within the enterprise. Business operations are performed by organizational units. Some of the operations and services performed by those organizational units will be supported by applications. The mapping of the Application Component-Organization Unit relationship is an important step as it enables the following to take place: Assign usage of applications to the organization units that perform business operations Understand the application support requirements of the business services and processes carried out by an organization unit Support the gap analysis and determine whether any of the applications are missing and as a result need to be created Define the application set used by a particular organization unit The Application/Organization matrix is a two-dimensional table with Logical/Physical Application Component on one axis and Organization Unit on the other axis. The relationship between these two entities is a composite of a number of metamodel relationships that need validating: Organization Units own Services Actors that belong to Organization Units use Services Services are realized by Logical/Physical Application Components | |
| 2.3.3 Application Architecture Models | Software Distribution Diagram | Phase C - Application Architecture | Yes | Yes | The Software Distribution diagram shows how application software is structured and distributed across the estate. It is useful in systems upgrade or application consolidation projects. This diagram shows how physical applications are distributed across physical technology and the location of that technology. This enables a clear view of how the software is hosted, but also enables managed operations staff to understand how that application software is maintained once installed. |
| 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 | Networked Computing/Hardware Diagram | Phase D - Technology Architecture | No | Starting with the transformation to client-server systems from mainframes and later with the advent of e-Business and J2EE, large enterprises moved predominantly into a highly network-based distributed network computing environment with firewalls and demilitarized zones. Currently, most of the applications have a web front-end and, looking at the deployment architecture of these applications, it is very common to find three distinct layers in the network landscape; namely a web presentation layer, a business logic or application layer, and a back-end data store layer. It is common practice for applications to be deployed and hosted in a shared and common infrastructure environment. So it becomes highly critical to document the mapping between logical applications and the technology components (e.g., server) that supports the application both in the development and production environments. The purpose of this diagram is to show the "as deployed" logical view of logical application components in a distributed network computing environment. The diagram is useful for the following reasons: Enable understanding of which application is deployed where in the distributed network computing environment Establishing authorization, security, and access to these technology components Understand the Technology Architecture that supports the applications during problem resolution and troubleshooting Isolate performance problems encountered by applications, determine whether it is application code-related or technology platform-related, and perform necessary upgrade to specific physical technology components Identify areas of optimization as and when newer technologies are available which will eventually reduce cost Enable application/technology auditing and prove compliance with enterprise technology standards Serve as an important tool to introduce changes to the Technology Architecture, thereby supporting effective change management Establish traceability and changing application end-point address while moving application either from a shared environment to a dedicated environment or vice versa The scope of the diagram can be appropriately defined to cover a specific application, business function, or the entire enterprise. If chosen to be developed at the enterprise level, then the network computing landscape can be depicted in an application-agnostic way as well. | |
| 2.3.4 Technology Architecture Models | Application/Technology Matrix | Phase D - Technology Architecture | Yes | The Application/Technology matrix documents the mapping of applications to technology platform. This matrix should be aligned with and complement one or more platform decomposition diagrams. The Application/Technology matrix shows: Logical/Physical Application Components Services, Logical Technology Components, and Physical Technology Components Physical Technology Component realizes Physical Application Component relationships. | |
| 2.3.4 Technology Architecture Models | Environments and Locations Diagram | Phase D - Technology Architecture | Yes | Environments and Locations Diagram The Environments and Locations diagram depicts which locations host which applications, identifies what technologies and/or applications are used at which locations, and finally identifies the locations from which business users typically interact with the applications. This diagram should also show the existence and location of different deployment environments, including non-production environments, such as development and pre-production. | |
| 2.3.4 Technology Architecture Models | Platform Decomposition Diagram | Phase D - Technology Architecture | Yes | The Platform Decomposition diagram depicts the technology platform that supports the operations of the Information Systems Architecture. The diagram covers all aspects of the infrastructure platform and provides an overview of the enterprise's technology platform. The diagram can be expanded to map the technology platform to appropriate application components within a specific functional or process area. This diagram may show specification details, such as product versions, number of CPUs, etc. or simply could be an informal "eye-chart" providing an overview of the technical environment. The diagram should clearly show the enterprise applications. The technology platform for each application area can further be decomposed as follows: Hardware: Logical Technology Components (with attributes) Physical Technology Components (with attributes) Software: Logical Technology Components (with attributes) Physical Technology Components (with attributes) Depending upon the scope of the Enterprise Architecture work, additional technology cross-platform information (e.g., communications, telco, and video information) may be addressed. | |
| 2.3.4 Technology Architecture Models | Processing Diagram | Phase D - Technology Architecture | No | The Processing diagram focuses on deployable units of code/configuration and how these are deployed onto the technology platform. A deployment unit represents the grouping of business capability, service, or application components. The Processing diagram addresses the following: Which set of application components need to be grouped to form a deployment unit How one deployment unit connects/interacts with another (LAN, WAN, and the applicable protocols) How application configuration and usage patterns generate load or capacity requirements for different technology components The organization and grouping of deployment units depends on separation concerns of the presentation, business logic, and data store layers and service-level requirements of the components. For example, the presentation layer deployment unit is grouped based on the following: Application components that provide user interface or user access functions Application components that are differentiated by location and user roles There are several considerations to determine how application components are grouped together. Each deployment unit is made up of sub-units, such as: Installation: part that holds the executable code or package configuration (in case of packages) Execution: application component with its associated state at run time Persistence: data that represents the persistent state of the application component Finally, these deployment units are deployed on either dedicated or shared technology components (workstation, web server, application server, or database server, etc.). It is important to note that technology processing can influence and have implications on the services definition and granularity. | |
| 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. |