Published in DM Review Online in January 2006.|
Printed from DMReview.com
Enterprise Architecture: The Holistic View: The A in SOA is Architectureby JP Morgenthal
Are you confused about service-oriented architectures (SOAs)? Is the lack of a formal definition of SOA causing governance issues within your organization? After all, who's the primary stakeholder of SOA if it isn't defined? Don't be concerned; you're not alone. There are many individuals that have the same concerns and confusion as you - including me.
It's easy for me to espouse the benefits of SOA and the return on investment for moving to SOA, but as an individual I cannot force my definition upon the industry, which leaves me at the mercy of definition de jure - same as you. I believe that if you review much of the literature that is available today on SOA, the common theme that emerges is highly biased toward software development. In fact, you'd be hard-pressed to find a white paper or presentation on SOA from any software company selling SOA wares that doesn't illustrate the enterprise service bus linking together disparate business systems.
However, my efforts in producing an enterprise architecture (EA) for one of my clients has forced me to examine SOA from the perspective of the EA, which requires a very different mind-set than SOA from the perspective of IT alone. Because the EA is about strategy and organization, I had to clearly identify the aspects of SOA as it relates to the organizational hierarchy and business processes. It was through this effort that I began to focus on the A in SOA.
As stated in the title of the column, A in SOA stands for architecture. This is a critical point to grasp if you're going to understand SOA. An architecture is a plan for implementation - it is not the instance of the entity. However, industry pundits, analysts and others have been using the A word interchangeably with implementation. To further illustrate how this leads to confusion, I will fall back to the age-old analogy of building architecture.
The building architecture is the plan for the building - not the building itself. If we want to compare aspects of an SOA to a building, perhaps we can compare the foundation to the enterprise service bus, the beams to the SOAP protocol, the floors to the business services, etc. However, this is just one configuration of this building based on the architecture, and there are probably hundreds more ways I could build this building based on the same architecture.
By staying true to the word architecture in SOA, your SOA is your plan for how you will build, deploy, access and manage services in your organization. Indeed, as we have done with my client, not all services are machine-based. We have human-based services as well. The abstraction simplifies the development of business processes and makes them extremely reusable. Most importantly, your SOA does not have to look like any other organization's SOA in order to work.
There is one caveat. When a building is being built, there are certain engineering principles and laws of physics that must be adhered to or the building will come crashing down. Likewise, there are some basic tenets of building, deploying, accessing and managing services that must be adhered to or your SOA will amount to a telephone network with no phones at the endpoints. What are these tenets? We'll address that in future columns.
Know this: No longer must you endure in silence the shame of not knowing what SOA is, because no one else does either. Whatever SOA is, it's still emerging and taking shape, much like the Blob as it slowly consumed small villages and towns. However, by staying true to the architectural underpinnings that gave birth to the placement of the A word after service oriented, you will create an environment that allows you to take full advantage of a services-oriented approach to building whatever it is you wish to build.
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.
Copyright 2006, SourceMedia and DM Review.