Business Transformation in Action

Joe McKendrick

SOA's Seven Greatest Mysteries Unveiled

user-pic
Vote 0 Votes

Last fall, a group of us set about to better define the true meaning of service orientation and SOA, and the result was the SOA Manifesto.

The hope is that the Manifesto will help provide clarity to SOA. However, there's a lot of mystery still surrounding SOA. Many people -- even in IT -- say they don't fully understand what it can do, or how to go about building one. For a subject that has been hyped to incredible levels by vendors and analysts, there has been precious little information about its fundamental implications.

Here are some of the unsolved mysteries that still persist around SOA:

#1 How could SOA be failing when nobody really has SOA yet? Plenty of pundits and analysts declaring SOA to be a failed idea; yet SOA is an evolutionary process, and nobody really has fully completed a SOA implementation yet. There's been a rush as of late to declare SOA dead in the water, when surveys I have seen and conducted show most companies are still planning or considering their first service-oriented projects. In fact, the major challenge I keep hearing about these days is SOA gets too successful, and too many services are being added or launched willy-nilly -- or being demanded -- across enterprises that have SOA efforts underway. That's why so many vendors are hyping governance.

#2 If SOA is failing so miserably, where are the horror stories? Over the years, we've heard plenty about failed ERP and CRM implementations, how companies shoveled millions of dollars into software projects that not only failed to meet expectations, but also was hated and rejected outright by end-users. There haven't been such accounts associated with service oriented.

#3 How many full-functioning, true "SOAs" are there, exactly? Some analyst groups say that at least as many companies (75 percent and up) are undertaking SOA implementations. Others say the numbers are as low as four percent at present. How is this measured? By number of services? By the granularity of those services? By number of applications or processes accessing service-enabled, loosely coupled components? When does Just a Bunch of Web Services become SOA? What is the threshold at which Web services may require some better care and feeding, with governance, registry, management, and all that good stuff -- and thus become more SOAish?

#4 How do vendors sell a concept that will make it easier for customers to drop their products?
What's in it for them? The benefit of SOA is that services can be swapped out almost on demand. This, of course, is one of the conundrums vendors face, especially those pushing SOA in a big way. (Of course, all vendors say they are about "SOA" these days, right?)

#5 Who's paying for SOA?
What departments are ponying up the money and staff time to launch services that will be used by everyone else -- potentially, departments that have not had to commit any resources to take advantage of a service? SOA-enabled applications may take more to build at first than more traditional point-to-point interfaces, and the ROI shows up in economies of scale. The economies of scale generated through SOA -- better ROI over the long haul -- contrast with the cheaper up-front implementation of point-to-point applications. However, the risk occurs when organizations think they're putting SOA in place, but end up with little or no ROI because it wasn't true SOA -- still JBOWS, or point-to-point interfaces. Who's taking these risks -- or who's being asked to take these risks?

#6 Why is everyone so ga-ga over cloud computing and Enterprise 2.0, yet disinterested in SOA? When you get right down to it, cloud is the acquisition or provisioning of reusable services that cross enterprise walls. Likewise, Enterprise 2.0 is accessing services that enable greater collaboration and mashing up of information by end-users.  They are service oriented architecture, and they rely on SOA-based principles to function. Perhaps it's similar to trying to get people interested in jet propulsion technology, versus a weekend getaway on an island -- which will need that jet-propulsion technology to get them there.

#7 How does one know when a SOA project has been successful or unsuccessful?
A paradox comes into play here -- the companies most prone to adopt SOA are those that need it the least. If their management has the vision and foresight to support SOA, it's also very likely putting many other progressive programs in place -- business intelligence and analytics, data warehousing, and so forth. How much of their ongoing success is directly attributable to SOA? What's the definition of success? Documentable cost savings? A single end-to-end process enabled by Web services?

This is one of the biting challenges of SOA to begin with -- success is a long-term gain, evidenced by the sharing of services across multiple business units, in which service development time is notably cut back, or, a business is able to reconfigure and achieve faster time to market with a product or service thanks to the increased flexibility of its underlying infrastructure.

But the only true measures of long-term success in the market are either increased revenues or increased stock values, and many factors besides SOA will contribute to this. The real issue is figuring out how to measure SOA's contribution to this success. The "success" of the SOA itself is irrelevant.

1 Comment

Joe -

Thank you for the article.

I've worked in this industry as a business strategist, IT management consultant, and in technology sales and marketing for almost 40 years and have worked with many of the global Fortune 500 helping them maximize their investment in IT. I've seen "fads" come and go, and many recycled under a different name. I've even been responsible for some of them.

Time and time again I've seen good ideas fail because the people sponsoring them are either unwilling or unable to put them in context. Many SOA advocates focus on the "architecture" and forget the first word of the phrase - SERVICE. SOA is a way of providing business services more effectively. Unless you understand those services, why they are needed, and how they are being used, the architecture is worthless.

Information Systems are a SERVICE. Yes they can significantly impact business strategy, and yes they can enable increased productivity and operational effectiveness, but they are only a tool - no better or no worse than any other hammer, machine tool, calculator or fork-lift truck.

SOA can be an extremely valuable strategy and set of tactics for improving IS's ability to provide service to its customers. A successful SOA program, however, requires a careful analysis of the enterprise's business environment; an understanding of what services potentially are of greatest impact and value; an analysis of the existing portfolio; and the governance necessary to assure that investments are justified, appropriate to the needs and business strategy of the customer, and delivered in a manner consistent with those needs. This is not something that IS can do by itself.

The last sentence of your article is perfect: "The "success" of the SOA itself is irrelevant."

In this blog (formerly known as "SOA in Action"), Joe McKendrick examines how BPM and related business and IT approaches can promote business transformation.

Joe McKendrick

Joe McKendrick is an author and independent analyst who tracks the impact of information technology on management and markets. View more

Subscribe



Subscribe in Bloglines
Subscribe in NewsGator Online
Add ebizQ's SOA in Action Blog to Newsburst from CNET News.com
Add to Google

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT