No, Virginia, there is no SOA Wizard
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:
- IT end-users — Be wary of SOA wizards! There are no shortcuts to success for your SOA initiatives. No product will automate SOA, and just because a product claims to have SOA inside or even to be an SOA, that doesn’t mean it will help you with your SOA plans. Look for products that accelerate SO development, but always remember that no product provides an architecture out of the box.
- Vendors — Never forget that SOA is a means to an end. Your customers don’t want SOA, they want solutions to their business problems, whether those solutions promote improved customer service, regulatory compliance, or lowered costs. They will only move to SOA if such a transition can help solve those problems cost-effectively. Your job is to make that happen. Architect your product following the principles of SOA, yes, but don’t confuse true SOA enablement with the hype in your marketing collateral.
- Consultants — Always remember the maxim “the right tool for the job.” Choose your tools and vendor partners wisely. Professional services firms have their greatest opportunities when their clients wish to transform their businesses, and SOA offers such a transformational force. Play your cards right, and you’ll be able to solve your clients’ problems with SOA.
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.