Enterprise Architecture was introduced to address system complexity and poor business alignment. Typically:

  • IT systems have become unmanageably complex or too costly to maintain
  • IT systems are hindering an organisations ability to respond to market conditions in a timely and cost-effective manner
  • Mission-critical information is out of date or incorrect

Zachman Framework

In 1987, Zachman introduced a 'framework for information systems architecture' to address and manage the complexity of distributed systems. By looking at issues holistically and from different perspectives, Zachman's vision was to increase a businesses agility and increase the value from implementing a system.

The Zachman Framework is better described by a taxonomy for organising architectural artefacts (e.g. design documents/models/specifications) by target audience and issue rather than being called a framework which better reflect principles and practices for developing and maintaining the enterprise architecture repository.

This framework can be best visualised as a grid of concerns for each stakeholder within the business: what (data), how (function), where (location), who (people), when (time), why  (motivation) are listed along the top. Level of abstraction for each concern are listed down the side which describe a refinement from a plan to a functioning system:  scope (contextual model for the planner), enterprise (conceptual model for the business owner), system model (logical model for the designer), technology model (physical model for the implementer), detailed representation and finally the functioning system. At each cell, a model is used to describe information at the level of abstraction suitable to the target audience: e.g. a system model in the 'who' column may contain the human interface architecture, and yet at the technology model, this column will contain a presentation architecture.

Each model in the framework is additive and complimentary. Together, the collection of models forms a holistic view of the organisation that no one model can, possibly due to limits on levels of abstraction or expressiveness of a single type of model.

An artefact generated should only reside in one cell of the Zachman framework. If an artefact can be described by more than one cell on the taxonomy, perhaps questions should be raised about the quality or level of detail described in the artefact.

Completing the Zachman framework requires 36 models to be generated which sufficiently describes the system from the perspective of every stakeholder.

Zachman grid improves quality of the Enterprise Architecture by:

  • Ensuring every stakeholder's perspective has been considered
  • Ensuring each artefact has a specific focus point
  • Ensuring traceability of each business requirement to its implementation

The Zachman Framework, however, is not a complete solution. There are far too many issues that the Zachman Framework does not discuss: it does not describe the process for creating the architecture, or for evaluating the fitness for purpose of the proposed architecture.

TOGAF Framework: The Open Group Architecture Framework

The Open Group Architecture Framework describes enterprise architecture into four categories:

  • Business Architecture - describes the processes that a business uses to meet its goals
  • Applications Architecture - describes how applications interact
  • Data Architecture - describes how enterprise data is stored and access
  • Technical Architecture - hardware and software that supports applications

Naturally, applications architecture can be designed to meet the business architecture requirements,

One of the most important parts of the TOGAF framework is the Architecture Development Method (ADM): the process that describes how the enterprise architecture can be captured and maintained.

Models in TOGAF range from generic to specific: TOGAF describes that these lie on an Enterprise Continuum. ADM describes how generic models can be refined and have appropriate specificity added to meet the needs of the target stakeholder. The generic architectures are called "Foundation Architectures" and can be used by any enterprise. These are progressively refined to common system architectures - may only be relevant to a subset of organisations. Industry architectures describe patterns relevant to a domain. And finally, Organisational architectures are specific to an organisation.

TOGAF ADM describes a preliminary phase and a cycle of processes:

  • Phase A: Architecture Vision
  • Phase B: Business Architecture
  • Phase C: Information Systems Architecture
  • Phase D: Technology Architecture
  • Phase E: Solutions
  • Phase F: Migration planning
  • Phase G: Implementation Governance
  • Phase H: Architecture change management

The preliminary phase ensures buy-in from the organisation's stakeholders and evaluates the organisation's suitability to create and digest the architecture being created. This may involve adapting TOGAF to meet an organisation's needs. TOGAF is non-prescriptive and purposefully allows steps or phases to be skipped, partially completed or altered.


MoDAF is architecture framework developed by the British Ministry of Defence that captures information and allows it to be presented in standard viewpoints. The viewpoints are used by decision makers to help understand and document complex issues.

Viewpoints describe:

  • Strategic Viewpoint (StV) - desired business outcome and capabilities required to achieve it
  • Operational Viewpoint (OV) - the processes, information and entities needed to fulfil the capabilities.
  • Service Oriented Viewpoint (SOV) - services (units of work supplied by providers to consumers) to support the processes described in OV.
  • Systems Viewpoint (SV) - implementation of Operational and Service Oriented Viewpoints; defining the solution
  • Acquisition Viewpoint (AcV) - dependencies and timelines to deliver solution
  • Technical Viewpoint (TV)- standards applied to the solution
  • All Viewpoint (AV) - definition and glossary of the architecture.

MODAF describes a linear processes from establishing intended use of the project to documenting the results in a similar vein to the TOGAF architecture.