Twenty years on, and stakeholders still don’t speak architect…

In Business Architecture, Enterprise Architecture by IRM UKLeave a Comment

Print Friendly, PDF & Email

Twenty years ago, the US Congress signed an Act known as The Clinger-Cohen Act (CCA).  The Act made it a legal requirement for US Federal agencies to appoint a CIO and specified their responsibilities to include “developing, maintaining and facilitating the implementation of a sound and integrated IT architecture”1.  The CCA had a far-reaching effects for Enterprise Architecture.

Now although the Act did not specifically mention “enterprise architecture”, the agencies’ response was to adopt EA frameworks such as FEAF, TEAF and DoDAF. Other governments followed with DoDAF being adapted by the UK and NATO to create the defence architecture frameworks MODAF and NAF2 .

In the twenty years since the CCA, Enterprise Architecture has flourished, but it has also attracted criticism as organisations have often failed to reap the anticipated benefits.

There are dangers in simply mandating the use of an architecture. If an architecture is required in order to demonstrate compliance then management will certainly ensure that one gets created. However, it may simply be viewed as just another non-functional requirement – an overhead rather than an asset. If the emphasis is on deploying the architecture, rather than employing it, then the architectural discourse will tend to focus on the inputs and activities needed to construct the architecture, rather than on outputs and results.

This seems to be at the root of a problem highlighted in a Forbes Tech article “Is Enterprise Architecture Completely Broken?”, namely that EA Frameworks are “self-referential”3. “Self-referentiality” suggests a negative kind of self-absorption: a preoccupation with form rather than content. There is often a perception that architecture teams are more concerned with architecture itself than with practical problems.

Assuming that everyone concerned agrees that architecture is simply a means to an end, why should this be?

The answer lies in communication. If we take professionals such as doctors and lawyers, they use one language amongst themselves and a different one when talking to clients. In contrast, the technical vocabulary of EA employs commonplace words but loads them with very precise meanings. Words that are effectively synonyms in everyday language have subtle distinctions and interrelationships assigned to them. It doesn’t help that different frameworks apply different meanings to the same words, and that many architecture practitioners (and stakeholders) have their own preferred definitions. It has been remarked that Britain and America are divided by a common language4. The architecture community has a similar problem.

Attempting to resolve meaning by reference to one or other architecture framework in the course of a conversation with stakeholders risks turning it into a dialogue about the framework itself. It also suggests a privileged status for the language of the architect over the language of the stakeholder. It shouldn’t be surprising if the stakeholder finds this irksome. Architecture is a collaborative activity but ultimately it’s the architect’s job to understand the stakeholder’s world, not the other way round. All of this simply reinforces the “self-referential” stereotype.

What can Enterprise Architects do to avoid this?

A good doctor will listen and talk to each patient in a way that is appropriate5. Although they master a formidable technical vocabulary they don’t let that get in the way of effective communication. The doctor matches the patient’s words to the medical terminology, but it’s mainly an unspoken process. If clarification is needed, it is sought using the language of the patient, not the medical textbook.
Consulting room conversations are about patients’ concerns, symptoms, treatments and outcomes. Architects who take a similar approach with stakeholders are unlikely to be accused of self-referentiality.

So much for negative self-referentiality. Is there a good kind?

The current holder of the FEAC Institute’s Industry Award for “Leadership in Enterprise Transformation” is the European Air Traffic Management Architecture6. EATMA is used to coordinate the Single European Sky ATM Research (SESAR) project, a €2.1Bn R&D programme to completely overhaul the air traffic management of European airspace.

Terry Bromwich, Principal Enterprise Architect at National Air Traffic Services, explains some of the reasons for its success:

It may sound obvious but organisations have limited success unless they take an Enterprise Architecture approach to their Enterprise Architecture. In the case of SESAR EATMA, a great deal of time was invested up front ensuring that the team were clear what was needed from the Architecture, who was going to use it and what data they needed.”7

So, to succeed, an organisation should take an EA Approach to EA? That’s so self-referential it’s actually recursive! It’s clear, however, that the focus is on the organisation, not the architecture. If in another twenty years EA has ceased to be accused of self-referentiality (i.e. the bad kind) it will be because EA practitioners have succeeded in demonstrating that Enterprise Architecture isn’t about building better architectures, but better enterprises.

*****

emy

Eugene McSheffrey – Principal Business Consultant, MEGA International

Eugene has over 17 years of experience of using software tools to help organisations develop and manage their Enterprise Architectures. He specialises in training and consultancy to enable clients realise business benefits by applying architecture frameworks such as Zachman, TOGAF, MODAF, DoDAF and NAF. He is the author of several white papers and was a contributor to the ‘UML Bible’ (Tom Pender, Wiley, 2003). Eugene holds a B.Sc. degree from the University of Edinburgh and a M.Sc. from the Open University. Contact Eugene at [email protected]

 

This blog was first published on MEGA’s blog page

  1. National Defense Authorization Act for Fiscal Year 1996”, Public Law 104–106,
    104th Congress of the United States of America, 10 February 1996.
  2. FEAF: Federal Enterprise Architecture Framework; TEAF: Treasury Enterprise Architecture Framework; DoDAF: Department of Defense Architecture Framework; MODAF: (UK) Ministry of Defence Architecture Framework; NAF: NATO Architecture Framework
  3. Is Enterprise Architecture Completely Broken?”, Bloomberg, J., Forbes/Tech, 11 July 2014.
  4. The observation has been variously credited to Oscar Wilde and George Bernard Shaw.
  5. Physician-Patient Communication – The Relationship With Malpractice Claims Among Primary Care Physicians and Surgeons“, Levinson, W., Roter, D.L., Mulooly, J.P., Dull, V.T., Frankel, R.M., Journal of the American Medical Association, 1997;277(7):553-559.
  6. 2015 Leadership in Enterprise Transformation using EA – Industry”, Zachman International, 8 October 2015.
  7. The 3 Open Secrets of a Successful Enterprise Architecture”, Bromwich, T., 5 November 2015.

 

 

Leave a Comment