Why Nobody is Doing Enterprise Architecture

I’m sure it comes as no surprise that I belong to a number of enterprise architecture-related forums and discussion groups. Sometimes, however, I wonder if it’s worth the trouble. After a while, the babble coming from these groups begins to repeat itself, devolving into argument after argument on what enterprise architecture really is.

In our Licensed ZapThink Architect (LZA) course, we love to point out that the collective term for architect is an argument. As in a flock of seagulls, a pride of lions, or an argument of architects. Put enough architects together in a room, and sure enough, an argument ensues. Furthermore, architects love nothing more than to argue about the definitions of terms—since after all, definitions are simply a matter of convention. Bring up the question as to what “enterprise architecture” means, well, you might as well go home. No more work will be done today!

It doesn’t help matters that many techies have co-opted the term enterprise architecture to mean some kind of technology-centric architecture or other. Look up enterprise architect on a job board and chances are, four out of five positions that call themselves “enterprise architect” are entirely technology-focused. In spite of this confusion, if there’s one thing enterprise architects can agree on, it’s that enterprise architecture is not about technology. Sure, every enterprise these days has plenty of technology, but there’s more to the enterprise than its IT systems.

Unfortunately, there’s little else enterprise architects agree on. Some of them point to ontologies like the Zachman Framework, in the belief that if we could only define our terms well enough, we’d have an architecture. Others point to methodologies like TOGAF’s Architecture Development Method (ADM), figuring that if we follow the general best practice advice in the ADM, then at least we can call ourselves enterprise architects.

Hence, an argument of architects. If you’re an architect, you probably already disagree with something I’ve written. See? What did I tell you?

The problem is, neither Zachman nor TOGAF—or any other approach on the market, for that matter—is truly enterprise architecture. Why? Because nobody is doing enterprise architecture.

The truth of this bold statement is quite obvious when you think about it. Where does enterprise architecture take place today? In enterprises, of course. That is, existing enterprises. And you don’t architect things that already exist. Architecture comes before you build something!

Can you imagine hiring an architect after building a bridge or a building? I can hear that conversation now: “we built this bridge organically over time, and it has serious issues. So please architect it for us now.” Sorry, too late!

Most forms of technical architecture don’t fall into this trap. A solution architect architects a solution before that solution is implemented. A Java architect or a .NET architect does their work before the coders do theirs. You don’t build and then design, you design and then build. Even if you take an Agile, iterative approach, none of your iterations have build before design in them.

Enterprise architecture, on the other hand, always begins with an existing enterprise. And after working with hundreds of existing enterprises around the world, both private and public sector, I can attest to the fact that every single one of them is completely screwed up. You may think that your company or government organization has a monopoly on internal politics, empire building, irrational decision making, and incompetence, but I can assure you, you’re not alone.

Enter the enterprise architect. The role of today’s enterprise architect is essentially to take the current enterprise and fix it. OK, maybe not the whole thing, but to make some kind of improvement to it. Go from today’s sorry state to some future nirvana state where things are better somehow.

If you’re able to improve your enterprise, that’s wonderful. You’re providing real value to your organization. But you’re not doing architecture. Architecture isn’t about fixing things, it’s about establishing a best practice approach to designing things.

OK, so if nobody is doing enterprise architecture, then who actually architects enterprises, and what are they actually doing?

The answer: nobody. Enterprises aren’t architected at all. They are grown.

Every entrepreneur gets this fundamental point. When entrepreneurs first sit down to hammer out the business plan for a new venture, they would never dare to have the hubris to architect an organization large enough to be considered an enterprise. There are far too many unknowns. Instead, they establish a framework for growth. Plant the seeds. Water them. Do some weeding and fertilizing now and then. With a bit of luck, you’ll have a nice, healthy, growing enterprise on your hands a few years down the road. But chances are, it won’t look much like that original plan.

Does that mean there are no best practices for growing and nurturing a startup through all the twists and turns as it reaches the heights of enterprise-hood? Absolutely not. But most people don’t consider such best practices to fall into the category of architecture.

If you’ve been following ZapThink, you can probably guess what the difference is. “Traditional” enterprise architecture—that is, take your massively screwed organization and establish a best practice approach for improving it—follows a traditional systems approach: here’s the desired final state, so take certain actions to achieve that final state.

Growing a business, however, implies that there is no specific final state, just as there is no final state for a growing organism. An acorn knows it’s supposed to turn into an oak tree, but there’s no specific plan for the oak tree it will become. Rather, the DNA in the acorn provide the basic parameters for growth, and the rest is left up to emergence.

Such emergence is the defining characteristic of complex systems: systems with emergent properties of the system as a whole that aren’t properties of any part of the system. Just as growth of living organisms requires emergence, so too does the growth of organizations.

Perhaps it makes sense to call the establishment of best practices for emergence architecture. After all, if we can architect traditional systems, why can’t we architect complex ones? As a matter of fact, we do just that in our LZA course. If we have any hope of figuring out how to actually architect enterprises, after all, we’ll need to take a complex systems approach to enterprise architecture. It remains to be seen, however, if it’s possible to architect enterprises that way. Have an opinion on the matter? Let the arguments begin!

Image source: http://www.flickr.com/photos/digitalsextant/4835111700/