In-Depth

Q&A: Microsoft and Service-Oriented Technology

Steve Martin, director of product management for the Connected Systems Division at Microsoft, talks about shaping his company's SOA strategy.

• By Ed Scannell and Chris Kanaracus
• 08/01/2007

It may also prove to be one of the most important strategically. The team Martin oversees is smack dab in the middle of many of the technologies Microsoft hopes to build its service-oriented initiatives around.

Martin sat down with Redmond Editor Ed Scannell and Chris Kanaracus, news editor of Redmond Developer News, to talk about a range of topics, including Microsoft's under-the-radar approach to the Service-Oriented Architecture (SOA) market, what he believes is the next major evolution in service-oriented technology and why Microsoft will be on the leading edge of it.

Over the past few years Microsoft has appeared reluctant to talk much about Service-Oriented Architecture, or even to use the phrase. What should people read into this?

The only thing they should read into this is that we're trying to remain above the hype. But increasingly over the last several years we're giving prescriptive guidance on not just the "how to do service orientation," but about observing the kinds of applications people are developing, including composite or SOA apps. We ask them: Are those apps core business practices, things that help differentiate their organizations? Or are you really using SOA just to wrap legacy investments and expose them in a service-oriented way to do essentially a new generation of EAI [Enterprise Application Integration]? Either is fine, but we think most organizations in the last several years have focused on using a service-oriented approach to solve intra-organizational connectivity issues. There's plenty of value there. But the next frontier for service orientation is the cross-section of SOA and BPM [Business Process Management].

Why do you think this intersection represents the next major evolution for developers?

From our perspective, SOA is a "how." It's a way to accomplish something, and BPM is a "what." SOA isn't very interesting by itself if it's just being a new version of EAI. It could be better, faster, cheaper -- and there's great economy in that. But with service orientation you have access to applications in a high-fidelity way, and that's the BPM side of things. The types of apps we see users building now that sit on top of SOA are things that truly differentiate the business and aren't things they can buy off the shelf. They are their organization's secret sauce.

What makes Microsoft's service-oriented strategy different from your major competitors, such as IBM Corp. and Oracle Corp.?

A couple of things. As I said, we've always talked about SOA as a how, not a what. So the first guidance we give users is that SOA for SOA's sake is probably doomed. You need to be able to articulate in 30 seconds the business problem you're trying to solve. If you can't do that, then you're already in a hole. You must be very pragmatic about what you're going to do and how you're going to use SOA to solve a particular problem. Within that pragmatism we coach people to take a "middle-out approach." Don't assume everything that goes into your organization must be services-oriented. Make good use of service orientation where it makes sense for either cost savings through reuse or in places where you're truly going to differentiate the business.

What are Microsoft's basic building blocks for SOA -- now and in the future -- for building a comprehensive end-to-end solution?

That's hard to answer, although I can answer from an architectural standpoint. We think about the tools that create the services themselves, we think about having a robust runtime to make sure you're getting solid performance, and we think about the adherence to the Web specifications to ensure interoperability. But we also think about how we can help users solve a lot of the management and governance issues with tools like System Center. I don't know if we've been as clear with users about how to tie this into the other pieces of their infrastructure as we could have been. But we're giving that guidance now.

How open will your SOA strategy be? Some developers and users have reservations given the range of new and old technologies they'll have to mix and match.

We've fully embraced the Web services specifications and the standards associated with that. In addition, we're starting to offer more guidance on how to use Windows Communication Foundation for building applications. Not just the WS-* stuff, but offering prescriptive guidance on some of the standards being adopted on the lighter-weight side.

Can you talk about how you'll evolve BizTalk Services and what role they can play?

We'll continue to incubate BizTalk Services. It's absolutely our intent to ensure that BizTalk Services is, at the right moment in time, a commercial offering people can take advantage of. We think we've built the world's first ISB [Internet services bus]: taking the functionality you get in an ESB [enterprise service bus] but making it work at Internet scope. One of our axioms is: Any time in history where the Internet has met the enterprise, the Internet always wins. Always. An ESB working at Internet scope means firewall-friendly messaging, building an app with the assumption that that app lives in multiple DNSes, assuming that identity could be inside or outside the firewall-then we can drive a lot of benefit for users and that's what we're doing with BizTalk Services. We think it's one of the best-kept secrets in the SOA world.

Some users have a concern that Microsoft's SOA strategy will be too tied to licensing of its core products, forcing them to buy bread-and-butter products in order to implement a complete SOA.

I've heard from users talking about a similar point. If you took our stack that you need to build a complex SOA with full management, customers quickly find that we're not only the most productive but also the most cost effective. You can compare our numbers for the technologies, and we'd advocate in building that complex SOA app against IBM or Oracle or anyone else. Our middleware offering -- even for complex scenarios in BizTalk Server -- on average sells for about one-seventh the cost of our competitors' offerings.

What's the best story you have here for CxO-level people in terms of ROI over the short term for SOA?

Well, one thing is the focus on core processes and using service orientation to build highly agile composite apps -- the things that can differentiate the business and require a great deal of customization and ongoing care and management. That's one area that's critical for CIOs to really understand.

Some people think Microsoft is weak on the governance portion of SOA.

We're working hard to understand what the user requirements are. I think there's a lot to do today with the technology that we have. We've done a lot of work with partners on it. A lot of what you hear when you pick apart that governance onion is people wanting prescriptive guidance on how to do something, and we're working with partners on that.

The version of BizTalk coming out after the R2 version will be built from the ground up on Windows Workflow Foundation. How do you see that improving Microsoft's SOA strategy?

We made a big bet on .NET with BizTalk Server 2004, when we began to leverage Visual Studio as the native design environment. Now that .NET Framework 3.0 has shipped and has some good technology in it for workflow and for messaging, we feel the technology is very compelling and is something we want to utilize in future versions of the product. But right now we're focused on getting R2 shipped and making sure that's the highest-quality release.