For those of you out there championing the cause of service orientation, the title of this post may catch you off guard. Likewise, casual observers of the service orientation movement might assume that developing services for reuse is the norm. Believe it or not, my title is not ironic, sensationalized, or tongue-and-cheek. I honestly believe that given the way most enterprises have established SOA, only a fool would build reusable services. Why might you ask? Simple. Rational self-interest.

What does rational decision-making have to do with adopting service orientation and developing services for reuse by others? I’m glad you asked. The simple fact is that the creation of services as reusable rather than one-off solutions is not free. Experts peg the expense of creating reusable solutions anywhere from base cost +30% to base cost +200%. It is significantly more expensive to build for reuse. On the flip side, it is considerable less expensive to reuse an existing service. Experts peg the expense of reusing a solution rather than creating one from scratch to be anywhere from base cost - 80% to base cost - 20%. In short, developing reusable services is very expensive, but once you have reused a service multiple times, a return on your initial investment will emerge. I blogged about this several months ago (SOA ROI, deconstructed) and provided a link to a whitepaper that explores this subject in more detail.

From an enterprise perspective this all seems very logical and the additional investment is easily offset by the value of the reuse over the long term. The problem is that in the short term, rational self-interest will drive individuals to never develop reusable services.

Consider the following scenario:

Bill is a project leader and is creating a service oriented product portal. He realizes that several of the services he needs could be designed in a fashion to foster reuse. As a good citizen of the enterprise, he directs the team to design these services in a more flexible and enterprise-centric fashion. Additional effort is spent during design and potential enterprise customers are interviewed regarding their potential needs. The added cost puts a strain on his budget but is certainly the best answer for the enterprise overall.

Sharon is another project leader in the same division as Bill. She is creating a product reporting application. She discovers that several of her requirements can be met by simply reusing the services created by Bill’s team. Other services that she needs are then developed as unique, one-off services to contain costs. Sharon uses a fraction of her budget to produce this solution, freeing up resources to meet other goals for the year.

At the end of the year, both Bill and Sharon will be judged based upon what they were able to accomplish with their respective budgets. In the absence of some acknowledgment of Bill’s contribution to the pool of available services or similar affirmation of Bill’s decision, then he is in hot water. Sharon looks like a hero and Bill comes off as a fool. Knowing this, Bill will be less likely to develop reusable services in the future (unless he can directly benefit in a very short timeframe).

Adopting service orientation and encouraging reuse is great, but what will compel divisions and individual project teams to actually play ball? In the absence of some sort of incentive structure, charge-back mechanism for using services, or similar recognition for contributions to the greater good, no one will develop reusable services. Rational self-interest will drive each group and each team to develop services that only help themselves and which will, in effect, re-create the same silos that we are trying to supplant.

All of this points to a very real gap that exists within many enterprises that are adopting or at least exploring SOA – lack of business buy-in. Someone within the business needs to recognize the true cost of SOA and put in place some sort of incentive structure to encourage teams to contribute to the greater good of the enterprise. SOA is not a short-term, quick-win approach. It requires strategic planning and long-term investment windows.

So what if you have no business buy-in? Are you sunk? No. You may not be able to get traction around reuse, but you can go for ease of integration, the benefits of standardization vs proprietary solutions, lower maintenance costs due to the loose-coupling that SOA offers, the configurable nature of services and process, and other benefits that do not depend upon long-term reuse time windows.

Adopting service orientation requires a considerable amount of strategic planning and up-front design work. There are a variety of business drivers around SOA and reuse is certainly a popular one. Is it foolish to develop reusable services? It is if you attempt to do so within an organization that is not viewing things strategically or is unaware of the long-term impacts of service orientation. In the absence of business buy-in and strategic incentives, only a fool would build reusable services.

I spent much of the second day talking with attendees, speakers, and SYS-CON staff about SOA, virtualization, and the conference in general. Overall, there was a general sentiment that the conference was a success and had some valuable content. One presentation from the day that really stood out was a case study from the banking industry — Delivering Big Bank Solutions with Community Banking Intimacy. The bank is Synovus, a regional bank in the southeastern part of the US with about 33 billion in assets spread across multiple lines of business (banking, financial management, brokerage, insurance, and more).

In a thick southern, ‘good ole boy’ style delivery, the speakers from Synovus described their approach as ‘Blue Collar SOA’, explaining: “…it may not be perty, but it works and we get a lot of value out of it.” The Synovus representatives went on to explain that while they did not set out to deploy a SOA solution, their business requirements and technology objectives led them in that direction. They went on to describe several keys to successful SOA adoption, including the following:

• Define and document a set of guiding principles
• Define and document a reference architecture that is consistent with those principles
• Identify standards, technologies, and products that can enable that architecture and communicate and manage this through governance
• Identify a business visible pilot project to convert the strategy and reference architecture into a real implementation
• Define and enforce the implementation strategy through governance processes
• Employ governance toolsets to validate services against guiding principles as well as policies and SLAs

The results of their SOA adoption as well as the importance of service orchestration is outlined in a white paper from Active Endpoints (their service orchestration partner).

The presenters concluded by identifying a huge list of lessons learned. Three things really stood out to me on that list:

1. Identify and document standards and best practices and enforce them through your governance processes
2. SOA changes your team dynamics — you will need more documenters than developers
3. Education is key because SOA is hard

That third one was especially of interest to me given Web Age’s focus upon SOA education. In the Q&A portion I asked for the folks from Synovus to elaborate on the education topic. They were eager to explain that they had discovered a huge gap between legacy skill sets and what it takes to be successful with SOA. They had to figure out how to translate those skills, bring people up to speed on new methodologies and terminologies and get people to think differently about how to solve problems. Synovus also discovered that considerable education and mentoring was necessary to help the leadership that direct their lines of business to “think outside their silo”. Amen!

At Web Age we have seen the same sorts of challenges and often discover that teaching the technologies is fairly simple. Teaching the methodologies is more difficult. Teaching the new mindset (e.g. ‘thinking outside the silo’) and providing business users with new tools and techniques for solving problems is even more difficult. So what is the most challenging? Getting organizations to actually change once they are educated. The technology side of SOA is relatively easy. The human side is where things get tricky.

Overall, the conference was a great experience. If you get a chance to catch the East coast or West coast shows next year, definitely go. I hope to see you there!

Last month, Aberdeen Group released a report detailing the findings from analyzing the service orientation results over a period of eighteen months for approximately 400 companies. The analysis revealed a ‘deep division’ between enterprises that simply deploy ‘a bunch of Web services’ and those that take a more strategic and comprehensive approach to service orientation. A lot of great analysis of these findings has emerged within the blogosphere:

• Survey: Done right, SOA pays by Joe McKendrick
• SOA Beginning to Pay Off by David Linthicum
• Survey points to SOA pay off by Tom Jowitt

I’ll let you dig through the report as well as the above posts for more details, but I would like to highlight one interesting aspect of the report. Aberdeen identifies three classifications of SOA maturity that categorize the survey respondents:

1. Best-in-Class (top 20% of aggregate performance scorers) - Characterized by organizations that prioritize investments in education/training, architecture, SOA middleware and infrastructure, and processes aimed at measuring and tweaking performance
2. Average (middle 50% of aggregate performance scorers) - Characterized by organizations that have made minor investments in SOA middleware and infrastructure, very little in education/training, and have virtually ignored organizational performance measurement metrics for refining the enterprise
3. Laggards (bottom 30% of aggregate performance scorers) - Characterized by organizations that have made little to no investment in SOA tools or training/education, tend to deploy Just a Bunch of Web Services (JBOWS), and virtually ignore the importance of governance

Beyond just identifying and labeling these groups, the report provides some compelling metrics around how these three categories drastically impact the ROI realized from service orientation. For example, every one of the Best-in-class organizations saw a reduction in application development costs, compared with only 59% of Average organizations. Those companies identified as Laggards, however, actually saw an increase in application development costs. Similar trends were identified regarding maintenance costs and impacts to user satisfaction.

So the question remains – Are you a SOA Laggard?

SOA ROI is a hotly debated topic, with some claiming that an ROI cannot be determined:

“Can You Assign an ROI to SOA? Not so much.” (Ann All)
“ROI doesn’t apply to SOA” (Joe McKendrick)

That last posted generated some discussion which led Joe to post a follow-up entry: “SOA is not above ROI scrutiny, but…” I was a bit disappointed with his first post, but I agree with several of the thoughts that Joe expresses in this latest entry. Determining an ROI for an individual SOA initiative or even an entire SOA strategy is difficult, but it cannot be above scrutiny.

A few weeks back, a client requested a detailed analysis of ROI calculation models for SOA. After putting together the tailored analysis for the client, I decided to leverage the research that I did into SOA ROI calculation and pull together a white paper on the subject: “SOA ROI, Deconstructed”. I hope that the community finds it to be valuable.