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.
If you ask Steve Martin, director of product management for Microsoft's Connected
Systems Division, how he likes his job, he'll tell you with little hesitancy
he has one of the best gigs at Microsoft.
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
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
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.
About the Author
Ed Scannell is the editor of Redmond magazine. Chris Kanaracus is the news editor of Redmond Developer News magazine.