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.
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.
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.
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.
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.