This may be a bit of a rhetorical question, but here it goes. Is the field of Enterprise Architecture, in the 3rd or 4th decade of life, mature or immature?
At first glance, it is a silly question. Anything that has evolved from the late 80s as EA has, that has multiple frameworks and methodologies as EA does, that is so widely practiced and funded as EA is, surely cannot be called immature. EA has embedded itself in every CIO/CTO’s basket of buzz words and conceptual frameworks. It’s seen as a key mechanism to enhance alignment and drive value. It is ingrained in a services-based view of the world. Of course it is mature.
If this is the case, why is there a seemingly endless stream of EA angst over program definition, program valuation, program metrics and program justification? A quick Twitter search for #entarch, #ea or #enterprisearchitecture reveals a daily deluge of tweets about these topics:
- “Is EA still relevant?”
- “EA or SOA for cloud computing?”
- “The term Enterprise Architecture has so many interpretations it is no longer useful for communicating.”
- “Cross-Enterprise Architecture Reality Check – A Case Study”
- “Enterprise architecture isn’t a one-size-fits-all approach”
- “Are SOA and Enterprise Architecture Now the Same Thing?”
- “Demonstrating EA value to the business”
- “EA program organization for maximum effectiveness”
- “Enterprise architecture label generates more confusion than insight”
This was all found within 10 minutes. Why the existential angst for something so mature? Why are we questioning the very nature of EA 30 years into it? If Zachman defined it in 1987, why are we still having debates about what it is, what it does, how it is used, why it is used and when it is used? If it is so mature and innate to modern practice, why the constant battle to measure and prove the value of EA?
The reality of course is that EA, like the business and IT philosophies that underpin it, is constantly changing. If enterprise architecture is an architecture in which the system in question is the whole enterprise (including business processes, technologies, and information systems), then there will always be dynamism to it. These elements and components are under constant change. The blueprint that seeks to describe these elements will also be required to change constantly to cope with the march of time. The practitioners of EA are constantly undergoing education and illumination, constantly questioning the intrinsic nature of the thing they practice. In this sense EA is, and will always remain, immature.
Frankly I think the immature, constantly evolving nature of EA is a strength. Concepts and methodologies that don’t change, grow and adapt, will die. There is something about innovation imparted to the practice and field of EA by the constant gnashing of teeth over what it means and how it should be “done”. Sure it has a chaotic element to it. But I think this is a net positive. It keeps things fresh and keeps the thinking on this topic energetic. The back and forth debate on EA, the provocative statements that fly by on Tweetdeck in the #entarch column, serve to keep us sharp on this important area of architecture.
Since EA is so often described to newbies using the building/city analogy, let’s use it to discuss maturity. Imagine if physical architecture for buildings or infrastructure systems stopped evolving with Tudor England. Sure the houses would be charming (if that’s your style), but there would be no indoor plumbing. Cities would be health disaster zones and lack the ability to cope with modern innovations like the automobile. In short, life would be a mess. EA, like physical architecture, has to constantly change if not merely to keep itself fresh, but to cope with external innovations and incorporate them into its set of guiding principles.
So don’t let anyone tell you that we shouldn’t be having these discussions or that EA is settled science. It isn’t and will never be so long as business and technology elements continue to evolve. EA is immature. And that’s a good thing.