Four things to remember when building Enterprise Architecture capability, or, can you imagine a gas refinery running without blueprints? This article is about trying to understand the nature of the Enterprise Architecture capability in order to make it actionable, and to prepare for the challenges.

1. Four things to remember when building
enterprise architecture capability
What is an enterprise architecture capability?
The purpose of this article is not to be exhaustive when it comes to list the widely discussed
enterprise architecture (EA) success factors (like the need for C-level management support,
or the necessity to remain consistent with an industry framework like TOGAF), nor is it to
justify why architecture should be an essential asset1
of any organisation. Rather, it is to
look at four important aspects that are essential to understand the nature of the capability
that makes EA actionable, and to prepare for the challenges.
1. It should deliver services.
2. It should be process centric.
3. It relies on reference.
4. It is a learning exercise.
Organisations often consider enterprise architecture when in need for a lasting foundation
that can be trusted to assess and support change decisions. At Leonardo, we don’t think
that our work is to relay any definitions of EA to our clients – particularly as there are no
definitive ones. The term ‘enterprise architecture’ could disappear and be replaced – I like
‘enterprise intelligence’, but that is not the point.
In short, enterprise architecture capability enables an organisation to assess and control its
transformations in a robust manner, thanks to a reliable source of knowledge.
1
John A. Zachman article - You can’t “cost justify” Architecture - 2001

2. It should deliver services
The enterprise architecture capability should be centred on expressed needs and on the
attention to their stakeholders. The management of these needs – from collection to
fulfilment – should be at the heart of the EA capability. Needs, expressed in the form of use
cases, can be addressed at the relevant pace, and possibly one architecture at a time
(considering that the EA combines the different architectures of an organisation, not all
architectures need to be developed at once or at the same level).
The following graphic shows the EA as a central source of information that contributes to
major support and management activities:
Support and management activities can benefit from EA capability deliverables, like:
• Intranet publication for quick reference and training.
• Impact analysis results and related architecture views – for example, to assess the
impact of a new strategic direction in terms of cost or risk.
• Business processes analysis reports to reduce the effort and cost of integration and
the development lifecycle.
• Repository-based roadmaps to improve the design of systems transformation
planning.
• Reports to identify opportunities for corporate harmonisation and rationalisation.
• Enterprise information lexicon to support information management.

3. The next graphic illustrates the EA capability with the delivery of services at its core and
built around a device combining people, processes and tools:
• The triangle in the centre represents the architecture services to be delivered by the
EA capability and its stakeholders.
• The triangle at the top represents the concepts of the architecture content (the
metamodel).
• The bottom right triangle represents the tooling required to record content and
create outputs (the reports, etc., delivering the services). This segment makes the
capability actionable.
• The bottom left triangle represents the governance processes necessary to ensure
the quality of the content (recorded by the capability) and of the generated outputs.
• The EA capability has its lifecycle centred on collection of needs and delivery of
related EA capability increments to its stakeholders. That cycle is represented by the
circular arrows. Every new capability increment has an impact on each segment of
the EA capability.

4. It is centred on processes
The purpose of any organisation should manifest itself down to its processes: “organisations
are best envisaged, measured and managed as a set of processes whose interdependent
purpose is to add value for customers and other stakeholders.”2
That is why business process
representations – or put simply, the process architecture – should be at the core of the
enterprise architecture metamodel.
A good repository should act as a trustworthy source of knowledge about the whole
enterprise architecture. If this memory is trustworthy, the reaction(s) to a new context, and
the resulting need for change, can be evaluated in a robust manner. The impact of any
business change needs to be drawn from the business processes representation – which,
thanks to the relations between the architectures, allows an estimation of the impact and
related efforts on the other architectures.
The main challenge to obtain an actionable EA capability centred on the processes is to
reach the stage when your architecture representations (the models – and, first of all, the
process models) become reference material within the organisation. This is probably one of
the most difficult parts, and it determines the success of the exercise.
2
Roger Tregear’s article – bpm capability and credibility June 2013 - http://leonardo.com.au/newsletter.html

5. It relies on reference
Can you imagine a gas refinery running without blueprints?
Once a client insisted on having a repository where anyone could freely produce
architectural content, like a list of applications, or the description of which persons
supported which systems. My initial advice was that it was necessary to make sure that the
produced content be validated and converged into an administered library to create a
common reference (the equivalent of industrial blueprints). This meant that governance was
necessary. In other terms, it meant that any newly created architecture relevant content
had to be reviewed, at some stage, by an owner of that content before validation and
promotion to reference material.
Why is this important?
If the created models and objects within a repository are not validated and stored in a
controlled environment (i.e. where they are not modifiable by anyone beside the owner of
that content), then they are not completely trustworthy – and even if they could be reused
in other models, their reuse would not add solid value to the repository.
An example of potential referential content can be the list of roles within an organisation, or
the list of system applications.
Let’s say that a repository contains different roles linked to different activities and, as a
consequence of no governance, people could create their own roles when documenting

6. who executes the process activities. In this situation, it is difficult to obtain a good overview
of who does what in that organisation – some roles might have different names while
describing the same item. It is necessary, first thing, to converge these different roles into a
common list.
Technically speaking, it is only a matter of consolidating different objects into one, and
choosing a name that suits every stakeholder. But you often realise that this is not
necessarily straightforward, especially in an organisation that maintains different ways to
name things. And who would be the owner of the resulting unique converged object?
At this stage, you sometimes run into subtle resistance to changes in the way things are
named. Agreement on a common reference name might mean handing ownership over to
someone else, or losing a degree of autonomy at a local level. That resistance is often the
physical sign that a common language is necessary, but not yet in place in that organisation.
The client mentioned at the beginning of this section did not want to challenge the isolated
operating silos within his organisation – but by not doing so, missed the benefit of having an
architecture repository that allowed proper analyses of referential content.

7. It is a learning exercise
Actually, building EA capability can be seen as setting up a device – made of people,
processes, and tools – and organised as a dedicated office within the organisation. To use an
educational and holistic analogy, it is like considering the whole organisation in focus as one
student: stimulating a sleeping area of his cortex, developing memorisation and anticipation
thinking. The result is a transformational journey from rudimentary capacities, like reflex
reactions, to more elaborate ones that range from communication with a common
language, to regulation and optimisation – and then on to planning and strategy
elaboration.
The organisation as a whole is the learning entity – and the transformed organisation is the
true deliverable. Eventually, the organisation will have to take control and reach full
ownership the EA device;
Like in any learning exercise, it is a journey that requires active support and genuine
engagement, has its stages, and opens up unexpected challenges and opportunities.
As with individual learning, the process is cyclic, incremental; it is initially scaffolded by
exercises and guidance through enlightening situations. It also has to be opportunistic,
adapting to the maturity, the goals, and the culture of the organisation.
Like in individual learning, enterprise architecture capability will develop:
1. A better understanding of the organisation, by itself.
2. A capacity to use that understanding to act on itself and its environment.
3. A capacity to transform itself.

8. Enterprise architecture capability can be developed progressively, and can initially be
reduced to what is necessary to obtain one set of expected results while relying on the help
of a consulting organisation for that matter.
Some of the more successful EA projects we’ve experienced are the ones for which the
words enterprise architecture were not initially uttered – or were even forbidden. After all,
imagine telling a toddler that we will apply the pedagogical framework X based on
knowledge development theory Z from Dr W, when all his parents want is to have him eat
his food without messing the place!
The good news is that, if successful, the client organisation becomes equipped with a device
that can be progressively extended to provide services that assess and improve the way it
plans, controls, coordinates, runs, supports, and transforms its operations.
Reaching the ‘clean-eating stage’ equips our toddler with new capacities that can be used in
a variety of new situations – and, most of all, his parents benefit from that new level of
autonomy. This is an asset.
As with any learning exercise, there are subsequent maturity levels to be reached along the
journey that will transform an organisation from reactive to proactive in its capacity to
handle changes.
Reactive organisations can only wait to see the results of something gone wrong and rely on
the efforts of, yet professional, smart, experienced, but badly synchronised people.
Proactive organisations equip themselves with, and learn to use, a variety of referential
blueprints which describe:
- the organisation’s principles and goals
- the operations current state (models of processes, applications, information)
- the operations future states scenarios, to be assessed and chosen against the
principles, goals , and identified risks
- the roadmap set to reach the chosen future state
- the operation’s performance indicators and its control points.

9. In summary
Understanding the nature of an enterprise architecture capability building exercise allows a
better grasp of the many organisational- and people-related challenges paving the way
toward the realisation of the EA vision.
It is a long, transformational journey in which achievable goals need to be set.
• It should deliver services: it is what people expect; they don’t really care how you get
there, as long as you deliver the promised services.
• It should be process-centric: this is the only way to focus on the end purpose of an
organisation.
• It relies on reference: a common language must be used to create reference
material. Only organisation-wide reference material will allow the necessary
integration for comparison and optimisation.
• It is a learning exercise: where the organisation as a whole is the learner. The pace of
learning is slow; each new acquired capacity is a small step at an individual level, but
a tremendous improvement at an organisation-wide level.
About the Author
Frederick Halas is a Senior Consultant at Leonardo Consulting (www.leonardo.com.au).
Frederick joined Leonardo consulting after more than 15 years’ experience in software
development, related methodologies and enterprise architecture capability development.
He can be contacted at f.halas@leonardo.com.au.