Having discussed the sub-domains and domains of our enterprise architecture we can now bring them together in a single depiction shown below.
The enterprise strategy defines the purpose, the measures, and the means for delivering the enterprise architecture:
- Drivers - the purpose of the enterprise, its motivation
- Stakeholders - who is responsible for setting direction/objectives and delivering them?
- Objectives - what changes need to be effected, outcomes achieved, and targets reached when?
- Constraints - what are the restrictions on design, planning and delivery? For example, regulatory, budgetary, structural (manpower, plant, machinery)
- Assumptions - what are we to assume, who has made the assumption, and how are they justified?
- Measures - How do we know when we have delivered? How is success measured?
Further detail on how to define strategy can be found in our essay: “Developing a strategy in business”.
The functional architecture sets out the functional domains and their capabilities.
- Each functional domain will have its main capabilities and constituent capabilities. Detailed descriptions of these will be available in separate documents referred to by each subdomain in its architecture. For further details see the previous section on functional architecture
- The process inventory catalogues the main processes used by the enterprise. The level of detail will be sufficient for the purpose and priorities that require the enterprise architecture to be defined
- Principles - these guide the definition of the functional architecture (e.g. process definitions must include owners who are responsible for keeping them up to data in accordance with a review schedule; processes must be optimised before documenting them in the inventory)
- Strategy - as with each architecture domain, the functional architecture will be aligned to a strategy that itself supports the enterprise strategy
Information and data architecture concern themselves with descriptions of the information and data concepts and entities.
- The report inventory and data dictionaries contain the descriptions that define their architectures
- The principles and strategies provide the rationale/guidance for describing information and data, the purpose of the architecture, its goals, and delivery plans for changes that are needed to conform to the optimum architecture
The technology architecture aligns with and supports the functional architecture. Again, as with the functional architecture, each sub-domain provides links to detailed documentation. For further details see the previous section on technology architecture.
- The application/solution inventory describes the architectural components. Enterprises commonly use a specialised tool for managing this information (application portfolio management) but investment in tooling is not always sufficiently beneficial and initially the task can be adequately undertaken using a document repository, or library, and manual processes
- The principles and strategies provide the rationale/guidance for describing technology solutions, the purpose of the architecture, its goals, and delivery plans for changes that are needed to conform to the optimum architecture
Infrastructure architecture can be viewed as a specialised technology architecture. It provides centralised control and management of solutions that are themselves used to provide the technology (tooling) utilised in processes throughout the functional domain.
In software terms these components are operating systems on which software is installed, and the tools for managing their configurations, integration platforms that move and transform data between them, and technology used in communication (email, telephony, social media, etc.). In other contexts it may be the logistical solutions, and plant and machinery.
Composition of an enterprise architecture
