 Video streamVideo streamVideo stream |
 |
 |
|
|
|
| Question indexQuestion indexQuestion index |
|
|
|
|
|
| Interview transcriptInterview transcriptInterview transcript |  Discuss this interviewDiscuss this interviewDiscuss this interview |
|---|
|
Sure, I got started in the early 80s when I went to Tandem Computers, after dropping out of college - I
figured I needed a real job - and I spent most of that time working on a product called TMF - Transaction
Monitoring Facility - which is the foundation for Tandem's non-stop systems, it does the database logging and
recovery. And then after that, I did a little dallying doing hardware design with multi-processors. And after
that I came to Microsoft in '94 and started a project that became the Microsoft Transaction Server, now part of
COM+. Since then, I've worked a lot on asynchronous messaging and loosely coupled systems. And now I'm in the
.NET Enterprise Architecture team, trying to help our customers understand, what are the issues associated
with, distributed architectures, and in particular service-oriented architectures. Sure. I think it's an exciting time to see the changes that have happened, because we started out with a
single machine, a big momma mainframe. And then, as we started getting more mini computers working together, we
tried to make them look like one system where everybody trusted everything, you've got to do distributed
transactions which is a way of pretending that all of these changes either are on one machine even though
they're not. But the problems associated with that have to do with the issues of independence, autonomy and privacy.
Can I, as an organization, have my machine, and still work with your machine, your application, in a way that
ties things together while allowing me to grow and you to grow without asking permission. In some ways it's a
lot like having, you know, a four engine airplane that can fly on three engines. They have a lot more failures,
but if you can fly on three or two engines, you have better availability, you have the ability to change and
evolve things. And that's where we're seeing this trend away from tightly coupled distributed object systems, which are
fine and they work great, and they solve a problem. But you have those systems sitting here solving one
problem, how do you connect into a system solving a different problem. So, it's really a fascinating inflection point in the industry as we start looking at taking lots of
different machines, different systems and allowing them to work together, while maintaining their independence,
while maintaining their autonomy, while allowing one to be evolved independent of the other. Well, I think this direction is mostly characterized as service-oriented architecture. That's the
buzzword that we've applied. But what it really means is allowing the systems to work together while not
sharing more than just the message formats, the schema for the messages, and a contract describing the
interaction sequences of those messages. There's policy and things like that, but it's about not knowing much
about the other machine. When I call up to make an airline reservation, I don't know what kind of machine they've implemented it
on. When I call up to make a hotel reservation, or to order something from Amazon or Barnes and Nobles, I don't
need to know about what their machine is like. I'm working across a trust boundary, and what I need to know is
what I need to say, and what they need to say back to me, and how we can come to a co-operative solution.
That's the new cool thing that's happening. (With) Distributed objects, you know so much about the other side. And in this new world you know very
little and it allows for independent evolution and allows for a lot of features, a lot of cool things. Distributed objects are still very important. But let me first back up and say: Objects are very
important. If you want to think about a service as a boundary across which trust is maintained: Inside the
boundary, I trust, across boundary, I don't. That's the idea behind services. God bless objects! You just want
to use objects. They're an incredibly powerful technique for how you do software engineering. Sometimes that application is spread across multiple machines. We've seen that more and more, as adding
machines was helped us scale out. Now, as machines get more and more powerful, a lot of these applications are
going to fit back on one machine, where they didn't fit upon a single machine before. And so, I think objects are the important thing. Distributed objects, that's fine, you can use them
wherever you want to, but I would put the emphasis on services as the key way to hooking together disperate
things. And then when you implement each individual thing, objects are just a wonderful, wonderful technology.
You have to understand that I get paid to think of far out in the future, right. That's my job, is to
say: What are the economic trends and what are we thinking about as we move ahead? It's going to be a number of
years before people stop wanting to do multi-tier deployments in order to be cost effective. All that's said
and done, Moore's Law seems to be on an inexorable trend, getting larger and larger, and machines are getting
more and more powerful, and so as time moves on, it becomes less interesting to distribute them across multiple
machines. One thing to remember: If you have a distributed object solution, you're solution is having
challenges if the machines are not all up. Actually, the forces, they're mitigated with humans. Mostly, you've had people interacting with other
people, and behind the people they have their computer systems, right. And so, as businesses have worked
together, historically, it's been, you call up and talk to a reservation agent. Or you do whatever it takes to
fill out a form and drop it in the mail in order to get the work done. Now, we're starting to get to the point where we can see that we can actually eliminate more and more of
the human touch in making these things work together. And that doesn't need to be a black and white. I think
one of the mistakes we've made with B2B computing, is that we assume that we have to be 100% programmatically
connected. And I point out: Gee, if you've got people in there doing all kind of this stuff, if eliminating 20%
of the interaction is a lot of money, it's a lot of savings, it's fantastic. Because then what you can do is
you can take that money, you can reinvest it, solve a few more programmatic problems that people used to have
to do, and maybe raise that bar to 25% or 30%. And that then ends up being low hanging fruit that can allow you
to tie these machines together. So, it's just thinking about these independent systems, and beginning to get them to wok together
without having humans being the lubrication that allows it to work. Well, when you've had a couple apps that have been independently designed, they have different
assumptions about the world. Different assumptions about inventory, different assumptions about customers; they
probably don't even have the same snail mail address format. It's a lot like: It's true that we can connect the
bytes back and forth with IP and TCP today, but that doesn't do me anymore good than if I can pick up the
telephone and talk to China, and if I'm speaking only English, and they're speaking only Mandarin, we still
can't communicate very effectively. Here's some cool sounds, but it doesn't help get work done. The same thing's occurring when you bring applications together. The semantics of the interaction is a
challenge. It's very, very difficult across an enterprise to get a common understanding of what a customer is,
is a great example. Because, this half has got these fields, and that half has got those fields, and maybe you
can get some common fields of understanding, but there's still all these differences that are in there.
A huge advantage that we have is XML. XML and XML Schema, and XSD have allowed for at least the
expression of what the data formats look like, even though that hasn't helped with all the semantics. But it's
a good start. We don't have to worry about parsing, we don't have to worry about a lot of those details. But we
still have a huge road ahead of us in terms of rationalizing how we understand the data across differently and
independently designed applications. Well, I think it's a fascinating area. There's a lot of what we can learn by looking at history. And to
me, there's a strong parallel between data, and how you represent structured data, and what happened in the
late 19th century with manufactured goods. All these cities were independent and they weren't connected. You
know, you would go to one company and they would have their own nut format and their own bolt format, and you
would put them together and they would match within the company, but there were no standards across different
manufacturers. As people try to start making things work together, the economic forces demanded that these
things worked and be able to hook together. And so what happened is some manufacturers were in a dominant position and they were able to take their
standards, and say: This is how we're going to continue to do it, and others then had to adapt to that. Some
industries got together and there were consortiums that said: Okay, here is what we're going to do so that we
have a common agreement of how our parts will work together, but largely it happened by people having a good
design, and then other people being able to make compatible parts that fit with it. You're going to start seeing that shaking up in the horizontals and in the verticals across the industry
as people have applications that need to work together and some apps are going to change because they are going
to have to adapt to whatever the common understanding is across the industry. And so this will be an exciting time as we see things evolve, as we see things change so that they can
interoperate, so that they can work together, and can have a common way of understanding the data formats.
EDI was a fantastic thing; that's the first thing. Yes, it was our grandfather's format, I'm not trying
to say that. Yes, it was in binary and it's not as cool as we have in XML. But EDI was pretty rigid. It didn't
allow for extensibility and flexibility, and so it had one pretty particular way of doing that. And that became
brittle as the applications evolved; it was harder for EDI to change. There's a lot of money in EDI today, so
you should tip your hat with respect, you know, at this data representation. Still, I do see more exciting
things happening that are going to go a lot farther than EDI has gone so far. Well, you hear a lot about EAI - Enterprise Application Integration - and B2B - Business to Business -
and those are both important things. I mean, in EAI what you're trying to do is take your existing applications
and make them work together without humans in between them. And that's where services could be very powerful,
because we're talking about the messages that flow between these applications. That's very much like what goes
on in B2B, where you're actually going from one business to another. There is a subtle difference between the two of them, in that EAI, you need to have federated
infrastructure across your enterprise. You need to have solutions that are thinking about identity management,
security management, just management, to distributed directory and naming, all of those problems that it takes
to run your application, run you enterprise, your IT ship. And so, it's EAI, B2B, they're very, very important,
but when I think about services, I fundamentally prefer to call it HST, or Hooking Shit Together. Because, Hooking Shit Together emphasizes the fact that I've got two things, they're separate, they're
independent, and it's about: How the heck do I make them work together. That then takes me to messaging, that
then takes me to Schema, that then takes me to the contracts and the flows between them while allowing them to
be independent. I think there's far more in common in doing that inside an IT shop, and doing it across IT
shops, than there are differences. So I actually like HST because it emphasizes what's in common about tying things together across
machines, without regard to whether they're in the same company or not. It's about all the different pieces. You can't find a real enterprise that has a single standard. I
mean, if you have a standard, just wait until the merger and acquisition. Or wait until the CEO plays golf with
his brother-in-law who's selling some application that's running on a different platform. All the real
companies out there have got stuff from different vendors. And it's just a matter of hooking it together, and
talking about: What do you know? Well, the cool thing about a service-oriented architecture is you know very little about what's on the
other side. I'm always mindful of that cartoon I saw which showed a dog typing in a terminal turns to his
friend, another dog, and says: On the internet, no one knows you're a dog. In a service-oriented architecture,
no one knows what kind of a platform you have on the other side. And no one should know, and that allows you to
keep them separate, to grow them separately. And maybe, make a decision - if it's a business decision that
makes good sense for your business - to replace it with a totally different platform and still continue to do
that interoperability. It reminds me so much of how cities grow and evolve. One building gets torn down and rebuilt, and
another stays right next to it. The streets become something that last much, much longer than the individual
buildings themselves. And as you start thinking of enterprise architecture, you have to think about: What is
the lifetime of something I'm designing? Is this interface going to really be around longer than the
application? That's not an unusual answer. A lot of times the application gets replaced and yet you have to be
compatible with the way you get in and out of that application. So, it's important as architects to think about: What are we trying to do for our business, how are we
trying to accomplish it for our business, and what can we sit down and design, and what longevity will it have?
And the other important piece to that is, one totally needs to remember, you're going to have different
machines from different vendors, that heterogeneity is going to come at multiple levels. It's going to come at
the hardware, it's going to come at the operating system, it's going to come at the database, the middleware.
And then you get the into this world of applications where there's so many different design points, and each of
those is going to have to have ways of interacting with the rest of them. It's a cool business; it's an
interesting thing to look at. Well, I would argue that the biggest best practice is pragmatism. Don't do anything unless it makes
financial sense. So if you have an existing app that is just sitting there, and it's this historic monument
that was built a long time ago, you're not going to replace it, you're not going to tear it down, you're
probably even poring money into it, and you want to make that tap into something else, then do whatever the
heck it takes: Screen scraping, HTML parsing, tap in however you can get in. And maybe that application has
2000 different functions. And well, if you do an analysis that 30 of them are the ones that account for enough
that it's worth figuring out how to hook them in via service orientation, wrap 30 of them, and let humans type
away at a two tier interface on the other ones, or whatever it is. So the big guidance I would say, is just:
Follow the business sense. So, what's going to solve your business problems, in the most practical way
possible. Life is not that clean. It just isn't. You have stuff out there that you have to hook into. And you
can't walk in and say - that's like walking up to the mayor of Boston and saying: Hey your roads are crooked,
I've got a straight layout for your streets, let's bulldoze everything. That is not real. The reality is, you
have these investments, you have these things that you have to work to, and you should do whatever it takes to
pragmatically accomplish it. When I talk about how these things happen, I like to point out the easiest place to build a subway is in
Nebraska. You don't have those pesky buildings to deal with. But you also don't have the economic investment to
drive you to build that. And so, that is what people are facing in the enterprise. They have stuff, they need
to figure out how to mostly grow it, mostly evolve it and let it work together to accomplish what their
business needs. Once in a great while you decide to take an app and throw it away and replace it with something new. But
that's about as common as bulldozing a building in a city to put up a skyscraper. It happens, but it hurts, it
costs, there's emotional investment in bulldozing that thing, there's pragmatic investments in bulldozing that
thing because you've got to go and figure out how to solve problems during the transition of taking one down
and putting one up. So mostly, people do a retrofit and figure out how to shore things up to accomplish what
their business needs. Service-oriented architectures allow you the tools to make whatever business choice fits. Because it
talks about these being independent things, that can then hook together with others, using messaging, and using
the sequences of messages that flow. And so, that then takes the decisions of about what you bulldoze and you
don't bulldoze, and puts it back where it should be in the pragmatic business guy's hands. Well, I usually think of three broad categories for using services. One is if you're building a fresh
app - it doesn't always happen that often - but you start out, and you can actually use your services to cut
your functionality into a bunch of different pieces giving you scale out as you spread the work around. One
cool way of thinking about that is that I can have the front end that does work - kind of like shopping baskets
do, you see this in websites a lot - and that can scale out, and then you use messaging, to tie back into the
backend system. You see that in all the big websites where you're doing the shopping, and then you push Submit
and it goes to the backend system. So, scaling out is one answer. Another is where you're taking an existing application and you're trying
to cleave the part - and I like the word cleave because it's its own antonym, it actually means the opposite of
itself - and so, as you cut that application into different pieces, you have to figure out: Can I pull the data
apart without too many entanglements. It's not always easy. Can I take the logic apart, and allow, maybe, this
piece of code to be running separate form that piece of code and then put messaging in between them as I cleave
them apart? And then, the third category is where you actually take differing apps that were independently designed
and bring them together, cleave them together as you cleave to your wife. Sometimes I want to talk about
cleavage a lot, but you know, that's really a great point to talk about apps being cleaved together, or being
cleaved apart with services. And what's interesting when you go in and look at these, is that taking applications apart has a huge
challenge when people have read the data from other parts and are looking and it's too big of a big ball of mud
of entangled stuff that you're trying to pull apart. But the advantage to those cases is at least you have a
common understanding of what those data types are because you grew up in the same neighborhood these parts did.
Bringing differing apps together sometimes has the disadvantage that you don't understand things the same way.
You have different interpretations of what a customer is, of what an item is. These kinds of things. Well, I've been thinking a lot. I'm a history buff and so I've been thinking a lot about the evolution
of cities, and how that has strong parallels in IT. And as I've gone through I've flushed out a metaphor and
I'm working to write it up even more, where you look at an IT shop, which has grown up independently from other
IT shops, as a lot like a city that grew up independent before being connected by the railroad, right. And that
connection by the railroad let people go and see other places. Now we got the internet connecting IT shops. So you can then see a parallel between transportation and
communication, where the railroad would let you bring people and raw commodities over to other places, but it
didn't really solve the problem of making things work together. Just like the internet, you're bringing data
back and forth. We can shovel bytes around, but we can't really make all the structured data work. And as I thought more about it, I've seen parallels to manufactured assemblies and virtual enterprises.
Also, some really interesting parallels about how you see retail and distribution paralleling business process.
And we saw some amazing changes occur in manufacturing when standardization kicked in. Things like, as clothing
size becomes something where you can go buy a shirt that's either a little too small, or a little too big. But
because of that they get to stamp them out like crazy. In the early 19th century, you would go and get hand tailored things. And now I feel like I'm trying to
tell people: Know, what you want is less accuracy. You want stuff that is, you know, okay, it'll work just
fine, but it's not quite up the snuff with all those customized things. And what happened then, is that by
putting things into standards, by making them interchangeable, you were able to have a lot of common goods and
a lot of pre-manufactured stuff, and we're going to see a lot of that in applications. When I look at a typical interface application today I see a lot more information coming back from the
app than I need to get done what I want to get done. I may be ordering inventory, I don't need to know the
inventory balance. I need to know that if I'm ordering ten widgets, and I need the by Tuesday, what's the
probability I'll get then. I don't really need to know that there's 40 In the warehouse right now. And as we
allow those changes to occur, we can start seeing more interesting integration of apps where the interacting
applications know less about what the other one does, but really focus on what they need to accomplish their
task. |
