There’s a lot of FUD (Fear, Uncertainty and Doubt) surrounding Service-Oriented Architecture (SOA) in the IT industry. Some concerns are legitimate given the number of wide-spread failures have been documented and discussed. After all, would you want to be the IT manager better his/her job on SOA in this economy? Still, most of the FUD is undeserved.
To put things in perspective, there were more actual dollars spent on multi-year, non-operational implementations of SAP in the mid- to late-90’s, than all of the SOA endeavors put together. Still, SAP is going strong and still growing. Let’s face it when something is new, there’s going to be growing pains. The primary question businesses need to ask is, “is it worth the effort?” To that end, there’s lots of great literature on the value proposition for SOA that doesn’t need to be repeated here.
A root problem for SOA is a general lack of either understanding or agreement on a) what is SOA and b) the goal of the SOA initiative. This leads to the SOA initiative taking multiple, simultaneous paths, which if are not joined back together at some point, will appear as a failure. As far as an organization’s approach to SOA, all are valid as long as the process ultimately leads toward resulting agility for the business. Although, if questioned what a truly successful SOA initiative looks like, I would respond:
- An agreed upon business domain service model that accurately represents the activities and characteristics of the business
- Establishment of a common set of semantics for the business that are represented by the services
- Implementation of an appropriate governance model to ensure the business domain service model and the semantics are properly maintained
Clearly, my perspective on SOA is definitely from an Enterprise Architecture perspective. Which is a great lead-in into the issue at hand, which is the biggest mistakes of SOA initiatives.
1.The SOA initiative is really nothing more than JBOWS (just a bunch of web services) focused on providing data to a presentation layer. This is not SOA, this is client/server but with PowerBuilder being replaced with an HTML/Ajax interface. It’s okay for the SOA initiative to have a technical focus, but the resulting services need to represent business capabilities and expose a matching contract.
2.The first step in the SOA initiative is selection of an SOA tools vendor. Forward thinking is great, but focusing on development and governance before the first service model is designed is getting too far out ahead. With SOA being a hot topic, it’s natural for IT personnel to want to sharpen their skills and keep their resume current, but, the can also be a death knell to the organization’s SOA initiative.
3.Allow services to become a battleground for power. In large organizations, there may be multiple groups building services. No doubt, a certain number of these groups will leverage this opportunity to take a lead in an ongoing power struggle. Services need to be thought of as Enterprise assets if they are to be a successful part of a successful SOA initiative. Services held hostage will lead to redundancy as a side-effect of the power struggle, therefore, undermining a key value proposition for SOA in the Enterprise.
There are probably other mistakes that can take an SOA initiative astray; these just happen to be the ones I have seen most often. As you can see, they really are not that different than mistakes associated with other IT initiatives we have seen in the past or we might see in the future. SOA does require at different set of skills for design than required for a typical IT application development effort and businesses should ensure that they agree on their goals for the SOA initiative from the onset.