Enterprise Architecture - The Holistic View:
Service-Oriented Architecture Versus Enterprise Architecture
||Column published in DMReview.com
February 23, 2006
When I first considered writing this piece, I heard the shrieks of hundreds of architects ring in my head, "They're not mutually exclusive architectural models, you idiot!" Well, I've been slashdotted before and lived to talk about it, so I'm going to forge ahead with my initial instinct on this issue.
Zachman, TOGAF, DODAF and FEAF are all enterprise architectural models. I'll leave it to you to Google the acronyms because it is of little importance to this column that you know what these represent. The point is, there's more than one way to skin a cat - especially in the enterprise architecture (EA) universe. However, what do these architectural models produce? Separatists! They build communities of architects that believe one way of modeling is supreme, much like a religious zealot.
Architects need to be open and creative to continuously push the boundary of what our systems are capable of producing. I recently worked with a client that was Zachman-oriented when I first started working with them. They wanted me to produce everything in terms of Zachman, until I was able to demonstrate to them that Zachman was too static to represent the agile organization they wanted to become. I showed them how, using the focus of the business, they could more easily align the technology vision with the business vision and then model the relationships to produce the analyses they were expecting from this exercise.
While the common EA models of the day were all limited in producing agile and matrix systems, a service-oriented architecture (SOA) matched our needs and our goals perfectly. The loosely coupled nature and service-based contracts produced a firm foundation upon which we could establish the web of relationships that modeled the business. Inside each service, we did leverage some EA techniques for modeling the relationships between organizations, processes and infrastructure, but at this point, it was less EA and more service architecture using EA concepts.
Now, I'll grant you that I am a nonconformist, and when I see structure in architecture start to form patterns and reusable models I'll most often point to the common-sense nature of these efforts and push back on the level of effort that goes into building and maintaining these tomes. However, this time is different, because I can tell you based on firsthand knowledge that using SOA led to immediate tactical benefits in addition to providing strategic guidance. The output of this effort was completed in two months instead of two years, and the organization as a whole was better prepared to leverage the output of this design than with any EA I've worked on to date.
Go ahead and be an EA zealot if you wish, but I'm sold on real SOA. To clarify, I'm not talking about service-oriented development of applications (SODA), which is what most people mean when they talk about SOA. I'm talking about a real architectural model that involves designing loosely coupled services with well-defined, self-describing interfaces that can be brought together to create composite services without having to dedicate any one of those services to a single task. This architecture can work for the entire enterprise or a single system or application.
For more information on related topics visit the following related portals...
Enterprise Achitecture and
Service-Oriented Architecture (SOA).
JP Morgenthal is managing partner for Avorcor, an IT consultancy that focuses on integration and legacy modernization. He is also author of Enterprise Information Integration: A Pragmatic Approach. Questions or comments regarding this article can be directed to JP via e-mail at firstname.lastname@example.org. Do you have and idea for a future Enterprise Architecture column? Send it to JP; and if it is used, you will win a free copy of his book.