| QUESTION & ANSWER |
Enterprise SOA versus departmental SOA |
 |
By Rich Seeley, News Writer
19 Jul 2007 | SearchWebServices.com |
|
|
In his role as vice president of SOA products webMethods/Software AG, Miko Matsumura, has been traveling across North America and Europe talking about service-oriented architecture (SOA) as well as teaching in the SOA Master Class that he helped launch last winter with the ZapThink LLC analysts to address the SOA knowledge gap. At the beginning of 2007, we talked to Matsumura about what he expected the year would bring for SOA. Two calendar quarters later, we wondered what he is seeing so far. One of the trends is a bifurcation of the service-oriented approach into enterprise-wide business alignment, which he calls "big SOA," and more modest departmental type projects, he calls "little SOA."Since the first of the year, what trends are you seeing in SOA development and adoption?
Miko Matsumura: The industry is going through a lot of interesting dynamics. One of the things that people are realizing is that there's a lot of interesting connections between systems. I think that there are a couple of different approaches that people want to take and I think that's reflected in some of the bigger consolidations.
Some people are using the term big SOA and little SOA to characterize the difference between those bigger consolidations or major enterprise business alignment, and smaller pilot or departmental projects, are you seeing that?
Matsumura: Yes, big SOA and little SOA. The way I would quadrant-ize it is there are people who are going to succeed and people who are going to fail. There are people who are doing big SOA and there are people who are doing little SOA. The success stories in big SOA are somewhat limited at this time. So what I think is going to be the acid test is how many of these cases can pave the way for kind of early majority to succeed. In terms of the number of people who have achieved major successes with big SOA, there are limits and constraints to how many are there yet.
Do the same rules for policy and governance apply to little SOA or can they get away with less than big SOA?
Matsumura: Big and little slice in such different ways. The question that keeps coming up in all these discussions and debates is where should you have to deal with governance. If you're dealing with a business service you better be able to govern it, because ultimately if you look at the basic service infrastructure without governance, you're talking about the inability to intermediate discovery, which means people are discovering things willy-nilly. And you're talking about the inability to intermediate runtime. If you take out the ability to intermediate discovery, it just means people are basically e-mailing WSDL interfaces in the dark and connecting up stuff that can become a tangle of spaghetti. If you abdicate the responsibility to appropriately intermediate the discovery with some kind of discovery process and some kind of a registry, you can get into trouble pretty quickly. If you give up on the registry-based discovery model that's a trouble spot.
What about runtime governance for big SOA versus little SOA?
Matsumura: In terms of runtime mediation it's different. If you don't have an intermediary that can manage runtime around a service then you really don't have any way of providing assurances about the service. Runtime governance is needed if your service has some kind of value to it. I know that's a little bit harsh, but I think that's pretty true. The point in time when you need to govern a service is the point in time where you actually have a responsibility to the consumer of the service. That's a business value question. If it's just something that people are having fun with that's one thing, but if it's something where there is a business consequence to unavailability then governance becomes the process of managing and ensuring that outcome is being met. It's the thing that the SOA reference model calls "produce desired effects consistent with measurable pre-conditions and expectations." It's a bit of a mouthful, but a service has a service consumer who gets served. Their overall experience of being served is fundamental to the notion of service orientation.
Another problem we hear about in big SOA is that across the enterprise there are issues over who controls data that might previously been in silos. Where are we with that problem?
Matsumura: Here's my take on it at some level. If you look at the reference model definition it basically says that SOA is the paradigm for organizing, utilizing, distributing capabilities that may be under the control of different ownership domains. So that opening sentence in the definition jumps immediately to this notion of, "Hey, like there are different people who might own different parts of this whole thing." Which is kind of a strange thing, like a time-share condo or something. So, the thing that I think is interesting about it is there is traditionally two dividing realms. There is the realm of information, which tends to be lightweight and kind of like "Oh, by the way," and you can think about it in terms of the World Wide Web and knowledge management and data sharing and things like that.
And then there tends to be this concept of asset, where you have, "Well, we have a server and we need to control access to the asset because if someone overuses the asset then it can start to slow down or whatever." Whereas data is one of those funny topics where it's like, if you make a copy of the data or you keep spreading the data around, it tends to increase in value rather than decrease in value. It's not like, "Oh, you used up my information and now I can't have it." So, that's the natural propensity of things.
What I think is kind of funny about it is, that rule of thumb doesn't always apply. Like for example if you look at the director for national intelligence under John Negroponte, he basically has the challenge of how do you federate intelligence in the government so you can catch more bad guys. So, the problem becomes in those organizations, the information is the asset. It's like, what do we invest and what do we imbue value in. And it's not that the information is sort of this casual, "Gee, we'll all be smarter if we all share our data." It'll be like, "We can't possibly share this with anyone." This is very much the product of culture of secrecy and probably with good reason. If you have complex state secrets, you definitely don't want the bad guys to get access to that.
But isn't that also true in business data such as customer lists that you may not want competitors or even other departments to have access to?
Matsumura: The last thing you want to do is have someone you don't know getting access to your data. Taking responsibility is one variable, but so is getting credit. So there are P&Ls associated with this information. So, if you are the one who takes the "L" for paying for that, why would you want someone else to get the profit and the credit, or exercise your database by sending out e-mails and getting people irritated and creating absolutely no benefit for you as a division?
So are we starting to see internecine wars over data in big SOA?
Matsumura: Internecine is a great word for it and I think that's sort of typical. I think there are sort of three broad swaths. The open knowledge network view, which I think is pretty rare, which says, "Okay, let's just share information." That tends to be more the realm of content publishing and syndication, which tends to be one totally different realm. When it comes to things like personal information then you get into that realm where people start to value relationships, which are assets. And then finally you've got the third realm where the information itself, not the relationship, but the actual, "This is something that we know and we don't want other people to know it." That sort of clandestine, knowledge investment function and in those cases the information is the asset by itself and ownership of the information is considered to be a big issue. I think what we're being faced with is something that was straight out of the box at the get go, the different ownership domains and the issues that relate to governance, absolutely.
Does governance have an answer for that?
Matsumura: That's where the realm of policy comes into play. It's one of these really delicate balancing acts. One of the ways I like to describe metaphorically, the sort of SOA enterprise architects view, is that there is a potential for naïveté if you don't have the gray hairs and experience in the way that you analyze it. Let's say the CFO's office looks at it. They say, "Let's analyze the neighborhood." There ought to be enough PlayStations and bikes and basketballs in a neighborhood to cover utilization for all kids in the neighborhood. But that's a very naïve view because the reality is that there are issues that go beyond that that go with life, convenience and availability, things of that nature. And there are ownership issues.
So how do you align SOA with that reality?
Matsumura: One of the exciting propensities that people have is there are extremely well regulated relationships that exist across companies and those are business relationships that have really beautifully structured definitions and the reason they are so well structured is that they are very typically legal contracts. Frankly, internal organizations tend not to have economic structure to them. The smarter ones have things like charge-backs and shared services organizations with separate budget line items, utilization metrics and all these interesting things. Things like performance bonuses for people using your service and encouraging people to promote their service.
So an existing business contract can become the basis for SOA policy?
Matsumura: The thing that's interesting is some of the success patterns we've seen have taken SOA straight out the door to B2B. Right out of the gate. And people think that's nuts because B2B has to be ten times more complicated than connecting applications within our own house, our own family, our own company. But it turns out there is a lot more pre-built structure to those relationships and a lot more constraints and expectations around those relationships. Given that's the case, it makes it more structured and easier to deal with people who are outside than inside. It's like how people behave at home versus how they behave in public.
|
|
|
|
