By Eugene McSheffrey, MEGA International
Twenty years ago this month, the US Congress signed an Act that had far-reaching effects for Enterprise Architecture (EA). The measure subsequently became known as The Clinger-Cohen Act (CCA).
Signed into law on February 10th, 1996, the CCA made it a legal requirement for US Federal agencies to appoint a Chief Information Officer and specified the CIO’s responsibilities to include “developing, maintaining and facilitating the implementation of a sound and integrated IT architecture”.
Although the Act did not specifically mention “enterprise architecture”, the agencies’ response was to adopt Enterprise Architecture frameworks like FEAF, TEAF and DoDAF. Other governments followed the US example and encouraged the use of EA. DoDAF was soon adapted by the UK and NATO to create the defence architecture frameworks MODAF and NAF .
The concept of EA is now well established. There is evidence to suggest that the job of Enterprise Architect is now regarded as the pinnacle of the information technology career path, at least in the US. Salaries offered for “Chief Enterprise Architect” exceed those for CIO or CTO, and posts with “Enterprise Architect” in the title pay more than those with similar job descriptions. Although the research suggests that this might indicate confusion on the part of recruiters about what EA actually is, Enterprise Architects are hardly likely to argue.
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”. “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. Professionals such as doctors and lawyers effectively use one language among themselves and a different one when talking to clients. It doesn’t cause any confusion because it’s generally clear which one is being used. 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 language . 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 normally listen and talk to each patient in a way that is appropriate, so although they have to 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 Architecture. 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.”
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.