Search Results for 'WOA' ↓

Gartner 2008 SOA User Survey

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.

Web-Oriented SOA

A little while ago I expressed my dislike for the term WOA on the grounds that it refers to a style of SOA and my feeling that new TLAs just lead to more confusion. Its good to see the ZapThink guys are in full agreement and state their case in their trademark inimitable style.

While the WOA concept does indeed provide deeper insights into how to best implement a Service and create an infrastructural approach for scaling Services, we simply don’t see a need to identify this as a truly separate architectural approach…

ZapThink believes that the term Web-Oriented SOA represents greater clarity than WOA, since it disambiguates the desire to position WOA as an alternative to SOA as well as more accurately positions the concept at a lower level of abstraction than the SOA concept. Going forward, hence, we will prefer the term Web-Oriented SOA over WOA, since it provides greater clarity. And clarity is exactly what companies today need to make SOA a reality.

My emphasis added – hear hear!

But I still have a problem with this terminology. It doesn’t exactly roll off the tongue and the use of “oriented” twice in the same term is really ugly. Moreover, we’re still mixing two levels of abstraction into the same term.

“Web Oriented” is a reference to the style of implementation of the Services which comprise the SOA. So wouldn’t it be better to use the terminology “Web Oriented Services”?

To take it a step further, I think we can do better than “Web Oriented” in categorizing the Service implementation. The two main Service implementation patterns that we have in the current debate are implementations based on Web Services standards (ws-*) and those based on REST. A key differentiator between these implementation styles is that Web Services are based on an “interface description” of the service, whereas REST is based on a “resource” as the key entity that we operate on.

Hence I propose the terminology “Interface-Based Services” to refer to the ws-* Service implementations and “Resource-Based Services” to refer to Services implemented in a RESTful manner.

So at the top of the ontology we have SOA – our architecture comprised of Services as first-order citizens. Those Services may in turn be Interface-Based or Resource-Based in their implementation. Note that an SOA could quite easily comprise a combination of Resource-Based and Interface-Based Services.

I think this nomenclature is clearer…but it won’t catch on because these are not TLAs!

Web2.0 Informing SOA

In “Web 2.0 success stories driving WOA and informing SOA”, Dion Hinchcliffe writes about how enterprise SOA can learn from the successes of Web2.0 and WOA*.

“…since there’s little question that the core ideas behind SOA seem to be the right ones. Rather, it’s been how we’ve gone about designing and implementing SOAs that appears to be at the crux of the issue. As we look at the most successful examples of SOA actually working, we keep being drawn back to the Web itself.”

Along the way Dion points out a couple of differences between the Web and the enterprise which I think are pretty salient and underscore the issue that its not the technology that divides the two hemispheres of the service-oriented world.

“One big issue…is that enterprises are often very much unlike the Web. Many of the aspects that make the Web successful…just don’t exist in the enterprise with it’s wilderness of relational databases, proprietary applications, and silos of every description, despite some success in adding a traditional SOA layer on them.

The article Dion references in the last quote has this great summary graphic:

Web versus Enterprise

But in addition to the technical differences between the Web and the Enterprise, I think it is worth mentioning some fundamental cultural differences:

  • The participants: When it comes to Web APIs that have been so successful, the conversation is basically between technologists. By-and-large it is technologists that are writing the mashups that demonstrate the success of Web2.0. Conversely with SOA in the enterprise, the conversation is (supposed to be) between technologists and business – and plenty has been written about the lack of success there.
  • The success criteria: There are different success criteria for Web2.0 versus enterprise SOA. Very few Web2.0 companies currently make money out of their APIs. Success for Web2.0 is “eyeballs” and VC funding. In the enterprise, SOA success is all about hard ROI.
  • The legacy: Most enterprise services must build on legacy applications, whereas Web2.0 applications are mostly greenfields and purpose built for the Web. Legacy applications rarely expose “resources” directly. If you’re lucky, the application exposes API methods which encapsulate an awful lot of business logic around a resource.
  • The standards: Also part of the legacy is that WOA is “an emergent set of best practices…not a formal set of standards.” Let’s face it, WS-* are a formal set of standards designed by disparate committees often with competing agendas and ulterior motives. The structure and evolution of these standards has not been optimal for the users.

Fundamentally, I agree that Web2.0 in the enterprise and REST approaches to SOA have a lot of value and can teach us how to do SOA properly. Conversely REST needs to address enterprise concerns more fully. The key is recognizing the commonalities and the differences so that we can hit the sweet spot in between.

* BTW I’m not a big fan of the term WOA to denote “Web Oriented Architecture” or REST-ful approaches to Services. While I understand that distancing REST from WS-* makes good marketing sense, ultimately I think we are all talking about Services – so WOA is really a style of SOA. Jockeying for market position/dominance/discrimination has already got us into such a mess.