Definition of Enterprise Architecture

Definition Last Updated 08-Feb-2016 11:04


The mission of Enterprise Architecture is to deliver organisational insights and establish governance that facilitate safe, efficient and beneficial enterprise transformations.

Note that whilst this definition might seem overly broad, it is in fact strictly true; for details see the main article.


Enterprise Architecture is the practice whose continuous processes1Hence mission in the concise definition., governance and coherent descriptions of organisational structures (expressed in terms of the enterprise’s component entities and the relationships between them, i.e. architecture descriptions and architecture models etc.) – inform the specification of the enterprise transformations sought in response to changing internal or external circumstances, and facilitate their safe, efficient and beneficially managed execution.

Here safe means not exposed to unmanageable risk, rather than not exposed to (any) risk. Unmanageable is used here rather than unacceptable because EA should provide information that helps provide insight into the nature of risk (including likelihood and impact) and it is explicitly not the role of EA to determine whether a risk is acceptable or unacceptable: that is a business decision.


Enterprise Architecture is a defined term of Enterprise Architecture.


Article Last Updated 08-Feb-2016 11:04

Notes on the Definition(s)

In the concise definition, the scope of EA is clearly the whole enterprise, simply because it is not explicitly limited to IT systems, people, processes, etc., each of which is properly a sub-domain of EA.

What EA Means

The meaning of the term Enterprise Architecture, like the term medicine, depends on how you use it.


Figure 1 – The Elements of EA

Medicine without an article – definite or indefinite – is what physicians (medics) practise. A medicine or the medicine is a substance of nominal benefit to a patient.

Similarly, Enterprise Architecture may refer to one of three things:

  • The discipline or practice called Enterprise Architecture
  • What actually exists, “the” architecture that an enterprise actually has, meaning all its parts (entities), and their attributes (including properties, relationships and behaviours)
  • Descriptions of architectures, the is, has and does – past, present and future/hypothetical. These are discussed below.

EA the Reality

The architecture of an enterprise is simply the way an enterprise is actually put together; an Enterprise Architecture is a description of the architecture of the enterprise.

Bearing in mind that “The map is not the territory”2Saying attributed to Alfred Korzybski, one must accept that the architecture will never be perfectly captured in any description and that one must therefore take special care in drawing up a map for a particular purpose to ensure that it is appropriate and contains sufficient detail for that purpose: the same map may not be appropriate for other purposes.

One of the challenges of EA is to have a modest standard set of maps that are appropriate for common business and technology purposes; architecture frameworks typically specify up to 25 different “views” (i.e. “maps”) presenting a variety of perspectives of the architecture from a defined set of viewpoints.

Whilst the architecture of an enterprise is whatever the components and their relationships are, and as such sufficient3Whatever the architecture is, it does what it does, ergo it is sufficient; it may not however be necessary: other collections of component and relationship might achieve the same. for the enterprise to do the things it does, an enterprise architecture as merely a description or model reality is not very useful4“Look on my works ye mighty, and despair!” Ozymandias, by Percy Bysshe Shelley, full text at Wikisource – it must be appropriate, it must be practical and it must be used in making decisions about changes to the architecture of the enterprise.

EA the Discipline

The disciple5That should of course have been “discipline”, but, whether due to inadvertent grandiosity or an unseen auto-correct, it has an amusing je ne sais quoi about it. Whether it is also a bon mot is another question. of Enterprise Architecture is concerned with the governance and management of the architectures of an enterprise, both real and described. But what it is for? Let’s examine the definition.

The idea of managed transformation encompasses the ideas that:

  • The transformation is directed towards well-specified (and presumably advantageous) objectives, i.e. goals
  • Progress towards the achievement of those objectives is monitored, and that
  • If circumstances are not as foreseen or other impediments arise (such as the intended means proving inadequate to a particular task), corrective action is taken

One could therefore replace “managed transformation” with “directed, monitored and corrected transformation” if one wished to be explicit. Note that, except in the simplest cases, it is projects and programmes that deliver change.

What does this mean? It means that Enterprise Architecture is about delivering business value and addressing the changing needs of the business. Those needs may be driven by external forces – such as a change in the regulatory environment – or by internal forces, such as a need to manage costs. The nature of the changes required in response to a change in circumstances (and possible approaches to delivering that change) are also the concerns of Enterprise Architecture.

The purpose of EA is to develop and maintain an understanding of how all parts of the enterprise work together so that sound proposals for changes to the architecture to meet the enterprise’s changing needs can be offered and the impact of changes assessed.

The governance aspect of EA arises from the support for the required sound proposals: EA establishes policies for the design, i.e. specification, of capabilities6Naturally including everything that may go by another name, such as processes, services, competences, etc. that are fundamentally abilities to effect transformations and thus capabilities., systems, etc. so that the risks associated with making changes to the enterprise may be managed.

EA the Description

The description of enterprise’s architecture is a model of the enterprise (often comprising many linked sub-models) that captures all (relevant7Architecture models and views should be defined with specific purposes (and audiences) in mind. Models and views for their own sake (or for nominal compliance with some framework standard) are worse than pointless; they divert attention and resources away from developing and maintaining models and views that add real value.) aspects of the enterprise’s construction and operations, presented according to specified individual or composite views of the information they contain.

The purpose of an architecture view is to present the information in one or more architecture models for the benefit of specified stakeholders, i.e. in a way that emphasises the particular entities, their relationships and attributes in which that particular kind of stakeholder has a recognised interest.

Enterprise Architectures are usually described in terms of fundamental entities, relationships and attributes defined in a metamodel, which provides a common standard for architecture modellings within the enterprise.

Definition of An Enterprise Architecture

A description, designed to support the managed transformation of an enterprise, of an enterprise and its context in terms of the nature of the enterprise as a whole and the involved individual performers and their behaviours and goals (or objectives), and related materiel.

Unpacking the Definition

The phrase managed transformation expresses the idea that the enterprise is never static, it is always slowly being transformed, and all transformation needs to be managed for safety and efficiency (safety here means understanding and managing risks).

Even if a business is stable, simply maintaining existing capabilities still requires transformation – albeit minor – because effort is required to compensate for changes forced upon it through changes in its environment, the need to replace worn-out or obsolete equipment and the need to replace people who leave the organisation for whatever reason, and so on.

Dynamic organisations actively seek to adapt so as to become more efficient (by doing the same with less, getting more from the same, eliminating redundant capabilities) and more capable (for example offering new products or services).

Managing transformation means planning, executing the plan and monitoring the execution of the plan so that corrective action can be taken if a plan is not correctly followed or does not work in practice. One of EA´s contributions to transformation management is to provide input to the planning process in terms of accurate descriptions of the things the plan will deal with directly and the things outside the plan that may have an effect upon it or be affected by it.

The definition of an enterprise architecture also refers to the enterprise, the nature of the enterprise, and its context because no description of an enterprise – at least none that includes some idea of the mission and strategy of the organisation – makes sense without an idea of who the enterprise serves and the constraints (legal, physical, financial, etc.) it must work within.

The performers, objects and activities of an enterprise architecture are the three broad categories of things that comprise an organisation: performers – which includes people and systems – do things; objects (things or data) are what the performers work on or with; and activities are the processes they follow to achieve their objectives.

Any descriptive architecture and its associated products should be managed and kept under effective and appropriate change control.

Kinds of Descriptions

Various kinds of descriptions are recognised and will be described in turn

  • The “As-is” Architecture
  • Architecture Options
  • The Reference Architecture
  • The “To-be” Architecture
  • Transition Architecture

The As-Is Architecture

An As-is architecture is an approximate description of the actual architecture of something; how accurate or approximate it is or should be – and when or whether it is for purpose – are just some of the questions that must be answered carefully.

Architecture Options

Architecture options are descriptions of possible future states, organisational approaches (i.e. specific designs) given in sufficient detail to permit assessment and comparison in appropriate business terms so that one may be selected (the To-Be Architecture) for implementation by a project.

Note however that it is conceivable that no option is selected: if the benefits of the even best option are outweighed by the cost one should not proceed; however, one must be wary of all assessments and take care to recognise that assessment and comparison can only take into account so many things, and that if there is a strong feeling that some change is nonetheless worthwhile, the architecture and its parameters may need to be broadened to reflect hitherto neglected considerations.

The Reference Architecture

A reference architecture is a body of design patterns and norms from which and against which architecture options should be derived and judged. However, sometimes architecture options may go against the reference architecture for good reason and the reference architecture may then be updated to reflect some new best-practice approach to some business or technical issues.

The reference architecture is therefore (to paraphrase a sentiment widely expressed) “guidance unto the wise and a law unto the fool”. The reference architecture guides but does not dictate – though of course changes to the reference architecture must be undertaken in accordance with prevailing processes, policies, standards, etc., i.e. the reference architecture, like every other thing of persistent business value, should be under effective change control.

The Target or To-Be Architecture

The To-Be architecture describes some future target state that either is, or may be a goal or objective for a project or programme.

Transition Architecture

A transition architecture describes states between an as-is architecture and an architecture option or a to-be architecture. Transition architectures are typically objectives whose specific identification facilitates the effective management of the transformation from the initial state to the target state that constitutes the goal.

Apart from facilitating the management of a large transformation, transition architectures also serve to facilitate the validation of the strategy. Unless a transformation is particularly simple or well-understood it may be hard to see how the validity of a to-be architecture can be assessed without also considering how (and sometimes, whether) it may be achieved: though a target state might be wonderful, if achieving it costs too much (c.f. the cost of merely being in or having a certain architecture at some future time) it may not be a good option.

Transition architectures are therefore no less important for strategic assessment than they are in helping plan implementation.

How Architecture Evolves

In principle, the process of changing the architecture of a system, sub-system or the enterprise as a whole is as follows.

The development of a new architecture may require input from a number of sub-domains of EA (as described in the next section below), but it begins with the As-Is Architecture, which either complies with the Reference Architecture or has known and accepted deviations from it.

A number of Architecture Options – alternative potential Target Architectures – are generated; the criteria that determine their content should be the same, but the extent to which the options balance the target parameters (cost, performance, standards compliance, etc.) will vary. The options must also be considered for their compliance with the enterprise’s Reference Architecture: non-compliance does not automatically exclude an option – there may be sound reasons for changing the architecture norms – but non-compliance must be considered.

Then a number of Transition Architectures must be developed: these map the route from the As-Is Architecture to the various potential Target Architectures. Each transition architecture also needs to be assessed for its practicality, value, etc. and its relationship with the Reference Architecture (and consequent adjustments to either).

From the completed set of architecture options, transition architectures and evolutions of the reference architecture, a proper assessment of cost, benefit, risk, etc. can be made and a final Target Architecture selected from the options developed. The path to implementation then follows the route mapped by the transition architectures.

The evolution, i.e. progressive development, of the Reference Architecture will be described separately.


Figure 2 – The Evolution of Architectures

Sub-Domains of Enterprise Architecture

The following graphic illustrates one way of decomposing the all-encompassing domain of enterprise architecture into related but non-overlapping sub-domains. Each domain should normally have an associated architect role. The role of the domain architect includes responsibility for the governance and management of EA activity within her domain (including the activities of other architects in sub-domains of her domain), and for establishing architecture policies for relevant activity within it.

Division of the EA domain is usually necessary so that sufficient people with the relevant expertise are available to take on the work. The larger the organisation, the more divisions it may be appropriate to recognise.


Figure 3 – Sub-domains of Enterprise Architecture

Related Entries

Architecture Modelling

Notes   [ + ]

1.Hence mission in the concise definition.
2.Saying attributed to Alfred Korzybski
3.Whatever the architecture is, it does what it does, ergo it is sufficient; it may not however be necessary: other collections of component and relationship might achieve the same.
4.“Look on my works ye mighty, and despair!” Ozymandias, by Percy Bysshe Shelley, full text at Wikisource
5.That should of course have been “discipline”, but, whether due to inadvertent grandiosity or an unseen auto-correct, it has an amusing je ne sais quoi about it. Whether it is also a bon mot is another question.
6.Naturally including everything that may go by another name, such as processes, services, competences, etc. that are fundamentally abilities to effect transformations and thus capabilities.
7.Architecture models and views should be defined with specific purposes (and audiences) in mind. Models and views for their own sake (or for nominal compliance with some framework standard) are worse than pointless; they divert attention and resources away from developing and maintaining models and views that add real value.

Pin It on Pinterest