Five great unsolved mysteries of SOA
There's a lot of mystery still surrounding service-oriented architecture. 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 is being hyped to incredible levels by vendors and analysts, there is precious little information about the fundamental implications of this new approach.
How could SOA be failing when nobody really has SOA yet?
Here are some of the unsolved mysteries that still persist around SOA:
#1 If SOA is failing so miserably, where are the horror stories? Plenty of pundits and analysts declaring SOA to be a failed idea; yet nobody has really 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 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.
#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. As Mark Rix explained it, 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 point-to-point interfaces. Who's taking these risks -- or who's being asked to take these risks?