Are you confused about the term service-oriented architecture? Is the lack of a formal definition of SOA causing governance issues within your organization? You’re not alone. Many individuals are as confused as you are; including me.
It’s easy for me bto espouse the benefits of SOA and the return-on-investment for moving to SOA,ut as an individual, I cannot force my definition upon the industry. I am at the mercy of definitions de jure, same as you all. In reviewing the literature on SOA, the 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 a client have forced me to examine SOA from the perspective of the EA, which requires a very different mindset about SOA than from the perspective of IT alone. As the EA is about strategy and organization, I had to clearly identify the aspects of SOA as they relate to the organizational hierarchy and business processes. Through this effort I began to focus on the ‘A’ in SOA.
Architecture
That the ‘A’ in SOA stands for architecture is a critical point. An architecture is a plan for implementation, it is not the instance of the entity. Industry pundits, analysts and others often use the ‘A’-word interchangeably with implementation.
This leads to confusion.
Consider a building. The building architecture is the plan for the building–not the building itself. If we 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. There are probably hundreds of 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, 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.
Cautionary Word
There is one caveat with the last sentence of the last paragraph. 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 articles.
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 ‘A’-word being placed 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.
