In “SOA is Like a Vacation” Brandon blogged on the notion that ESBs may, or may not, be part of an SOA which I agree with. In this blog I will go one step further and say that if I were you, I would question why implement SOA at all.
Now this is blasphemy on my part as I have made a nice living over the last 5 years implementing SOA. But let me say this. Every engagement we have had over the last 5 years, started as an SOA implementation and quickly became a justification exercise. What I mean is our engagements are routinely to help an enterprise who has already bought an ESB figure out why they bought it and what they are going to do with it. All to often “SOA” vendors slip under/through the doors/cracks of your favorite business and do a sexy dog-n-pony show, make a deal, drop some installers and run out the door.
Let me say this now ( and I will likely repeat this several times before the end of this blog)…
“SOA is a means to an end.”
The (hopefully obvious) problem with the above scenario is that SOA is an architecture, hence the “A” at the end. An architecture is never the goal, it is (dare I say) a means to a end. All too often vendors sell SOA as though it was the goal. Goals are business-centric and rarely technology focused. A typical business goal that may suggest SOA is the business need to share data across disparate systems in real time. The tidbits to glean from that statement are share, disparate and real-time. Before you write a flaming response to this blog on how your favorite architecture meets these needs remember it is just an example of a business need that may be solved with some of the features attributed to SOA.
Have you noticed that I haven’t used the term ESB yet. Brandon would be so proud.
Anyway, back to the point of the blog. As I was saying, Brandon and I often find ourselves not walking in the door on day 1 and implementing SOA, rather walking in on day 1 and asking to see their Enterprise Architecture artifacts that supports the decision to buy SOA gadgetry. If, and we rarely do get said documentation, we then ask for the SOA conceptual architecture that clearly shows how the business needs are met by SOA. For the record, we have never received an SOA conceptual architecture. So, as you might expect, we come in on day 1 and begin the process of making the already made decision to “go with SOA” look like it was based on sound requirements that support business goals. Following that, we then move onto developing a conceptual architecture which is used to retroactively evaluate the in-house tools. This is where we tend to alienate a few folks who would prefer to not have egg on their face for purchasing an SOA solution without doing a proper vendor evaluation against a conceptual architecture. In other words, there is no justification for SOA unless your efforts around Enterprise Architecture (EA) justify it. More on EA in future blogs. Hint, hint Brandon!
Stop laughing, this happens all the time. It is important to note that we have been in situations where the already purchased tool does not meet the business need without what we call “unnatural acts”. We document those facts, show what nefarious things would have to be done to make the toolset work and either do those nefarious things or punt. As a contractor, never violate the laws of nature unless the client fully understands what they are getting into.
Moral of this blog…. “SOA is a means to an end, nothing more”
Print This Post
Tags: Enterprise Architecture, Service Oriented Architecture
Couldn’t agree more. For any SOA related engagement, I ask the customers for EA artifacts or anything which formally justifies using SOA. This helps in preparing the business case. Customers with an EA function usually have bits and pieces. It is our job then to fill the gaps and evaluate/implement SOA based on EA principles (carved out from business and IT strategy). For customers with no EA function or lack of governance, SOA is usually nothing more than the next version of existing tools and technologies. Consequently, no alignment with the business needs.