Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search
advertisement

RESOURCE PORTALS
View all Portals

WEB SEMINARS
Scheduled Events

RESEARCH VAULT
White Paper Library
Research Papers

CAREERZONE
View Job Listings
Post a job

Advertisement

INFORMATION CENTER
DM Review Home
Newsletters
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

GENERAL RESOURCES
Bookstore
Buyer's Guide
Glossary
Industry Events Calendar
Monthly Product Guides
Software Demo Lab
Vendor Listings

DM REVIEW
About Us
Press Releases
Awards
Advertising/Media Kit
Reprints
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Enterprise Architecture - The Holistic View:
Service-Oriented Architecture Versus Enterprise Architecture

online columnist JP Morgenthal     Column published in DMReview.com
February 23, 2006
 
  By JP Morgenthal

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 morgenthaljp@avorcor.com. 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.



E-mail This Column E-Mail This Column
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
Advertisement
advertisement
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2006 DM Review and SourceMedia, Inc. All rights reserved.
SourceMedia is an Investcorp company.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.