Are enterprise architecture teams hopelessly outdated and anachronistic in an agile and service-oriented IT world? The verdict is in, and the answer is yes. It's time to pull the rip-cord, shut them down, and send the folks into the trenches. Like centralized planning in a Stalinist regime, most folks now see that heavyweight enterprise architecture was horrendously hide-bound, autocratically inflexible, almost comically out-of-sync with the business, and worse, far too slow to ever respond to the real needs of business units and their unvariably unique requirements. It's perfectly clear that enterprise architecture won't survive in its present form much longer; sucking dollars out of the IT budget and taking the best talent while producing little in the form of actual value.
However, we also can't forget that we have to practice enterprise architecture in a world where businesses themselves are now often defined primarily by loosely coupled federations with other businesses via automated processes that use service-oriented techniques to form their value chains (i.e. like Amazon and its 50,000 partners linked together via web services, ADP and their payroll services, etc.). In this new service-oriented world, companies now realize they can seriously cut costs and increase overall value by building new composite systems out of their own services, and that of other companies, instead of building or buying yet another application silo. Service-oriented architecture achieves the long-sought after goal of enterprise application integration, provides real reuse of value, and solves myraid other classical IT problems in one fell swoop. Does this emergent focus on service-orientation and enterprise architecture give EA teams one final new lease on life as the enablers of the service-oriented enterprise. Or does it finally make them completely irrelevant?

Figure 1: The future of enterprise architecture: Agile, Non-Centralized, Accountable, Service-Based
Certainly, some folks, like Scott Ambler, have recently been advocating a more agile version of enterprise architecture. In most realizations of agile enterprise architecture, there is a considerably reduced central planning aspect, which was formerly concerned mostly with authoring master models of the enterprise architecture and creating piles of write-only documentation. Agile EA has more to do with working with people, coaching, and getting out in the trenches and mentoring developers on practical architecture techniques and developing architecture skills. Stephen Cohen, for example, has been doing an admirable job of describing modern EA recently, but you can clearly see the us vs. them mentality with his safari approach.
In the end, the common complaint with enterprise architecture that most stakeholders outside the EA team have is that EA is notoriously unresponsive to specific needs, too difficult and expensive to comply with, is needlessly complex, and too general purpose. EA also frequently prescribed inapproriate, outdated or excessively bleeding edge technologies. There is also the realization that the growing adoption of agile processes may not be compatible with traditional EA and might never support the use of formalized enterprise architecture. Finally, many folks in the organization just don't have the skills or tools to support what EA groups usually pump out: ivory tower architectures that were never validated in the field other than a pilot or two.
In any case, the answer is that service-orientation won't give EA teams one more chance, in fact, I think service-orientation will likely finish them off. Coupled with the widespread perception that central enterprise architecture groups have been a rampant failure and don't deliver – and with central control essentially being eliminated by pervasive service-orientation – and we'll probably watch EA evaporate as going concern before our very eyes. The only wrinkle comes in with the ever-growing demand that companies build open service-oriented organizations. A demand that is pushed by increased competition, globalization, and need for more efficient (re)use of resources. Over the next few years, to fuel increasing collaboration, supply-chain integration, demand for web-facing delivery of services, we will find that many organizations will be forced to deliver their enterprise architecture in the form of easily consumable, non-visual, and open services. By looking at some of the emerging models for these efforts, I think we can begin to see the outlines of what enterprise architecture organizations will look like for the rest of this decade. We have to remember the classic IT antipattern: Not invented here. All too often our industry comes up a priori solutions and either ignores or fails to recognize existing, successful models unless they fit preconcieved notions. In other words, if enterprise architecture, 90's-style, just doesn't work, then let's look at what does.
The best enterprise architecture I've come across hasn't come out of any ivory tower group. Invariably, the best architecture I see comes naturally from self-organizing thought leaders in an organization that seek each other out and collaborate on common solutions to their problems. Rather than the us vs. them mentality of old-world enterprise architecture, there is only an us mentality. Instead of proscribed standards, designs, technologies, and tools there is real consensus and immediate buy-in. Sure, there are political camps in any organization that don't like playing with other folks but the inexorable drive towards service-orientation in the enterprise makes it so that people have to play nice together like never before. Or they can't get access to or provide the services they must in order to survive. CIOs, chief architects, and other technical officers must foster this collaboration and seek out the folks that are 1) technically competent, 2) have ground truth in what the business actually does, and 3) have great people skills. The truth is that enterprise architecture has always been much more about people and business than about technology. Making enterprise architecture happen today is about building agile networks of people in your organization that have the big picture, the local political power, real understanding of technology, and have a stake in the final outcome.
Technorati: Enterprise Architecture, Computers and Internet, Agile Methods