2.3.4 Technology Architecture Models

2.3.4 Technology Architecture Models

The purpose of this section is to either provide references to the relevant technology architecture documentation that complements the target architecture and/or this document, or to provide a high-level view of the technology architecture if it has not been defined in the technology architecture documentation. Mandatory/optional: This section is mandatory as this section will either provide references if the relevant technology architecture is described in other documentation or a description of the technology architecture if the relevant technology architecture is not described in other documentation. If the relevant technology architecture is described in other documentation, in terms of quality criteria, this section should make clear: • The relevant technology architecture documentation • Context around the relevant technology architecture documentation; e.g., validity, ownership, purpose • Any assumptions regarding the technology architecture documentation However, if the relevant technology architecture is not described in other documentation, in terms of quality criteria, this section should make clear: • Relevant views (diagrams) at the conceptual level illustrating the infrastructure services and their contracts (interactions) in scope for the target technology architecture • Description of the conceptual-level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders • Definitions for the infrastructure services (in table format) in scope for the target technology architecture • Characteristics of the infrastructure services (in table format) in scope for the target technology architecture; the domains will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both • Descriptions of the contracts (interactions) between the infrastructure services (in table format) in scope for the target technology architecture • If required, characteristics of the contracts (interactions) between the infrastructure services (in table format) in scope for the target technology architecture • Relevant views (diagrams) at the logical level illustrating the logical infrastructure components and their contracts (interactions) in scope for the target technology architecture; these logical infrastructure components group infrastructure services together based on common requirements/characteristics • Description of the logical-level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders • Definitions for the logical infrastructure components (in table format) in scope for the target technology architecture • Characteristics of the logical infrastructure components (in table format) in scope for the target technology architecture; the domains will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both • Descriptions of the contracts (interactions) between the logical infrastructure components (in table format) in scope for the target technology architecture • Characteristics of the contracts (interactions) between the logical infrastructure components (in table format) in scope for the target technology architecture • Any relationships between the business function categories, business functions, logical infrastructure components, and infrastructure services that are in scope for the target architecture • Any relationships between the business services and infrastructure services that are in scope for the target architecture • Any additional viewpoints and thus views that are required for this section due to new stakeholder requirements; these views will then be followed by descriptions for the views and definitions for the view artifacts • Any assumptions that have been used to define the target technology architecture; for example, one assumption (recommendation) that has already been stated is that the physical technology architecture is out of scope for the Reference Architecture.
Value
An agreed target architecture that can be approved by decision makers and consumed by implementors.
mandatory section
Yes
risk type
Cost
Time
Quality
Security
Risk owner
Architecture

Network and Communications Diagram

Mandatory
Yes
Security related?
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.

Processing Diagram

Mandatory
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.

Platform Decomposition Diagram

Mandatory
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.

Environments and Locations Diagram

Mandatory
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.

Application/Technology Matrix

Mandatory
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.

Networked Computing/Hardware Diagram

Mandatory
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.