The system architecture specification may be defined according to various architecture views (see System Architecture Definition). Core structural views can be defined across the three levels of design abstraction (business, application and platform), according to the entities defined by the System Design Meta Model.

The following entities comprise the Business Architecture:

• Business Function - A discrete, unique grouping of related functionality
• Business Process - An end-to-end process that achieves a business goal and which may span business functions
• Event - An action that triggers a business process
• Business Unit - An organisational grouping that typically performs one or more functions
• Actor - A party who performs a role in the completion of one or more functions
• Information - The information that is processed by functions.

There are six interrogatives generally relating to the business architecture that the architecture should be able to answer:

• What – this describes the tangible things in the system, i.e. the DATA
• How – this describes the PROCESSES that take place within the system
• Where – the LOCATIONS that are important to the system
• Who – the PARTIES and ROLES involved with the system
• When – the EVENTS, both internal and external, that affect the system
• Why – the MOTIVATION and GOALS, the rationale and objectives for system

The Business Architecture entities may be presented in a number of views. Firstly, a functional view of the business process and functions, with associated information and actors.

Secondly, an information view showing entity relationships. It may also map the information entities to a related high level subject area.

In addition the Business Architecture specification should include the following artefacts:

• A Business Service Catalog that describes a logical grouping of functions performed by a individual business unit and related actors that supports the business operating model. These should be related to specific functional and non-functional requirements that can be used to define a service level agreement.
• A Functional Requirements Catalog that describes the architecturally significant functional requirements associated with the business functions. These are the requirements that drive the system scope, boundaries and structure.
• A Non-Functional Requirements Catalog that describes out the architecturally significant non-functional requirements relating to business operations, including availability, performance and workload.

The following entities comprise the Application Architecture:

• Application - A logical system component that encapsulates closely related functionality and information and delivers this to end-users (actors)
• Application Package - A physical system component that realises all or part of an application; this may be a commercial off the shelf (COTS) software or custom developed
• Application Interface - An interface that shares information between applications to support a business process
• Data - Information that is persisted in within an application data store

The Application Architecture entities may typically be presented in a structural functionally orientated view.

In addition the Application Architecture specification should include the following artefacts:

• An Application Catalog that systematically details how application related business functions and information are supported by application package modules and logical data entities
• A Data Dictionary that maps the business information into an application package specific logical data entities; this may be accompanied by a entity relationship model
• An Application Interface Catalog that lists the application interfaces including sending and receiving applications, related information and interface style (e.g. real-time or batch)
• A User Interface Catalog that lists the business services supported by each application and how the related functionality is delivered to associated actors

The following entities comprise the Platform Architecture:

• Application Service - Supports an application processing style such as presentation, online transaction processing, etc.
• Technology Platform - The underlying technology software products on which the Application Service is based.
• Platform Interface - An interface that shares information between applications to support a business process
• Infrastructure - The underlying hardware elements that support the software

The Platform Architecture entities may typically be presented through two structural views. Firstly, that shows the relationships between Application Services and associated Platform Interfaces.

Secondly, a somewhat conceptual view of how Application Services are deployed on Infrastructure within a given physical network and computing environment.

In addition the Platform Architecture specification should include the following artefacts:

• A Platform Catalog that systematically details how Application Services are supported by Technology Platforms, including versions
• A Platform Interface Catalog that systematically catalogs the platform interfaces including sending and receiving services and related protocols, also with cross references to the supported application interfaces