2.3.3 Application Architecture Models

The purpose of this section is to define the target application architecture for the domain/sub-domain. Mandatory/optional: This section is mandatory as all the domain teams (excluding the data and infrastructure domains) need to produce a target application architecture at the conceptual and logical levels for their respective domains. In terms of quality criteria, this section should make clear: Relevant views (diagrams) at the conceptual level illustrating the application services and their contracts (interactions) in scope for the target application 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 application services (in table format) in scope for the target application architecture Characteristics of the application services (in table format) in scope for the target application 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 application services (in table format) in scope for the target application architecture If required, characteristics of the contracts (interactions) between the application services (in table format) in scope for the target application architecture Relevant views (diagrams) at the logical level illustrating the logical application components and their contracts (interactions) in scope for the target application architecture; these logical application components group application 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 application components (in table format) in scope for the target information architecture Characteristics of the logical application components (in table format) in scope for the target application 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 application components (in table format) in scope for the target application architecture Characteristics of the contracts (interactions) between the logical application components (in table format) in scope for the target application architecture Any relationships between the business function categories, business functions, logical application components, and application services that are in scope for the target architecture Any relationships between the business services and application 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 application architecture; for example, one assumption (recommendation) that has already been stated is that the physical application architecture is out of scope for the enterprise 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
Dependent Section
3. Architecture Requirements Specification

Process-Application Realisation

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

Software Distribution Diagram

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

Application Interaction Matrix

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

Application Communication Diagram

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

Application Use-Case Diagram

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

Interface Catalog

Mandatory
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

Application/Function Matrix

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

Application Migration Diagram

Mandatory
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).
Subscribe to 2.3.3 Application Architecture Models