Fourthingstorememberwhenbuilding

enterprisearchitecturecapability

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

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.

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.

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

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

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.

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.

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.

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.