I was reading Steve Martin’s latest blog post about Microsoft being named in the leaders quadrant of three different Gartner reports. Microsoft was certainly in the business of providing the building blocks of SOA at the start with ASP.NET web services and we have seen that evolve to support different standards and eventually to become WCF and all the continually evolving standards like REST. I think this is great for Microsoft and validates their approach to SOA. I feel it is a good, practical approach to implementing SOA and gaining business value. I guess I should back up and explain what I mean by the Microsoft approach to SOA.

I see many organizations trying to implement a SOA solution and the solutions tend to fall somewhere along a continuum. At one end is the side that emphasizes the architecture and operational purity. They want to design the entire architecture with the interfaces and the interactions and business processes. At the other end of the spectrum is the group that just starts creating web services and calls that SOA. Of course there are a lot of different shades in between.

The Microsoft approach as I call it has always been to lay plans for grandiose implementations but to make sure that you are getting value out of those plans. The catch phrase that I hear often is “plan, but don’t boil the ocean”. I certainly can relate to this as one of the projects early on in my career was to help a large company standardize a bunch of different databases into a single consolidated database to reduce redundancy and help with reporting. The project spent almost 2 months trying to get everyone to agree on how to create the customer table and where the data would come from in the different systems. In the end the project was cancelled because it was going nowhere fast and eating up a lot of time and money. We ended up creating a reporting database to give them the value they wanted without all the arguing and planning. (This was before data warehouses were mainstream.) The Microsoft approach has also tried to avoid long cycles of analysis followed by implementation but has instead concentrated on creating a SOA implementation for new projects and adding a SOA interface to existing systems. By tackling the architecture a piece at a time you can run into problems where your implementations or standards evolve and become incompatible. (This is where the ESB comes in but that is a different post.) For some reason Microsoft didn’t do a really good job of explaining their value proposition so the lack of an ESB and other “required” pieces of SOA would leave them ranking low in the various analyst reports.

It is nice to see that a pragmatic approach to SOA is being recognized as being a viable approach and just one of many on the continuum.