No, Virginia, there is no SOA wizard
by Jason Bloomberg, Senior Analyst, ZapThink, LLC
The lights have come down, the ornaments are packed away, and the Boy Scouts have the tree. It's time to put away the magic of the holiday season and get back to the realities of the working world. While ZapThink predicts 2005 will be a big year for service-oriented architecture (SOA), we must always balance the enthusiasm with a cool blast of reality -- and today's reality check is for the vendors who say their products are SOAs, or make building SOA a simple, automated task. Well, Virginia, there is no SOA wizard -- you know, the kind of wizard where click, click, click, and voila! You have an SOA! The fact of the matter is that no product will ever truly automate the creation of SOA, because SOA is architecture, and as such is a set of best practices, or a discipline, if you will. You can never get a great body from a pill, and you can't get architecture out of a box, either. Both take hard work, persistence, and discipline.
While only a few vendors claim to automate the SOA creation process, far more are now saying their products are SOAs or have SOA in them. While it is true that an increasing number of vendors are using service-oriented (SO) principles to architect their products, their claims of SOA are misleading, because the internal architecture of software products does not correlate to their customers' architecture. Software products have architectures of their own, after all, and it's relatively easy for those product architectures to be service-oriented, since vendors usually control all the code in their products. Building coarse-grained, loosely coupled service interfaces into a software product and making those services discoverable is often a straightforward task. But while such products might have service-oriented product architectures, they don't provide SOA as it's come to be defined, because SOA is an approach to enterprise architecture, not product architecture. SOA describes how businesses leverage IT functionality, not how vendors internally organize their products!
Now, lest you think we are digressing into some analyst-speak tirade, trying to coin "service-oriented product architecture" into some new four-letter acronym, let us point out that this Flash is issuing more of a warning, rather than trying to cut some verbiage into ever finer slices. The caveat here is that having SOA inside a product and enabling true SOA are two very different things. The former is a matter of good product redesign, so every vendor under the sun seems to be doing it. The latter, however, is far more of a challenge. For a software product to help enable SOA, it must provide a combination of security, management, process, tooling, and integration capabilities in a way that companies can truly leverage in their SOA initiatives. Now, there are an increasing number of vendors who truly enable SOA, and most of these vendors will likely do well in 2005. But there are far more vendors who have service-oriented their product architectures in order to jump on the SOA or ESB bandwagons, and yet offer products that are not particularly useful for enabling SOA.
With warnings, however, come opportunities. The first step to avoiding pitfalls is recognizing them as such. Here, then, is some specific advice for each of ZapThink's audiences:
The ZapThink take
Building world-class software products is extraordinarily difficult. Enterprise-class products can take thousands of person-hours to create, so younger vendors are always struggling to mature their products, while established vendors must deal with older, legacy code weighing down their offerings. When a new approach like SOA comes along and stirs the pot, every vendor wants to offer the latest and greatest, yet they all struggle with the same two issues -- maturing new technology and revamping the older stuff, all the while solving increasingly more complex customer problems. All this product development takes time, money, and vision.
If that weren't bad enough, enterprises now realize that while SOA promises the business agility so essential for dealing with many of today's tough business problems, SOA is difficult and complex, and thus will take -- you guessed it -- time, money and vision to implement. As a result, as companies take their time to purchase the latest SOA products, there is a resulting oversupply of technology as emerging vendors push their SO products to market as fast as they can.
The good news is that while there is an abundant quantity of SOA technology, there's no excess of quality SOA technology. On the contrary, software products that can actually meet the needs of companies who are actively building SOA implementations are still few and far between. Those vendors who offer such products will do well, and the companies that purchase them may also be successful, if they have the persistence and discipline to do SOA right. The challenge, of course, is separating the quality software from the bandwagon jumpers.
Copyright 2004. Originally published by ZapThink LLC, reprinted with permission. ZapThink LLC provides quality, high-value, focused research, analysis, and insight on emerging technologies that will have a high impact on the way business will be run in the future. To register for a free e-mail subscription to ZapFlash, click here.