E-Mail
Service-Oriented Architecture: Development and Ownership
by Tom Welsh, Senior Consultant, Cutter Consortium
This is the last of a series of four Executive Updates in which I examine the results of a Cutter Consortium survey on service-oriented architecture (SOA). In this final Update, we shall be looking at the favorite products and vendors for SOA development, security, mainframe connectivity, and Enterprise Service Buses (ESBs). We shall also find which dynamic lookup techniques are preferred and see how organizations allocate and share responsibility for the administration of SOAs.
As in the previous Updates of this series, I will take the opportunity to compare the findings of the present survey with those of a similar one carried out in early 2004.1 Thus, we will gain some insight into which opinions, plans, and commitments have changed in the intervening period and which have remained more or less the same.
Now that SOA has become so popular, there is a tendency for it to mean everything to everyone. Some people say, "We are doing SOA," meaning that they are implementing services with Web services using the WS-* stack. Others incline to ESBs, message-oriented middleware, or even 20th-century methods such as RPC and CORBA.
Nothing brings the level of abstraction down quite so well as deciding exactly how an SOA is to be built. After all, every choice implies the rejection of many languages, protocols, and features. Microsoft's Visual Studio, for example, has many adherents, but it does not support development in Java or on platforms other than Windows. Open source tools have their advantages, but they are rarely ideal for working with proprietary middleware, such as that of BEA, Oracle, or Tibco. Choosing a set of development tools, then, implies making many committal decisions about the present and future form of an SOA.
As Figure 1 shows, Visual Studio is by far the favorite choice for SOA development. It is used by 22% of surveyed organizations, compared to 12% using Model Driven Development (MDD) or Model Driven Architecture (MDA). IBM's Rational suite and the open source Eclipse platform (on which the IBM tools are based) are each the choice of 8%. Five percent employ other proprietary tools, such as those of Apple, Oracle, and Popkin (now part of Telelogic), while no one at all admits to using open source tools other than Eclipse.
Figure 1 -- Given that you have deployed an SOA, or plan to do so soon, how did/will you develop the necessary software?
There are, however, three other important responses. A respectable 22% -- exactly the same number of those using Visual Studio only -- build their SOAs with a mixture of products, typically including IBM's Rational and WebSphere tools, Eclipse, and tools from BEA, Borland, Microsoft, and Oracle. And another 20% agree that "SOA means being able to use any tools you like," with the implication that they do not need to make up their minds before starting work -- or, indeed, at any particular time. Lastly, 3% prefer to buy in components rather than build them inhouse.
How have these preferences shifted since 2004? The options offered are not exactly the same, but some trends are clear. The shares of both MDD/MDA and Eclipse have dropped sharply, from 22% to 12% and from 13% to 8%, respectively. The category "other open source tools" has disappeared altogether, falling from 7% in 2004 to 0% today. Visual Studio has seen only a slight drop in popularity (from 24% to 22%). These falls are largely accounted for by the introduction of the new options "A mixture of the above" and "SOA means being able to use any tools you like," which between them account for 42% of responses in the current survey. If we can make any inference based on these figures, it may be that dogmatism and single-technology solutions have become less popular, while more enterprises are keeping their options open.
The Enterprise Service Bus is a controversial concept, and some of its critics see it as an artificial construct whose only purpose is to boost the sales of certain vendors. Its advocates, on the other hand, often argue that SOA is too loosely defined to be viable without some kind of inner bracing, and that an ESB provides the necessary "steel skeleton" for a high-quality corporate SOA. Typically, performance, scalability, reliability, and security are cited as attributes that ESBs can contribute and which might otherwise be lacking.
As can be seen from Figure 2, only 27% of respondents have deployed an ESB within their SOAs. While this is significantly more than the 15% who had done so in 2004, it is less than the 38% who have deployed an SOA in production (reported in Part I, Vol. 9, No. 18). Apparently, it is possible to create and operate a production SOA without necessarily basing it around an ESB -- although, equally evidently, most production SOAs do include an ESB. This is an interesting issue, as most ESBs are proprietary by their very nature, even though they are usually based on industry standards. On the other hand, there are also a number of open source ESBs, such as Celtix, Mule, ServiceMix, and Synapse.
Figure 2 -- Have you deployed an Enterprise Service Bus (ESB)?
When it comes to choosing an ESB vendor, the outcome is very clear (see Figure 3). IBM is the runaway winner with 40% of those who have an ESB. IBM's most prominent middleware rival, BEA, follows in second place (16%), with Tibco and webMethods in a tie for third (8%). Oracle and Sonic Software (which claims to have invented the ESB) are each in use at 4% of those organizations that have an ESB. It may seem incongruous for SOAs to be based on proprietary middleware skeletons from industry leaders such as BEA, IBM, and Tibco, but considering the cost of these products, the enterprises that have deployed them must have deemed the purchases necessary and worthwhile.
Figure 3 -- From which vendor is the ESB that you have deployed?
Setting up a few Web services is easy enough and can be done very quickly. Building an SOA is, of course, much more challenging -- and security is one of the toughest aspects. Proper security must be designed in from the start, not tacked on as an afterthought, so anyone even contemplating an enterprise SOA should have a security plan. There are quite a number of promising specialist companies in this field, but which of them are most popular in practice?
Figure 4 shows the results, and once again the winner is IBM (25%). This includes the sizeable installed base of DataPower, which was acquired by IBM in October 2005. AmberPoint is the runner-up with 9%, just ahead of SOA Software (formerly Digital Evolution) with 8%. Layer 7 and Sonic Software (which acquired Actional in January 2006) are tied for fourth place with 3%, and Forum Systems, Reactivity, and Xtradyne have 2% each.
Figure 4 -- Given that you have deployed an SOA, or plan to do so soon, which of the following vendors' security products do/will you use? (Please select all that apply.)
Interestingly enough, 41% of respondents admit that, although they have deployed an SOA or have plans to do so, they have not chosen any security products yet. That does not necessarily imply that they have given no attention to security, as a certain amount can be done without buying any expensive specialist products. Nevertheless, it does suggest that quite a number of SOAs may be inadequately protected.
Somehow, SOA (or at least Web services) does not seem to go with mainframes. One is 21st-century technology, the other dates from the darkest depths of the 20th century. Yet once the obvious difficulties have been overcome, a mainframe actually makes a superb powerhouse at the core of an SOA. Designed to handle large interactive workloads while maintaining sub-second response times, mainframes are admirable servers for those who can afford to run them. What could be more natural, then, than to integrate existing mainframes into any new SOA?
There are no prizes for guessing which vendor is the runaway winner in the race to provide SOA integration for mainframes (see Figure 5). Yes, it is IBM again -- this time with an impressive 44% share of those organizations that have, or soon plan to have, SOAs. IONA (which has often cooperated with IBM) makes the second best showing with 9%, and Attachmate WRQ is third with 6%. Progress (probably through its acquisition of Neon Systems) has 3%, and Attunity and Jacada have 2% each. Although the "other" category looks significant at 9%, it largely consists of respondents who are not sure what solution their companies use.
Figure 5 -- Given that you have deployed an SOA, or plan to do so soon, which vendor's software do/will you use to extend SOA to mainframes? (Please select all that apply.)
As an SOA grows in size and complexity, it is important to provide some way for prospective service users to find out what services are available and how to invoke the ones they need. This requirement, termed "dynamic service lookup," was originally met by the Universal Description, Discovery, and Integration (UDDI) specification, which eventually became an OASIS standard. UDDI has not entirely lived up to its early promise, however, and many enterprises have opted for alternative techniques.
Nevertheless, Figure 6 shows that UDDI retains its primacy: it is still the choice of 48% of organizations. The older Lightweight Directory Access Protocol (LDAP), widely used as a general-purpose distributed directory system, is preferred by 17%, while Sun's Jini is used by 5%. Meanwhile, 27% get by with no dynamic lookup directory at all.
Figure 6 -- Given that you have deployed an SOA, or plan to do so soon, what is your preferred way of providing dynamic service lookup?
Compared to 2004, UDDI has lost some popularity; its usage has fallen from 57% to 48%. No data was collected in 2004 about LDAP or Jini, but the percentage not using dynamic lookup at all has stayed almost the same, sliding from 28% to 27%.
We have devoted a lot of time and attention to what may seem like technical minutiae. Let us conclude by zooming out to the galactic scale and asking who has overall responsibility for the operation of SOAs. This is very much an organizational -- even political -- matter, and may serve as a placeholder for a whole sheaf of relatively intangible issues whose resolution may be critical in determining the success or failure of a given corporate SOA.
The results are illustrated in Figure 7, and it is evident that the average enterprise has chosen to add SOA administration to the responsibilities of its IT department. This is true in 76% of cases, with only 20% entrusting the duty to individual business functions -- as was suggested by some of the more extreme apostles of SOA. These figures show only a slight divergence from the situation in 2004, when the IT department was in charge in 66% of cases, business functions in 16%, and "no one" in 12%! Presumably, that last category was one that could not persist for long in the real world, where someone has to take charge and make sure that business-critical software systems work and go on working.
Figure 7 -- Who has, or will have, overall responsibility for the availability, integrity, security, and quality of your SOA?
CONCLUSION
And on that note, this series of Updates comes to a close. We have seen that SOAs are now deployed on a fairly large scale and are being used for production purposes, although most are confined to a few departments at most. Only 5% of organizations have created enterprise-wide SOAs, with or without extensions beyond the corporate firewall. Just as in 2004, the largest group of respondents say that they have not yet built an SOA, "but it's in the works." Web services, loose coupling, and WSDL are deemed the three most important distinguishing characteristics of an SOA; in other words, many believe that Web services are the same thing as SOA. And whereas two years ago, 63% of respondents felt that SOAs were driven by the business (unlike all previous IT architectures), today that figure has fallen to 45%.
Respondents say that the top three benefits of SOA are greater business flexibility, shorter development time, and greater ROI from development investments. That jibes with orthodox thinking about SOA, which holds that it can deliver valuable business advantage by making IT more agile and responsive to business needs. The top four concerns, on the other hand, are interoperability with existing IT architecture, security, compatibility with the organization's business model, and interoperability with IT architectures across the supply chain.
We have also seen that Visual Studio still holds the upper hand, as the premier development solution for building SOAs, but that most respondents feel that freedom to use a variety of tools is the essence of SOA. Only 27% of organizations have deployed ESBs within their SOAs, although this is up from 15% in 2004, and IBM is by far the most popular ESB supplier. It also leads in SOA security and in mainframe integration, confirming that SOA does not necessarily favor the small vendor.
Finally, over three-quarters of respondents say that their IT departments have overall responsibility for the operation of their SOAs. Perhaps this was inevitable; after all, despite all the fine talk of new business paradigms, SOA is really just one more step along the path of software evolution.
1The 2004 survey was reported in Executive Updates, Vol. 7, Nos. 8, 10, 12, and 14.