Does Microsoft need a SOA strategy?

Whether or not Microsoft actually has a SOA strategy is far from clear (in the sense of actually committed to SOA in a strategic way as opposed to covering the bases in sufficient depth to be credible through alliances and product tweaking).

However, its latest announcements around BizTalk seem to have sparked off another wave of attacks from people who are deeply suspicious about its commitment and motives. For instance, Dana Gardener of Interarbor, really lets rip:

“My take is that inside of Microsoft its aggressor A-types are all about dissing SOA and promoting .NET ad nauseam. At the same time the Microserfs and developers must understand the inevitability of SOA for at last a portion of the most advanced and innovative enterprises’ and service providers’ architectures.”

To quickly jump off the fence: I don’t believe that Microsoft is as any way close to being as commited to SOA as most of the other industry majors (IBM, Oracle, Sun, SAP et al). However, this may not be a bad strategy for Microsoft right now. The reasons why this is so are well expressed by The CIO Weblog:

“Microsoft doesn’t have to have an SOA strategy now, anymore than they needed an Internet strategy before Netscape or a search strategy before Google. …A recent IDC research report shows them holding a comfortable lead in the architecture and platform development tools that will be used to build out whatever SOA most companies will bother to develop in the near future. And as frequently been pointed out, here and elsewhere, it’s not so easy to break the inertia that large corporate IT shops generate when they make those initial choices. Microsoft has plenty of time to manuever, and as of yet, little need to do so, clamoring of pundits aside.”

While many would argue that Microsoft’s lack of internet and search strategies significantly damaged the company, it is not an unreasonable argument for SOA if you consider their customer base: The smaller Microsoft only shops aren’t in the first waves of SOA adoption anyway, the larger Microsoft only shops will be bound to use Microsoft tools and finally the large enterprises which are a mix of Microsoft and others (I would suggest these are vast majority of the “the most advanced and innovative enterprises” mentioned above) will use Microsoft tools in their SOA strategy when needed.  Why? Because SOA is an architecture – not a product category: You can get started mostly using exsiting tools.  Therefore, Microsoft are guaranteed to be in the SOA programme frame anyway and so doesn’t need to try “to win” its share of initial projects.

So, are there risks for Microsoft and its customers associated with its take on SOA? Yes, I think there are major risks and these will become apparent over the next 12 to 18 months: Firstly, as customers who mix Microsoft with non-Microsoft get deeper into SOA, they will move beyond relying on existing tools and need more and more tooling designed specifically for SOA.  This tooling is more likely to come from vendors who have a deep SOA commitment. This will risk Microsoft’s share of the pie in the large mixed accounts.

Secondly, as IBM et al create SOA-based solutions for common emerging customer problems (think the next Basel II or Sarbanes-Oxley or CRM), Micosoft will be disadvantaged because the SOA based solutions will be more consistent with the customers’ existing architectural direction (i.e. SOA). This will not only limit their growth in the mixed accounts, it will also limit their ability to enter new large enterprise accounts.

Of course, this is all predicated on SOA remaining a popular and growing architecture … and however unlikely it may seem today to SOA advocates that SOA could hit a wall, this is probably Microsoft’s real bet.


Posted in Imported, microsoft, SOA, Vendor news.

Leave a Reply

Your email address will not be published. Required fields are marked *