Debunking the Analysts on Microsoft SOA Strategy
This was originally posted by meon our Intergen Company Blog. Reposted here for completeness.
Service Oriented Architecture: everyone is still talking about it. Recently there was a bit of a blog-o-thread happening among a bunch of US analysts about Microsoft’s SOA strategy. I refer in particular to articles by Lorraine Lawson at IT Business Edge and Dana Gardner at ZDNet.
Gardner is right when he says ‘SOA is a style and conceptual computing framework, not a reason to upgrade.’ Yet, maybe through lack of time at the coalface, he thinks that massive upgrades are required to put this framework in place. The answer couldn’t be further from the truth. The vision of SOA, that is systems demarcating themselves into atomic reusable services accessible by explicitly defined interfaces and open protocols, is easily implementable in the old faithful .NET 1.0 of several years ago. Sure you may not be able to pass transaction scope across interface boundaries or rely on non-transport level message delivery guarantees, but if people are required to upgrade in pursuit of these features then it must surely be called for what it is - the evolution and maturation of the entire SOA ecosystem - there were no vendors offering this six years ago, let alone Microsoft.
Even among its chief critics, Microsoft is considered a key initiator and implementer of the broad set of WS-* standards. The irony of the criticism levelled at Microsoft in the above articles is that, unlike the other vendors mentioned, the Microsoft stack does not require expensive application servers (beyond the operating system and the cost of that pales against say WebSphere) to actually make the conceptual framework of SOA a concrete reality.
Criticism is levelled at the Connected Systems Division vision of agility in SOA applications. Having seen the future, to an extent, this is somewhere that I think shows great promise. It’s arguable whether we’ll actually be able to compartmentalize enterprise applications much longer. Increasingly I see organisations where our approach, even in relation to users on the ground, is about surfacing features out of a broader IT ecosystem within the organisation. The future of IT agility will centre on the recombination of existing services and function more than it will the creation of new ones.
Lawson’s focus is a lot closer to the coal face. However twice in her post she notes some association between what she calls ‘Open Code’ and SOA. For example:
“I think what’s confusing matters is Microsoft’s inability, thus far, to reconcile SOA’s demands for open code and standards with a business model that’s thrived on proprietary solutions.”
This could not be further from the truth. While SOA certainly demands Open Standards it most explicitly frees us from the need to have ‘Open Code’. By making the boundaries of the application explicit and well described we are freed from knowing anything of their internal workings - if communication with a service requires us to see the ‘Open Code’ then we have surely failed. The SOA landscape and vision is very much one of highly optimised proprietary systems communicating by way of poorly optimised, but open, protocols. As Microsoft moves from a Desktop and Operating Systems company to being a broader vendor of both those tools and more vertically focused platforms it is inevitable that those teams, at the very least, will see the value in exposing their revenue generating applications for use by other vendors platforms. To ignore the need to have Sharepoint Server or Microsoft CRM participate in a broader Serviced ecosystem is to ignore a good portion of the market who don’t buy into the Windows Everywhere vision.
.NET|Wednesday, 26 September 2007 03:27:51 UTC||
While analysts in glass towers gaze at their Service Oriented Navels, there are a good chunk of us out in the world making at least part of their utopian vision a reality. They would do well to talk amongst us in addition to themselves every once in a while.