SOA is a journey. A long journey. Bring several changes of clothes.
Are organizations really ready to throw out manual processes and standardize?
Back in December, reported here in this blogsite, Oracle's Larry Ellison admitted as much, saying it will probably be 10-20 years before we really see the results of what we're doing. That makes perfect sense. Because SOA is not about slapping some new technology in place over a long weekend and issuing log-in instructions to the new system on Monday morning.
SOA means a change in thinking not only among IT professionals, but among line of business executives and professionals as well. That systems are there to serve them, not the other way around. And they have the power and capability to make adaptations in those systems, easily, whenever they need to be made. And leaders of the organization need to recognize and support this new interaction between people and systems (and that's going to take a long time).
Vendors would like you believe that SOA can be up and running in no time at all. But true SOA, as it's intended to be, will take years. The challenge for all SOA proponents is, how to keep the concept appealing to the business when tangible results are so far out in the future? Many businesses want to see results within the budget year, and many live quarter to quarter.
Chris Muir sees a lot of bumps in the long road SOA must travel. In a recent post, he picks up on Ellison's comments, and very astutely hits the nail on the head in terms of the challenge of long-term SOA:
"While Web services and SOA/BPEL are great enabling technologies, they're opening a huge can of worms in inter-system and inter-organizational communications that haven't even been really broached yet. Just because the underlying Web service communications allow you to communicate in a standard fashion, it doesn't mean the systems or organizations you communicate to are following any standards internally. And this is where the problems really start ... and you thought the technology was difficult enough?!"
In a B2B scenario, for instance, Chris refutes the notion, for example, that seamless networks of suppliers and customers can evolve from standardized approaches to services. He cited a case in which a purchase order Web service was exposed to three suppliers. One supplier got it right, but the other two could not interface correctly.
"In fact, behind the scenes they had manual processes sometimes that dynamically changed the result." If the company wanted to expand the reach of this service from three to 50 suppliers, all kinds of chaos would result, Chris says. He calculates that one full-time person would have been needed just to keep track of a weekly barrage of "changing interfaces, changing processes, making mistakes and so on."
Yes, enlightened businesses with forward-looking management will support the SOA vision because they understand how such innovations will move their organizations forward. And they'll move the right mountains to make it succeed -- again, over time.
But most managements are short-sighted, and want the here and now. That's why on this blogsite, you'll see a lot of discussion about approaches such as "Guerrilla SOA," (or naked SOA, or barefoot SOA, as Jim "World Wide" Webber puts it) in which SOA is introduced on a project-by-project basis, with the eventual vision of federating islands of SOA into something the enterprise can appreciate -- and afford. (Even though Jeff Schneider doesn't quite agree with this approach, warning that scattershot SOA is not SOA at all.) We'll keep looking at the pros and cons of both points of view.