An Architecture Content Metamodel defines the taxonomy for all architectural content across an organisation, the metadata associated with it, and how they are related to each other. This is a core foundation to enable architectural traceability across the organisation.
Traceability across your Enterprise Architecture landscape provides the organisation with the ability to understand how strategic and other initiatives driven by the business can impact down stream or upstream components and vice versa. Whether the requirement is to introduce an online channel to your customers, or upgrading to the latest version of Oracle, understanding how these initiatives impact your environment is critical to enable effective planning and decision making.
In TOGAF, the core Content Metamodel is defined in the following diagram:
Here we see the minimum set of metamodel entities, which are defined below:
- Actor: A person, organization, or system that is outside the consideration of the architecture model, but interacts with it.
- Application Component: An encapsulation of application functionality that is aligned to implementation structuring.
- Business Service: Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.
- Data Entity: An encapsulation of data that is recognized by a business domain expert as a discrete concept. Data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations.
- Function: Delivers business capabilities closely aligned to an organization, but not explicitly governed by the organization.
- Organization: A self-contained unit of resources with line management responsibility, goals, objectives, and measures. Organizations may include external parties and business partner organizations.
- Platform Service: A technical capability required to provide enabling infrastructure that supports the delivery of applications.
- Role: An actor assumes a role to perform a task.
- Technology Component: An encapsulation of technology infrastructure that represents a class of technology product or specific technology product.
This metamodel describes how each of these metamodel entites are related, and how, using such a content metamodel will enable traceablity across the entire organisation.
Lets look at how this can be enabled in an organisation to facilitate traceability.
ABC Bank provides banking services to its customers through ATM and Branch channels. Lets look at a process flow for a Withdrawal transaction across both ATM and Branch channels.
The following sample process details the Withdraw Funds (ATM) process, describing the process for withdrawing funds using the ATM channel.
Here we see the interaction between a Customer, the ATM, and the Banking platform, describing the process flow across human and system interactions. You can see there is an AccountGateway() function that is responsible for providing an abstract service layer to the core banking platform. This enables the ATM system to interact with the Core Banking platform using an enterprise defined interface rather than vendor specfic APIs provided by the Core Banking platform.
Similarly, the following sample process details the Withdraw Funds (Branch) process, describing the process for withdrawing funds at a Branch.
The architectural content in these process flows can be extracted to define architectural content consisting of Human and System Actors, Functions, Processes, Technology Components, Application Components, and Data Entities. But where to start?
Understanding the types of questions you want answered is imperative to assist with defining the artifacts and views to produce.
Using the core content metamodel defined above, we can start to define objects within our Architecture Repository. From the above processes, we can see the following list of architectural building blocks and their categorisations:
- [Process] Withdraw Funds (ATM)
- [Process] Withdraw Funds (Branch)
- [Application Component] AccountGateway.validatePIN
- [Application Component] AccountGateway.withdraw
- [Actor] Customer
- [Actor] Teller
We can start to build our Architecture Repository as follows:
Here we see the Processes and Application Components we have defined in our enterprise. The AccountGateway is an Enterprise Service, consisting of operations that can be used across many processess and functions in the organisation. We can see the AccountGateway service “supports” the Withdraw Funds (ATM) process. The relationships between each of the architectural building blocks provides architectural traceability across the architecture landscape.
Now, what Technology has the AccountGateway service been build on? What Technology is the Core Banking system built on.
Lets say the AccountGateway has been build using Oracle SOA Suite 11g (22.214.171.124) from the Oracle Fusion Middleware platform, and the Core Banking system is provided by Oracle Banking Suite XYZ (ficticious product ;)).
Now we can start relating the Application components to Technology components across the organisation.
Here we can see that the Oracle SOA Suite 11g (126.96.36.199) provides an Orchestration and Integration Platform Service to the organisation, so we can include the details of this in the repository as well.
Given Oracle SOA Suite 11g (188.8.131.52) is currently several releases behind the latest release 184.108.40.206. We can now introduce lifecycle status across the building blocks to assist us with impact assessment and planning of introducing change into the organisation. Lets introduce Oracle SOA Suite 11g (220.127.116.11) building block into the architectural landscape.
In planning the introduction of a technology upgrade, we can see that if we needed to schedule an outage to upgrade the Oracle SOA Suite from version 18.104.22.168 to 22.214.171.124, the Withdraw Funds (ATM) process will be impacted by this outage but the Withdraw Funds (Branch) process remains unaffected.
There are several Enterprise Architecture modelling and repository tools in the market that you can use to start populating your enterprise architecture repository. Tooling is only one aspect of Enterprise architecture, but establishing the correct foundation for your enterprise architecture repository is mandatory to ensure you get all the benefits of performing architecture across your organisation.