IT System Architecture Definition


IT System Architecture is a formal specification that describes the scope, structure and boundaries of the information technology landscape across various design abstraction levels, including the rationale, policies and principles that govern the specification.

This specification extends to precisely and unambiguously identifying the architectural design entities involved and their key characteristics, but is generally not concerned with the details of their internal construction and the full extent of any given design entity.

Architecture Views

The specification can be presented via different Architecture Views. An Architecture View presents the solution in a way that enables stakeholders that share a particular concern to understand how the solution addresses that concern.

Structural views present the key elements that comprise the architecture specification and can be defined across three levels of abstraction:

  • Business – Defines the business processing, at least in respect of that which the system needs to automate
  • Application – Defines how business processing is delivered by logical applications and the physical packages that support them
  • Platform – Defines how applications are supported by technology platforms and infrastructure

The System Design Meta Model (see Composition) defines the design entities that are used to compose the system architecture specification across the three levels of abstraction.

Other views may address more specific concerns such as security, business criticality, processesing archetypes, etc.

A number of third party Enterprise Architecture frameworks define Architecture Views. The Object Group Architecture Framework (TOGAF) defines a set of views that it believes are the minimum required in order to support development of the architecture, and which maps to the above design abstraction levels . The Zachman Framework is generally considered to comprise of a comprehensive set of views, although it may not be pragmatic or necessary to generate all of these.

Key Artefacts

The Architecture comprises key artefacts that are concerned with a Specification of the solution across various architecture views as well as a supporting Framework that facilitates specification through the application of reference models, patterns and methods that define the process of artefact creation and maintenance.


The architecture specification comprises of the Current State, Future States, and an associated Roadmap that joins them together. The Strategy defines the rationale, policies and principles that support this. The architecture will be specified from a variety of different Views, each of which addresses particular concerns.

  • Current State – a specification of the architecture at the current point in time. This needs to be maintained as time progresses
  • Future States – a specification of the desired architecture at various points in the future. This will change over time due to changes in the current state and strategy
  • Strategy – the design decisions and policies that implement IT imperatives, principles and standards, and that are used to direct the Future State and Roadmap
  • Roadmap – a specification of how the Future state is realised through migration from the Current State, including a definition of interim states and dependencies.

Reference Models & Patterns

In order to define the architecture at the various levels of abstraction and across the various views it is useful to define a number of Reference Models. These define the structure for articulating the architecture, provide a set of reference considerations and help to maintain consistency. They also define standard design patterns for the solution.

Whilst many reference models will be concerned with describing structure, another type of model is concerned with describing potential scope. These can be referred to as Vision State models. These define a complete set of potential functionality that is relevant for a given view.

Although the Vision State represents a complete set of functional scope, this is not necessarily the required set of functionality, or necessarily even an ideal set of functionality. Therefore the Current and Future State will always be a subset of the Vision State and the Vision State model follows the same structure as the Current and Future State specifications, and may therefore be defined in the context of the same structural reference model.

Architecture Patterns are closely related to Reference Models with the key differentiation being that a pattern defines concrete applications of the model for a particular purpose, including defining implementation options and the trade-offs between them.