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