How does it work?

EA Light includes a number of concepts from traditional EA. However, it starts by establishing just two items, architectural principles and a list of an organisation’s capabilities.

Capabilities – In EA Light, a capability is a special term describing all the different ‘whats’ which the organisation does for its customer or stakeholder. EA Light employs a ‘capability mapping’ technique which rapidly assesses all of the things that the organisation does and starts to understand how each of those activities might be interrelated. It then considers how capabilities are related to departments, to programmes and to systems.



Here is a snippet from an (anonimised) capability tree for a ministry of health that XML Solutions has helped in the past

Although capability mapping is fairly common, capabilities are still the most unfamiliar aspect of EA Light for most ICT professionals. It is the initially flexible nature of a capability that allow EA Light to gather all the activities of the enterprise and get results quickly, relative to other enterprise architecture methods. For example, once you have mapped the relationships between capabilities, you can quickly understand the effect of changing any systems or processes which support a particular capability. It is also the capability centric nature of EA Light that ensures that the technology delivery remains focussed on what the business is trying to achieve, rather than being side tracked by the systems themselves.

Viewing enterprises in terms of capabilities also makes it much easier to establish reference models. For example, the capabilities for one hospital are likely to be similar to those of a second hospital. This allows two organisations to compare the ways in which they fulfil their capabilities and helps them to share ideas and approaches in a meaningful manner.

Once you have mapped your capabilities, EA Light provides a template – a capability card – which you can use to investigate a capability. That template is in a presentation format and is typically then shared online as part of a fully transparent, accessible architecture repository. At later stages the template may be filled in directly online as part of an EA intranet, automatically updating the architecture repository with a readable, exportable and sharable document. Ultimately that template will lead to options and to organisational decisions which must be made. It is also that template that flows through the governance processes.


“[XML solutions] has a deep and expert knowledge on NHS IT infrastructure and of cutting edge developments in the world of ICT. They provided me with expert consultation on the development of an Enterprise Architecture for a national NHS work programme. Some of these recommendations are now being implemented and providing a benchmark for the NHS in improved service delivery as a benefit of the emerging Enterprise Architecture.”

James Walker, CIO, National Screening Committee

Architecture principles – Architecture principles provide the yard stick for architectural decisions taken about a capability. Architectural principles are gathered at the start of the process and then shared, reviewed and agreed. Once agreed they can change but will need to pass through the governance process in order to do so.

Architectural or organisational decisions are recorded in the capability cards. These decisions can be cross referenced against the architectural principles and convergence or divergence from those principles is tracked. Programmes or projects can have justified divergence from the principles.

In EA Light (unlike some other EA methods) we try to make principles mutually exclusive so that comparison against the principles does not result in logical contradictions. Furthermore, we may try to introduce conflicting principles which can be traded off against each other. For example, “ensure user facing systems have sub 500ms response times” may at times need to be traded off against “ensure data is saved at the back end, before responding to the user”. We believe trade-offs always exist in a system so the principles should allow that to be reflected and expressed.


Drivers and goals – Drivers and goals are agreed in parallel with or soon after capabilities and principles.

Drivers dictate the overall direction of the travel for an organisation. They should apply well beyond the technology domain and need to be agreed by senior stakeholders. They rarely change but by changing the organisational drivers senior stakeholder can nudge the focus of attention for an organisation. This is because everything in EA Light ultimately traces back to one or more of the drivers. Reporting on the relationships between drivers and their associated goals, objectives and capabilities provides a good indicator of the activity and attention of an organisation.


Below are two examples of drivers from a small charity and large national healthcare organisation respectively.


Goals allow the expression of finer grained aims for departments or programmes within an enterprise. They typically set the focus of attention for the next 3-5 years. They may be general goals like “align systems with new government legislature”, specific goals like “increase take-up of the online detailed patient record service” or technical goals like “reduce response times for the user”. They are closely related to high level requirements or epics (in agile) and may reflect sets of requirements or user stories.

Leave a Reply

Your email address will not be published. Required fields are marked *