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.
I just blogged that I think “Big SOA is Dead; Little SOA is Thriving” at: [url=http://tinyurl.com/soa-today2]http://tinyurl.com/soa-today2[/url] . Ok, maybe Big SOA isn’t “dead”, but certainly struggling to convince companies to invest in BPM, BAM, ESB (Big SOA) in today’s economic climate is a tough, academic sell when they can go Little SOA with positive ROI. Organizations want rapid results– they want SOA Today and not 6-9 months down the line!
Jordan,
I cannot deny that one of the biggest problems with SOA, and all architecture for that matter, is the nature of the soft benefits it provides. I am not a fan of the terms "Big SOA" and "Little SOA" as I find they add little value to the overall conversation. The issue is that SOA efforts are a continuum that range from pragmatic to strategic. Companies always see the immediate benefit from the pragmatic, but that has led to many long term issues for many businesses not being agile. The "fix it fast, fix it now" mentality ultimately hurts the business in the long run. Unfortunately, this usually only comes into play when the business wants to move quickly in a particular direction and IT is the stalwart in the process.
JP
There are two important points we are entangling here in.
1.) SOA cannot be conceived as just a JBOWS
2.) The impact of rapid development on SOA approach within organizations
The point (1.) is an Architectural & design issue. Whereas the point (2.) is a process issue. When the two get mixed it’s a recipe for disaster.
So what needs to be done?
Across the organization the Enterprise Architects should be practicing the best practice. They need to understand and arrive upon a common consensus on what are the best practices.
But what I regard as the most important catch here is to have a technology framework in place. Once you have a framework for all common patterns in place, it not only acts as the reference point but also as the very reusable piece of code and architecture for all teams to develop upon.
Secondly having standard documentation templates. For rapid development, least documentation is preferred. So have something which describes the approach in a simple FILL in the BLANKS manner.
Hi,
Nice post, I would add another common mistake: wrong levels of granularity: I recently blogged on this: [url=http://bit.ly/16Bcg]http://bit.ly/16Bcg
[/url]
nigel green