The Gartner 2008 SOA User Survey is a good read with some surprising insights into SOA adoption.

One interesting development is that the rate of SOA adoption has slowed in 2008. About half of respondents last year who were planning SOA adoption, now have no plans for SOA adoption. The two main reasons for not pursuing SOA are a lack of SOA expertise, and the perceived lack of a business case. These reasons may be correlated in the sense that lack of SOA expertise makes it difficult to build an SOA business case. But the fundamental conclusion is that SOA doesn’t make sense for everybody.

SOA Adoption shows considerable geographic disparity. Europe has almost universal adoption (70% currently using), followed by North America (55% currently using) then Asia (25% currently using). The majority of organizations in Asia have no plans to adopt SOA. The report doesn’t really analyse why Asia has such low SOA adoption. My guess would be a combination of factors including lack of SOA expertise in the region, the characteristics of Asian companies being late technology adopters and the preponderance of manufacturing in the region which the survey shows has overall low SOA adoption compared with other sectors.

Organisation size correlates strongly with SOA adoption and the range of SOA deployment. There is a sweet spot for mid-size companies with current SOA adoption high in companies with employees between 1000 and 10,000. Large companies obviously struggle with the governance processes required to adopt SOA enterprise wide.

A big surprise for me was the correlation between SOA adoption and primary development language. Forty percent of current SOA adopters use Microsoft .NET. There is also a clear trend over the last 3 years away from Java toward Microsoft .NET and “other” languages such as dynamic languages. Correlation doesn’t mean causality so there is a lot of wiggle room in how you interpret this but clearly there is a move away from Java for SOA development. Harkening back to the COM/CORBA wars of the 90’s one of the key factors was that the Microsoft development environment made COM so easy to develop versus the complexities and diversities of CORBA that eventually COM came to dominate the component world. Is history repeating itself?

Web Services are the dominant SOA model, but a significant minority uses POX and REST approaches. About one third of existing SOA adopters already use or are planning to adopt EDA. The report also claims significant plans for WOA adoption, but I’m not convinced by the data. An eyeball comparison between Figure 14 (current WOA adoption) and Figure 15 (planned WOA adoption) doesn’t show a great deal of difference to me, except for Figure 15 looking a little more “peaky” around the 50% mark. So WOA adoption will increase, but I’m not convinced the data shows this is “dramatic” as stated in the key findings of the report.

Gartner has nominated their top 10 strategic technologies for 2009. In priority order they are:

1. Virtualization
2. Business Intelligence
3. Cloud Computing
4. Green IT
5. Unified Communications
6. Social Software and Social Networking
7. Web Oriented Architecture
8. Enterprise Mashups
9. Specialized Systems
10. Servers – Beyond Blades

My primary interests in SOA and CEP are represented in items 7 and 2 respectively (with some applicability to 8).

Business Intelligence. Business Intelligence (BI), the top technology priority in Gartner’s 2008 CIO survey, can have a direct positive impact on a company’s business performance, dramatically improving its ability to accomplish its mission by making smarter decisions at every level of the business from corporate strategy to operational processes. BI is particularly strategic because it is directed toward business managers and knowledge workers who make up the pool of thinkers and decision makers that are tasked with running, growing and transforming the business. Tools that let these users make faster, better and more-informed decisions are particularly valuable in a difficult business environment

(emphasis added).  Complex Event Processing is a key enabling technology for real-time business intelligence. The ability to abstract “rules” out of data using analytics and then have those rules executed in real-time to match against “events” running around your enterprise bus is what will make BI achieve the needs of business to make informed decisions “faster”. Traditional BI where you feed data into a mammoth DWH and then analyse the results at some point later suffer from high latencies and reduced information currency. CEP can reduce these latencies from weeks or months down to seconds.

Web-Oriented Architectures. The Internet is arguably the best example of an agile, interoperable and scalable service-oriented environment in existence. This level of flexibility is achieved because of key design principles inherent in the Internet/Web approach, as well as the emergence of Web-centric technologies and standards that promote these principles. The use of Web-centric models to build global-class solutions cannot address the full breadth of enterprise computing needs. However, Gartner expects that continued evolution of the Web-centric approach will enable its use in an ever-broadening set of enterprise solutions during the next five years.

Recognition that SOA is more than just “Web Services”and that at least one other architectural paradigm is available to SOA implementers.

Interesting that BPM has dropped from the list after featuring in the previous two years. And SOA itself has not been mentioned since the list for 2006. It looks like SOA has become more business as usual – part of the IT “furniture” – as I predicted some time ago.

In 2002 Sonic Software invented the term ESB to differentiate their middleware from everyone else’s middleware. This is an old marketing tactic when you can’t differentiate your product from the others – just invent a new category. To lend credence, you need the collusion of an analyst and Gartner was there to knock this marketechture into the hype-stratosphere. We can also thank Sonic for the crap notion that an “ESB is a prebuilt SOA“.

ESBs have been back in the news again with the usual attendant vitriol and this has revived the perpetual question – “what is an ESB and why do I need one“?

I’ve seen ESBs referred to in two rather broad contexts. The first context refers to a distributed infrastructure that allows your Service Providers and Service Consumers to find each other and work together in a scalable and loosely coupled manner. This is often referred to as the “ESB as design pattern” and I think it is what many people would like ESB to mean. This “Service Bus” is effectively an extension of the “Message Bus” concept and is what I had in mind when I wrote about this subject a while ago.

The second context is ESB as a tool or a “thing you buy from a vendor” and this seems to be the terminology that calls forth all manner of vituperations. In this context ESB is secret marketing code for what used to be called “integration middleware.” This is also the thing that Jim Webber calls the “Erroneous Spaghetti Box.”

In this context, the eternal ESB question becomes – “in an SOA world, do I really need integration middleware?” I really think you can make more sense of the ESB debate by recasting into this terminology. The SOA pragmatists (including myself) see that there is a role for “integration middleware” as tools within your SOA infrastructure.

Eric Roch thinks of an ESB as a “productivity tool for integration” and points out that The legacy integration problem hasn’t gone away yet.

ZapThink say that an ESB could play the role of a Service Intermediary where transformations and content-based routing are essential requirements.

Todd Biske characterises five different types of ESB product each supporting different functions such as legacy integration, orchestration, mediation and transport, SOAP wrapping and gateways. The key insight here is how the label “ESB” has come to be applied to so many disparate products. “ESB” has come to mean everything and nothing and should be banished from our vocabulary.

So I agree with the pragmatists – design your SOA infrastructure to support your business requirements. Consider the so-called ESB products as tools and if you need mediation, or orchestration or transformation or integration to legacy systems then consider using the scads of tools – both proprietary and opensource – out there that support this stuff. And whatever you do, don’t try to author XSLT using Notepad.