Enterprise Architecture Is More Than Engineering

For almost as long as people have built things, they have relied on architecture as a means to describe them. Many amazing structures—the Egyptian and Aztec pyramids, the Great Wall of China, and the Golden Gate Bridge, to name a few—have benefited from a thoughtful design. However, architecture is different from engineering in that it incorporates the need to balance aesthetic value and the artful ability to fit in with the surroundings, along with the engineering skill to design and build.
Great architecture like The Temple de la Sagrada Família in Barcelona is amazing to behold. What started as an empty grazing field in 1866 is now the heart of the city. Why did this part of the city evolve into the heart and not into a manufacturing center? Why does the Temple look like a unified structure and not a series of bolted on structures that were individually designed and built? The answers to these questions and others must have been considered in advance along with the artistic, structural, and design constraints.
So it seems that the idea to use architecture to describe an information system is a natural connection. Both buildings and information systems are complex structures—both need to be concerned with their surroundings and usability—and both require architecture. Yet many IT professionals associate architecture solely with the engineering design and build part of the definition. Maybe this is why the IT industry felt it necessary to create the term “enterprise architecture.”
Oddly enough the Oxford American Dictionary did not define enterprise architecture (EA). As a practitioner of EA, I find it interesting that it is not defined, but I am not really surprised or worried. After decades of architecting systems and the advent of frameworks by John Zachman, Steven Spewak, The Open Group, the Department of Defense, and others, many definitions exist. What is more worrisome is that we are still looking for EA’s meaning—and its results.
After decades of examination as an engineering and design discipline, the EA discipline began to take off in the 1990’s. Companies with a desire to improve standards and reduce the complexity of the infrastructure began dubbing staff members with the title of Enterprise Architect. New frameworks and processes were created, and the Federal Enterprise Architecture program became a mandate of the Clinger-Cohen Act of 1996. It was a time of emergence.
In the excitement, the role of architect seemed to come out of the woodwork—it was everywhere. Overuse and misuse further muddied and confused the term “architecture,” and hence our lack of clarity as to what enterprise architecture is, what it does, and what it looks like when it is successful. One thing we can agree on is what it looks like when it is not working. EA has Minimal Influence
It is easy to spot an EA program that is floundering; in such a program, the EA team has little or no influence on getting things done. I have spoken with teams that could not gain traction—their artifacts were disconnected from each other and lacked relevant guidance. I have also seen several beautiful architectures that articulate business direction, technology standards, application development building blocks, and other guidance, yet they go unused. An EA team may even establish the infrastructure with the hope that, if they build it, developers will suddenly start using it. Silo-project approaches begin to overtake standardization efforts as double-digit exemptions show that their guidance is constantly being circumvented. The software development lifecycle (SDLC) disconnect is apparent. Developers continue to use the approach they know instead of the new architecture that has not been explained and whose relevance is unclear. This ivory tower approach to EA is the quickest path to failure.
Another warning sign is the lack of business participation or the lack of demonstrable commitment of sponsors and stakeholders to the result. A lack of participation can fuel and be perceived as the ivory tower syndrome, which is a natural outcome of organizational isolation.