I just noticed that this blog didn't have an SOA category-serious problem in today's enterprise IT environment. So I added one and will be christening it with this post (also changed "ASP" to "SaaS" based on feedback... gotta stay trendy, I suppose).

This recent delving into the roiled pool of enterprise SOA is prompted by Microsoft's release of Biztalk Server R2 on Monday and the resulting spate of commentary on the significance it has to their SOA strategy (if such strategy exists, an idea which has been called into question lately with some frequency).

Most of the above linked authors respond to that allegation with some variation of, "They do, but it's crap." Which may be true from a certain perspective, but also tends to presume that Microsoft needs such a strategy and that it should be a good one, which in my view are questionable assumptions at the moment.

But 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. As Lorraine Lawson points out in the linked IT Business Edge article above, 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.

In recent history and despite their claims to the contrary, Microsoft hasn't been an innovator or first-mover in technology... and I would argue that it has served them well not to be so. With the market control they can exercise, it doesn't really pay for them to be out on the bleeding edge of these things (although obviously they have to give lip service to being so); far better to hang back, get a sense of the developments, and come in later with force behind something that, while perhaps not technically impressive, will be perfectly acceptable to most customers. And it's not out of the question that customers benefit from this approach as well-the cutting edge isn't always the most cost-effective point on the curve of advancing technology.

I'm loathe to defend Microsoft, not that they require it, but I think they are being taken to task too harshly in this matter and without much justification. First, I doubt what we are seeing is really a well-developed strategy yet, and I don't believe they need one yet, so there's nothing really wrong with that. Some of their customers might like to see it, but if you accept the Microsoft premise behind building out Service Oriented Architectures-that you should start small and expand the effort-then this is a perfectly acceptable pacing. Seeking to define huge, overwhelming architectures at the outset smacks of old-school, failure-prone software project management.

Second, while I'm not going to accuse them of being genuinely open or embracing community standards, I don't think Microsoft gets much credit for something that has almost always been a strength for them-the ability to accept and work with other standards, even as they develop their own. It's admittedly a problem that they won't open some of their own code and standards if you are trying to develop truly portable, service-oriented architecture, but at the same time, there is nothing preventing one from using other standards with their tools in most instances. It's easier to work with Java in a Microsoft environment than with .NET in a Unix environment (Mono notwithstanding).

I don't think this is all necessarily much ado about nothing-there are real choices to be made now by people seeking to build out an SOA environment-but I think that the commentators closest to the technology, as is often the case, are tending to overcomplicate the issues currently, and companies eager to roll out SOA are going to be able to do so without undue hindrance based on platform (well, other than all the conventional hindrances that come with using Microsoft as a platform, but those belong in another article).