BriefingsDirect SOA Insights Analysts Explore SOA's Role Through Failure, Governance, Policy and Politics

Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition, recorded Feb. 2, 2007.

Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.

Dana Gardner: Hello, and welcome to the latest BriefingsDirect SOA Insights Edition, Volume 11, a weekly dissection and discussion of Services Oriented Architecture (SOA) related news and events with a panel of industry analysts and guests. I’m your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions, ZDNet blogger, and Redmond Developer News magazine columnist.

Our panel this week, and it is the week of Jan. 26, 2007, consists of Steve Garone, he is a former IDC Group vice president, founder of the AlignIT Group, and an independent IT industry analyst. Welcome, Steve.

Steve Garone: Thanks, Dana, great to be here again.

Gardner: Also joining us, Joe McKendrick, a research consultant, columnist at Database Trends, and a blogger at ZDNet and ebizQ. Welcome back, Joe.

Joe McKendrick: Hi, Dana, greetings.

Gardner: Also joining us is Jim Kobielus, a principal analyst at Current Analysis. Welcome back, Jim.

Jim Kobielus: Thanks, Dana. Hi, everybody.

Gardner: This week we’re joined by our guest Miko Matsumura, the vice president of SOA products at webMethods. Thanks for joining us, Miko.

Miko Matsumura: I appreciate being here. It's a great group.

Gardner: Now, Miko, you joined webMethods recently through the acquisition of Infravio. How is that going? Is that officially closed now, and what's the outlook for the two companies working together?

Matsumura: Well, it’s officially closed, and it’s very exciting. I tend to take an Infravio startup perspective, and from that perspective it’s almost like there are 10 times the number of sales people to talk to. It’s a little bit like The Darwin Awards guy that put a rocket engine onto his Chevy and raced it on the salt flats. Things are going a lot faster, and it’s kind of fun.

Gardner: Cool. Is this going to be a case where it’s the Infravio tail that wags the webMethod’s dog?

Matsumura: I listened to the [webMethods President and CEO] David Mitchell earnings call last night and we had a game, a virtual drinking game, we were playing by instant messenger. Every time someone said the word Infravio, we would say,"Drink." Were we actually consuming alcoholic beverages, I’m sure we would have been pretty soused by the end of the call.

Gardner: Cool. Well, it seems like so far it's a happy match up. It’s good to hear.

Matsumura: So far, so good.

Gardner: One of the topics I wanted to get into this week, and we’ll throw this out to the entire group, is looking at failure in SOA. What is the problem with those projects that are not going well these days? We talk a lot about SOA, the business value, when the maturity is coming, and where the technology and standards are going.

But I thought it might be worthwhile to take a step back and say, "Where are the warts, and why are they there? What can we learn from that?" You’ve had some experience in the field, Miko. Many of our panel speakers are working in these areas consistently. So I wanted to ask the panel, anyone at all. Have you come across SOA projects that have not been stellar successes? And, if so, are there any immediate lessons to be learned?

Matsumura: I'll answer, since you called my name out, and since it’s also a glorious introduction to have someone say, “Yes, I’d love to talk about the topic of failures and for this they have a guest expert.”

From our perspective, the thing that is really vital about this topic is that in 2007 we’re as likely to see catastrophic failures as we are limited success. There are a huge number of moving parts within SOA, and I'm going to use that almost as a handout point to this very well-considered group of folks. We need to categorize for the listener which moving parts are more dangerous than other moving parts, because those are the things that eventually cause the thing to kind of wiggle the wrong way, and send it to a tailspin. Any thoughts about that?

Garone: I’ve gotten involved in some research in the past, and it doesn’t really relate to SOA, but the results that I see from this research have tended to point out two major areas that cause or are the main factors behind these kinds of failures. One is a difficulty in nailing down and keeping a continuous eye on requirements for an application. The other has to do with corporate backing for that particular effort within the company. It's more focused on the people-oriented things and the collaborative issues associated with deciding what to build and how to build it.

What you just indicated was that, in the case of SOA, the focus in terms of failure might be more on the technology-based pieces associated with building an application. Do you see SOA being different in terms of what actually is responsible for failures?

Matsumura: I'm delighted to have you take that approach, because I’ve actually cast this net out into this group as a very neutral test to see what kind of like fish will come out of it. I used a very generic term, "moving parts," but I didn’t specify. Your inclination was to think that I was talking about technology.

Garone: Well, people do so …

Matsumura: That’s exactly what I was hoping to elicit -- the idea that, in fact, a lot of the moving parts -- and the most dangerous moving parts -- are people. From our perspective, the system is sort of cybernetic, half-human, half-machine. The human pieces of SOA are the parts that we’ve seen in failure mode.

It’s not necessarily just the human beings themselves, but, as you described, the interfaces between the human world and the machine world, whether those interfaces are the specifications used to design applications, or the mechanisms used to manifest constraints and policies. They make sure that people, when they do fight each other, fight each other in a way that's productive, as opposed to destructive.

So, thank you very much for heading in that direction. Any one else have anything about "moving parts"?

Kobielus: I think that SOA failures are a subset of IT project failures, which are of course legendary. The most common reason IT projects fail is lack of the appropriate business justification for them. Quite often, their aims are so broad and nebulous that there are over-heightened expectations built up about how it will change the business and contribute to revenues, profitability, and so forth.

There’s a "boil the ocean" element of SOA justifications, because SOA as a set of best practices, is often pitched as, "We’re going to totally clean up; we’re going to totally clean up our development practices and our integration practices. We’re going to orient them around this new grand unifying scheme called SOA."

When projects are pitched in that way, and justified in that way, you’re just setting up the SOA project for failure.

Matsumura: I want to plead guilty as charged. I don’t want to monopolize, but I do want to say that I just recorded an SOA governance podcast on my own, the theme of which was, “Reorganizing the Billion Dollar Software Project.”

Kobielus: I didn’t mean to imply that you were the kingpin of failure, and, in fact, I figured that people who are having trouble in the field look more toward the governance value in order to help solve their problems. I thought I was giving you a soft ball not a hard ball.

Matsumura: No, I appreciate that. Anyhow, I’ll cool my heels and let the others speak.

Gardner: No, you’re the guest. That’s fine. But some of our other discussions on this weekly podcast in the SOA domain come back to the notion of systems integrators (SIs) and even management consultancies getting the lion's share of business in the near term with these things, because it is about culture, people, and process. And the user companies need to shift a lot of what they are doing in order to exploit the benefits of some of the technology and standardization.

I wonder if you agree with that. Do you think that for the next two to five years vendors like yourselves are being dragged along, or do you have another relationship with the SIs that have to get in there and monkey around a little bit with the culture to get companies to transform?

Matsumura: Being dragged along might be a tall order. The reason I say that is that we’ve learned that the people who control the SOA are the people who essentially control the policies. The policies include metadata, repository, and registry -- the kind of policies that are machine-enforceable, but also involve human factors. In a way, the model is more of an equal partnership now.

On the other hand, real system integrators like to control policy as a way to permanently set up a base camp inside an account, pour people through the door, and take over. It's something that we know they're salivating about.

Gardner: Joe McKendrick, what do you think? Is this a control issue right now? Or is there some jockeying going on among the internal constituencies in an enterprise, some of the vendor’s constituencies, and also the SIs? And who’s going to win?

McKendrick: There is a lot of jockeying going on, and Steve has pointed this out in a previous podcast as well. There’s a tension between various groups in the enterprise. I guess there’s a lack of a clear definition as to who is going to be doing what, and who is going to be controlling what.

SOA, of course, is inherently cross-enterprise -- or in theory it’s cross enterprise. An SOA that’s confined to a single silo or single piece of the enterprise, by definition isn’t necessarily an SOA. It’s another proprietary system.

I was curious as well as to what the definition of failure would be in an SOA situation. Personally, I'm not familiar with situations where an SOA, or components of an SOA, had to be rolled back, such as you’ve heard about with spectacular ERP failures. It seems that there may be heightened expectations of ROI or increased business agility, which don’t happen immediately, but components of the SOA still may stay in place and just be sent off in a different direction.

Gardner: Maybe we should define failure. I was thinking of it as an instance where these new practices and methodologies were tried, but people didn’t think they were working. There weren't cohesive approaches. There wasn’t standardization in the organization.

And, so they went back to business as usual, which would have been some of the older application-development ownership and deployment practices, silo-types of affairs. So, in other words, a reversal from a movement toward holistic services, used broadly, to "I’ve got my set of apps. I'm going to maintain control over them. And, if you have any kind of changes or requirements that you wanted to address, you can get in line" mentality.

Matsumura: This strikes to me as a way of defining retreat as a "strategic advance to the rear." There are definitely potentials for failure. Since failure is an orphan, even though success has 10,000 fathers, I can’t allude to a project I know that experienced a failure condition.

For example, a project I was involved in for the insurance industry was widely touted as an early SOA poster child by the vendor. The CIO was on the speaking circuit, which was dragging him off the field, and he had essentially outsourced the entire project toward a single source. What eventually happened was that this particular individual ended up having to leave the company.

I think that the CIO had this mistaken impression that the service interface abstraction allowed him to outsource completely the operational concerns and the implementation concerns, and eventually to treat this service interface as something like a child’s car seat, where really mom is driving.

It’s important to treat the interface abstraction layer like a saddle on a horse, which means that the only people who can successfully get from Point A to Point B are the people who have the skill of riding and controlling the horse, which is the service implementation. It’s really an abstract or complicated metaphor. It’s not hard to lose control.

The whole thing we alluded to early about this integrator setting up a base camp inside a company ... we’ve had customers who deliberately, pre-webMethods, used Infravio as a wedge and basically said, “We don’t want a single vendor to come in with a product and a set of services, because we don’t want them to control everything. We want an independent to mix things up."

There is a very significant danger of the inmates running the asylum or the integrators taking over the whole account from the inside.

Kobielus: I think that the way to define SOA failure is the failure of SOA as a set of practices that a company adopts, the company’s failure to realize the grand claims made for SOA. These include such benefits as improving interoperability, simplifying your IT environment, reducing the cost of that environment, speeding up the development of applications, and enabling greater flexibility in terms of where you can source various components, portals, databases, and integration components from.

An SOA project or initiative is a failure if it increases the complexity of your environment, if it increases cost, if doesn’t make much of a dent in the incompatibilities among different platforms, or if it locks you into a given vendor.

That’s why last week I brought up the whole notion of SOA suites. This notion of an SOA suite from a single vendor who provides everything for you seems to fly in the face of, "Isn’t SOA supposed to allow me to mix and match the BEA, Oracle, webMethods, Microsoft, and everybody else’s components in my environment ?"

If, at the end of the day, you’re a CTO and you say, "Well, here’s my SOA strategy, and we standardize on Oracle or webMethods" -- are you really gaining anything over the monolithic days of yore?

Gardner: So, we can agree that something that would be opposed to failure would be less lock-in, and that could be lock-in from a vendor, lock-in from an integrator, or even internal lock-in, where there is a very strong division within IT or some other organization that’s holding the rest of the enterprise hostage.

Is SOA a democratization type of an effect, or is it really giving command-and-control through policies that you could think of as a governor or an accelerator -- a brake-pedal/dashboard type of an affair -- where suddenly those in the organization that may not have had power before gain it? Is the failure when the control doesn’t go to the right people?

Matsumura: Yes. That hits the nail on the head. I was giving the keynote of the governance track at The Open Group SOA Conference in San Diego [on Jan. 31], and one of the questions that came from the audience was about metadata. Who controls the metadata?

This question is basically The SOA Question, because the people who control the policy metadata are the people who are running the show. The thing that we’re trying to establish here is that the SOA success model is essentially a model where there are federated controls and delegated controls. The reason why this term "federation of control" is so significant is because we’re trying to achieve a balance between the central function, the IT function, and the distributed function, or the business function.

People talk about the agility and control. If you want to balance these things, you need a mechanism that enables some amount of control by the people who are on the periphery, in the business units, trying to create agility. Then, [there comes] some amounts of control by the people in the center, who are trying to create more orthodox standardization and security and orthogonal cross-cutting concerns.

Having the wrong people controlling the wrong things is exactly the pattern that causes things to go a little nuts. The old-school model -- having one single point of control for everything -- has actually proven to be undesirable. While it is not prone to failure, it’s not prone to success either.

Gardner: I suppose when we’ve seen enterprises that are in a suffering mode, when IT and the business are not aligned or not syncing up, well, that can often be due to a cultural clash. For example, if it’s a distributed company and they try to have a distributed approach to IT, that can break down.

If they’re a centralized company, but IT is decentralized among departments that are doing their own applications -- then that could break down. But what’s probably more productive is, as you say, a hybrid approach where certain functions, let’s say procurement, should be centralized. If you can take advantage of a volume approach to your procurement, if you can go to your vendors and suppliers with a larger bid, you can get a better deal. So there are lots of reasons why procurement should be centralized.

But there are other examples, perhaps around knowledge management or around innovation and collaboration, that should be very ad-hoc, very decentralized. How can you manage both of those types of cultures across the company, and then instantiate that through how the IT department behaves and reacts? Anybody have a sense or reaction of that?

Kobielus: A SOA and a SOA initiative are a success if it gives you the ability to adapt the SOA governance structure to your actual business governance structure.

As you’re saying, your business governance structure will evolve over time. All business models change. So the extent to which your SOA initiative and your SOA governance are totally centralized and totally rigid -- but your business environment and the challenges and threats and so forth are constantly changing -- then your SOA failure will ultimately become a business failure, a failure to adapt.

Garone: I’ll concur with what you just said, but also add more in the way I look at it: I don’t necessarily see a contradiction between some levels of centralized control and being able to achieve business agility. The argument for business agility really is about making sure that you make changes quickly to dynamic market conditions and relationships, and so on.

While too much centralization may make that a little bit more difficult than it would be if everything were ad-hoc, I don’t think it makes it impossible. Of course, the world is about balance. The world is about finding that midpoint, where control and governance is centralized enough to keep things safe and secure, and to be able to take advantage of business opportunities -- where consolidation makes sense -- while at the same time staying agile. That’s really the challenge, the way I see it.

Gardner: I guess we need some standard methodologies or best practices around how to approach the whole organization culturally. That brings us into a discussion around ITIL or around what The Open Group has been doing [in terms of certifying SOA architects and the move to the "Town Planner" model of enterprise architrect roles].

Miko, let’s go back to you, do you have a sense of whether there is a legitimate standardization approach that is welling up in the marketplace?

Matsumura: I’ve just been speaking with the head of The Open Group, SOA Governance Working Group and absolutely there are efforts in this area, under the banner of TOGAF, ITIL, and other types of processes. It’s still reasonably early in the game, and what people need to understand and establish are the basic patterns and best practices. A lot of the efforts that create these extremely ornate methodologies are intended to be recipe-book and all-encompassing or one-size-fits-all approaches. I think it’s early in the game to take those approaches.

What I would do is take a look to see if there’s any precedent for a model for policy-managed systems that balance the need of a central entity and the needs of distributed entities, against the desires of the whole. If you look at it from a metaphorical perspective, for example, the federal government of the United States is a very interesting model. You have essentially a bunch of business units called states, that each have their own legislation, their own competency centers called state legislatures, and even their own executives called governors.

Those look a lot like business units to me. If you look at the notion of federation and the federal government model, what you see is this whole principle of jurisdiction. Ultimately, competency centers become the legislative bodies within these organizations. All of the efforts that I’ve seen to codify methodologies around SOA tend to focus on these competency centers or centers of excellence, primarily because there needs to be an inclusive organization for adjudication and jurisdiction, as opposed to having a model, where it’s just a single iron-clad dictator that controls all policy.

If you want to go that way, let’s just go and live in the mainframe and forget about SOA. Not that this would necessarily be a problem, we just have to do it deliberately and well.

Gardner: This is great. We’re getting at the point where world political history is perhaps a guide to how to approach SOA. Do you want a Third World dictatorship? Do you want empires extending their influence? Do we want a Pax Romana approach? Or do we want a pure democracy or a federated democracy? I’m thinking more about Star Trek, when the Romulans and the Klingons get together. If you could only get that to happen in IT, would be in a lot better shape.

Matsumura: Just to extend that metaphor to the initial theme about failed SOA ... . You can actually look at the failure modes of failed states. If you look, for example, at how you establish and foment democracy, there are some models, some really good, real-world cases about how not to establish democracy. Not to get too overly abstract, but there are a lot of practices and principles around establishing policy federation. The interest in doing so is the interest in establishing a controlled paradigm that actually serves the common good in a way that enables agility, but also enables this centralized capability of control.

Gardner: Right. If your company is behaving like Zimbabwe, you need to do something different.

Matsumura: Exactly.

Kobielus: We talk about political governance in terms of the world community. There is no one right governance model within a state or among the various states of the world. But clearly, history has been marked by individual states or groups of states playing and towing with, if you can use the word, various governance models ranging from absolute dictatorships and empires down to sort of laissez-faire, no centralized government.

But governance is an abstract concept, and you don’t necessarily want to dictate one governance model that’s applicable or should be applicable to all organizations and industries. Everybody has their own pressures, market pressures and so forth. In terms of SOA governance, there are radically centralized models in a given organization. It could be a radically centralized governance model within a given industry sector in the sense that basically one monopoly company controls an entire sector of the economy and they then dictate all the SOA policies and practices for all of their tributaries, as it were.

In the world, you have 230-something countries that are sovereign states ostensibly, and they establish various bilateral treaty relationships and also participate in various multi-lateral treaty organizations like the United Nations and NATO and so forth. Any given country is probably, involved in various international governance schemes as it were -- but also internally, from generation to generation, from revolution to revolution it’s going from centralized to decentralized. One size doesn’t fit all generations of governance.

Gardner: So, maybe we should take a lesson from the United States in Iraq, where you need to look at what you’re getting into. You might not want to just take a company and inject a pure democracy or a federated approach. In fact, each company has its own history, its own culture.

You might want to do the equivalent of a Myers-Briggs test and figure our what kind of company it actually is. Then, figure out in what way to approach governance, so that we don’t try to overstep what’s possible on a linear basis. I suppose it’s also evolutionary. Some companies might need to start out as strict dictatorships, and then perhaps the government withers away and it becomes a democracy. We’ve seen the example of Eastern Europe over the last 20 years. Any thoughts on politics and geopolitics as a lesson for SOA?

Garone: I think it’s a great metaphor. I’m thinking about the model that I think makes sense in that regard, although it’s kind of obvious, which is basically, the U.S. Constitution and the federation of states. You’ve got certain things that are up to each state, and certain things that are up to the federated entity sitting on top of all of it.

Gardner: If I could just pause you. The first step, the Articles of Confederation, which gave too much power to the states, didn’t work.

Garone: Right. So, now you’ve got a dynamic situation where some of that can change and over time. Plus you can also “amend your constitution” to make changes as appropriate. But, there was not always a set of things that are controlled by the centralized entity, the federal government, in the metaphor. But there’s also a certain set of things that those individual states need to comply with in making their own rules.

Matsumura: I just want to jump in here and talk about the U.S. Constitution, which has some key design patterns in it. If you actually look at the separation of power declared in the preamble, it says that the purpose is, "... in order to form a more perfect union." So, there’s this notion of the intent of the formation of this governing entity, which is the goal of a more perfect union, which essentially means that there’s a distribution of power and that the consent of the governed essentially be the overriding principle.

The idea that comes out of that, though, is the clause "provide for the common defense." That’s really talking about the security domain, whether it’s physical security or technical policies associated with the current data. The idea is that it actually should be a federated concern. In other words, security is everybody’s business. You can’t just delegate it to one unit and say, "It’s your business."

The earlier comment about how there’s no one-size-fits-all is absolutely the case. For example, I just spoke with a bank that's highly decentralized. I also spoke with one of our customers, Johnson & Johnson, which has 200 operating companies, and is fairly decentralized. Their central IT exerts a pretty strong coordinating function. So, we’re talking about the big picture, which is, how do extremely large entities organize themselves and how do they achieve success in that organization?

Garone: It comes down to what an organization wants -- centralized or decentralized IT functions. Getting back to the whole notion of the Founding Fathers of the United States, they were not of a single mind among themselves on the proper governance structure. You have Alexander Hamilton, who wanted highly centralized. Then you have Thomas Jefferson, the fellow who wrote the Declaration Of Independence, who wanted it quite decentralized.

And they yanked back and forth until various things happened, and that got more centralized. Then, you had some of those, like in the southern states, who felt it needed to be highly decentralized, and fought a war to try to enforce that kind of order. It’s one of these things that just keeps rocking back and forth, from one generation to another, in terms of the right approach.

Kobielus: Look what’s happening in Venezuela now with this guy Hugo Chavez. He’s totally centralizing everything, establishing a new dictatorship there. Not all of his country people are happy with that. I saw in The New York Times that a lot of them are applying for asylum in places like Spain and elsewhere. This is highly political, but on the IT front, it’s the same thing. Quite often, SOA is justified on a project-by-project basis. "Oh, yeah. We’ll do this project according to the principles of SOA," without necessarily implying that they’re trying to impose SOA practices across all projects and across all systems.

Gardner: Now the corporation as an organizational definition has been around for couple of hundred years. You look back to early mercantile activities, to some of the Dutch companies that had started in 17th century, for example. The modern company is certainly at least a hundred years old.

If we look at some of the large conglomerates, there’s a history of progression around corporations as entities in a more modern sense. Perhaps what's different now, though, is that companies are of, for, and by -- if I could borrow another political statement -- technology. Technology so permeates how a company operates, particularly if you’re Internet-facing and if you’re using and exploiting the Internet for more and more of your supply chain, your distribution, your transportation, for the way in which you attract sales and customers, and so on and so forth.

So technology now is at an intersection with the corporation as an organization, and perhaps that’s what’s forcing this need for a different look at how to organize in general, and, therefore, on how to govern.

Matsumura: I wanted to respond a little bit, too. One of the themes that emerges from our conversation here is that we’re talking about SOA as more or less of a post-modern infrastructure. What I mean by that is that some of the themes that emerge in post-modernism, post-structuralism is the notion of the breakdown of the dominant narrative, which is that there isn’t a universal "thing." The resistance to the one-provider IT stack model, the suite model, is the notion that there isn’t a single system that can rule them all, over all others, and that heterogeneity, components-wise, is the law of the day. Think about that particular heterogeneity in terms of how it functions from a policy perspective.

We talk about federations and policy context, but there’s a degenerate case, where essentially what you’ve done is you’ve created a federation of two. This means that two business units come up with an agreement, or two companies come up with an agreement, which is referred to as a contract. The reason I’m alluding to this degenerate case is that a contract is treated as a completely different class of legal structure within our governmental system, and is protected by the civil law system. When disputed parties get into contention, it’s basically a civil issue.

When someone breaks a policy held by the government at-large then it is either a federal or state issue. From the perspective of creating an appropriate taxonomy, it’s important to consider that these two cases are actually pretty different. Perhaps an attempt to establish initially a sweeping universal regime of centralized federated policy may actually be subsumed by these kinds of groupings of pairs of twos or threes -- or United Nations or NATOS -- or just the kind of loosely coupled and smaller policy domains that are built on top of individual agreements between provider and consumer pairs.

Gardner: I guess we’re somewhat fortunate that there are only about 200 countries in the world, but there are thousands and thousands of companies. So, there’s a lot more opportunity for experimentation in the marketplace and for competitive forces to play out dominance. We can see some success stories, as well as failures, and we can learn from those successes on how to best organize a highly technologically advanced corporation.

McKendrick: We talk about the post-modern corporation. Where are these companies going to get their IT? Where are they going to get their technology? We’re seeing more and more instances of companies going outside, not wanting to get involved with the bits and bytes of managing a technology infrastructure.

We call it "software as a service," "managed hosting," and various types of acronyms and terminology. But I’ll bring Nick Carr into the argument here. Nick Carr said IT doesn’t matter. It’s going to be ubiquitous, available like a utility. Any company can tap into it, whether it’s internal or external, to the point where it’s not that big of a concern.

Matsumura: I can’t resist shooting at this. It’s going to require you to follow along with the metaphor that we’ve drawn. If you can’t suspend your disbelief in the metaphor, it will be hard for you. The metaphor of nations and the competition between nations has typically been along the lines of warfare in our history.

Look at the metaphor of business at war, which is essentially competition for the survival of the integrity of your company against all others. It’s not on the battlefield, but it’s for customer value, for creating services that people treasure. In the history of warfare between governments and nations, what we found is that the organizations that leverage technology to their advantage are the ones that come out ahead.

Abdicating the responsibilities of the management of technology to a commoditized provider creates an extreme vulnerability because your competitive differentiation should not be held or embodied by some generic provider. I think even Nick Carr has backpedaled from his hard-line IT commodity position.

Gardner: I’ve noticed that Nick has backpedaled a little bit, but again we’re back to where it’s not necessarily all-or-nothing. There are going to be some aspects of technology that are commoditized, that should be accessed centrally, and there are many others -- perhaps this will change over time -- that are differentiators. Control over how your organization behaves and controls your assets and resources strikes me as something that you would never want to commoditize.

Kobielus: Think of this notion of where companies in the most post-modern age are going to get their governance structures from. I think a lot of the governance risk and compliance management vendors -- it’s a new market space; companies like SAP and OpenPages and MEGA International and BWise, and others, are building up platforms that have both verticalized and horizontalized governance templates, rules and workflows, and so forth. Increasingly companies or enterprises will standardize on a dominant governance risk and compliance management vendor for their organizations, and then use whatever templates they choose. And their SIs will modify them to suit their own needs going forward.

Bringing this back to the whole notion of where nations get their governance charters. I just read a book, a really good one, called "Declarations of Independence," and it shows that the first actual declaration of independence ever created to found a nation was our Declaration of Independence in 1776. You wouldn’t believe how many other countries have actually plagiarized or borrowed language and whole concepts from it, including Vietnam. The declaration of independence for Vietnam in 1945 directly quotes from our Declaration of Independence, which I found highly ironic.

Garone: I’m going to bring back outsourcing into this discussion as well. Post World War II, the nations that have relied on the Unites States for its defense have thrived economically, because they have not had to spend so many dollars on their own defense -- Germany being the prime example. They’re under our umbrella, and their defense budgets are much lower than ours, and these nations have thrived and moved forward.

Gardner: Well, without getting too deep into what is or isn’t the right approach in world affairs, clearly we’ve defined here that a successful SOA is a lot about politics, power, and moving beyond traditional norms of organization. How you do that probably is going to involve failures. If the Unites States is a good model, it had to fail a couple of times. It failed with the Articles of Confederation. It failed in dealing with slavery up until the Civil War, and perhaps for a hundred years afterward in terms of how it was dealt with in practice, if not in law.

So the idea that we started this discussion with -- where are the SOA failures -- perhaps we should look to failures as a necessary set of learning activities, in that SOA is not going to just happen and spring up like a fungus or a mushroom after a spring rain, but it’s going to have to be something that’s hard-earned.

Matsumura: Well, the way I want to respond to is that having maturity in the way that you deal with failure is essential. If you look at the way that our policy system functions within the United States, what you have is you have a set of policy assertions about what it is people can and can’t do. But then you actually have a policy enforcement mechanism that’s heterogeneous and distributed. You have the FBI, the CIA, the state and local law enforcement, the Army and the National Guard.

You have all these different policy enforcement points everywhere, manifesting these policies. What is extremely important to understand is that there’s an entire judicial system whose function it is to take those policy enforcement actions, monitor their efficacy, and enable the whole system to readjust and adapt.

So, I think that it’s not just an accident of, "Let’s just run out there randomly, screw up badly, and then sit there and try to recover and learn." I think that having a learning engine that monitors, adapts, and revises policies, and having a competency center, an adjudication point that’s deliberately there for the purpose of making those adaptations -- that is an essential function.

Gardner: Or checks and balances ... . If you’ve got failure, that could be a very good learning experience, where you need a check and balance in place, and so the progression toward the value and benefit of SOA can be accomplished. It will be a different path for each company, but they’re going to have to have checks and balances to keep the progression going forward, rather than reverting back to the past, and in a sense giving up.

Well, this has been a very stimulating and interesting discussion, I’m glad that you all could join us. It took on a little different characterization than I was expecting, but a necessary vantage point on SOA in order to make it successful.

We’ve been joined here with our usual panel, Steve Garone, Joe McKendrick, Jim Kobielus and our guest, Miko Matsumura, vice president of SOA products at webMethods. This is your host and moderator, Dana Gardner. You've been listening to BriefingsDirect SOA Insights Edition, Volume 11. Thanks for listening and come back next week. Thank you, gentlemen.

If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.

Listen to the podcast here.

Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 11. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.

BriefingsDirect SOA Insights Analysts on SOA Suites Vs. Best-of-Breed SOA, and Master Data Management

Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition, recorded Jan. 26, 2007.

Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Dana Gardner at 603-528-2435.

Gardner: Hello, and welcome to the latest BriefingsDirect, SOA Insights Edition, Volume 10. This is a weekly discussion and dissection of Service-Oriented Architecture (SOA)-related news and events with a panel of industry analysts and guests. I’m your host and moderator Dana Gardner, principal analyst at Interarbor Solutions, ZDNet software strategies blogger, and Redmond Developer News magazine SOA columnist.

Our panel this week consists of show regular Steve Garone. Steve is a former IDC Group vice president, founder of the AlignIT Group, and an independent industry analyst. Welcome again, Steve.

Steve Garone: Hi, Dana, great to be back.

Gardner: Also joining us again Joe McKendrick, research consultant, columnist at Database Trends, and a blogger at ZDNet and ebizQ. Thanks for coming, Joe.

Joe McKendrick: Thanks, Dana, glad to be here.

Gardner: Also Tony Baer is making another appearance. He is principal at onStrategies. Thank for coming, Tony.

Tony Baer: Hey, Dana, good to be here.

Gardner: We’re also talking with Neil Macehiter. He is a research director at Macehiter Ward-Dutton in the U.K. Thanks for coming, Neil.

Neil Macehiter: No problem, Dana.

Gardner: And last on our list -- we have a large group today -- Jim Kobielus. Jim is a principal analyst at Current Analysis. Thanks for coming along, Jim.

Jim Kobielus: Thanks a lot, Dana. Hi, everybody.

Gardner: For our first topic this week -- and this is the week of Jan. 22, 2007 -- we’ll begin with the notion of SOA suites, a merging and definable market segment. We’re going to be looking at how mature such suites are. I suppose we should also look at the distinction between the best-of-breed-approach, where one could pick and choose various components within their SOA arsenal, or a more complete suite, a holistic full-feature set with the benefits, trade-offs, and detriments of each of these approaches.

Jim, you’re the one who was interested in this topic. Why don't you give us a little set-up as to what you think the state of the market is?

Kobielus: Thanks a lot. Over time, we’ve all been seeing this notion of a SOA suite take root in the industry’s productization of their various features, functions, and applications. Now, the big guys -- SAP, Oracle, Microsoft, webMethods, for that matter lots of software vendors -- are saying, “Hey, we provide a bigger, 'badder' SOA suite than the next guy.” That raises an alarm bell in my mind, or it’s an anomaly or oxymoron, because when you think of SOA, you think of loose coupling and virtualization of application functionality across a heterogeneous environment. Isn’t this notion of a SOA suite from a single vendor getting us back into the monolithic days of yore?

This thought came to me when I was reading a Wall Street Journal article earlier in the week about SAP, “SAP Trails Nimble Start-Ups As Software Market Matures.” There was one paragraph in there that just jumped out at me. They said, “Some argue that SAP's slump highlights a broader shift under way in business software, in which startup companies wield an advantage over established titans. Under this traditional business model companies buy large, costly packages of software from SAP and Oracle to help them run their back-office functions and so forth, but as the business software industry matures, many companies already have the big software pieces they need, and feel little urgency to replace them.”

So, clearly SAP is then sort of a driver in the SOA suite arena for few years with NetWeaver. Is the notion of SOA suite an oxymoron? Are there are best-of-breed-suites? There are also best-of-breed SOA components, and I’m not sure that the notion of a suite, an integrated suite is really what companies are looking for from SOA. They want best-of-breed components with the assurance, of course, that those components are implementing the full range of SOA standards for heterogeneous interoperability. So, I’m taking issue with this notion of a "best-of-breed" suite. Anybody else have any thoughts on that?

Macehiter: I’ll give you a couple of perspectives on this. We have to recognize that organizations increasingly are looking to rationalize their supply strategy. So, they’re increasingly looking to deal with a smaller number of vendors and suppliers, which is, in part, driving the move toward larger vendors attempting to offer a suite or portfolio of product capabilities that can help organizations manage the lifecycle of an SOA initiative.

That’s one factor that’s driving it. The second issue is the use of the term "suite," and what that really entails, versus what the market is currently delivering. Companies are putting together a bunch of products under a common brand, whether it’s Oracle Fusion, SAP NetWeaver, or under the IBM WebSphere brand. That's one thing. Actually making sure the products are well integrated and that they have a common management environment, common configuration environment, and common policy definition environment is the second thing. That’s one element of it.

The second issue is what actually constitutes a suite to support service-oriented initiatives. There is a tendency, certainly among the larger vendors, to focus on SOA from a development and integration proposition, rather than thinking more broadly about the capabilities you need to support service-oriented initiatives throughout the lifecycle. That extends beyond development and integration into things like security and identity, which have to be incorporated into an overall SOA offering.

Management and monitoring, usage management, audit logging are in the broad range of capabilities that you need. There’s a question as to whether it’s feasible for one vendor to offer all of those capabilities that you need to support an SOA initiative versus a set of core capabilities. Then the hooks in the interoperability allow you to exploit existing security and management infrastructure. There are a number of factors that we need to consider, and a lot of the SOA suite propositions are very much focused around development and integration, rather than management and monitoring, and really dealing with the lifecycle of services.

Gardner: I guess that explains and is consistent with the past. If you can have a cohesive approach to the development side, then the deployment tends to follow, and that’s where you monetize. Steve Garone, what do you think of this breakdown between best-of-breed and a suite?

Garone: All of us on this podcast today know that the debate over best-of-breed versus integrated-stack approach has been going for many years in a variety of scenarios and contexts, and it hasn’t stopped. I don’t really like the word "suite." It reeks more of marketing than functionality. I think what you really have to look at in terms of SOA is how people are actually approaching getting into building SOA-based environments.

What we’ve seen so far -- and we’ve talked about this on other podcasts -- is that up to this point people have tended to do pilot projects that are much lower in scale than what they will eventually do if they have success with the immediate projects. One tends to think that what they’re going to do at that point is pick and choose the individual products and functions that they need to make that happen in the short term.

I think that’s what we’re seeing, but I also sense that, despite the fact that everybody wants an open environment where they can pick and choose and not be tied to one vendor, what overrides all this is a desire to get things done quickly, efficiently. They want a way in which they don’t have to be concerned about integrating a lot of products and what that entails, and having potentially an unreliable environment. What that points to is working toward one vendor. End users will do that even in the short term by choosing someone that they know they can grow with in the future.

Gardner: Pragmatically, these vendors are also looking at their future and they’re saying, “We have an installed base. We have certain shops where we’re predominant. We want to be able to give them a clear path as to how to attain SOA values from their investment in our legacy. Therefore, we need to follow through with add-ons that smack of a integrated-stack approach.” So, it is almost incumbent on vendors to try to produce this "whole greater than the sum of the parts" -- if not to build out more SOA business, then just to hold on to their previous business.

Garone: That up brings up another interesting point, which is vendors, especially the platform vendors. The larger vendors, like IBM, Sun, and so on, tend to try to walk the line between being able to offer a fully integrated stack of software to accomplish whatever the goal it is -- in this case SOA implementations -- and also being what might be called “integratable.” This means you can bring in another product, because we adhere to standards, we’ll be able to help you do that.

They try to walk that line; where that really makes a difference is not so much what you are going to do in the future, but rather what you have done in the past. If you've got an existing registry that you used for identity management with your current applications, if you have existing app servers -- which is probably more common -- whomever you choose is going to have to be able to allow you to continue to work with those as part of a legacy environment. It sounds funny calling application servers legacy, but at this point you can do that, and that’s really where the "integratability" aspects of a fully integrated stack come into play.

Gardner: So how about you, Joe McKendrick? Do you see that the drive for simplicity and working from your installed base creates a compelling case for an integrated SOA approach? Or is the trade-off such that this is really not going to happen anymore? Is that the old way -- and is SOA fundamentally different, and therefore one should look for a different strategy?

McKendrick: Perhaps a little of both, Dana. Basically the industry still operates under the traditional mode where a lot of enterprises rely on one vendor -- we'll call it a master vendor -- that supplies most of its solutions. We see that in the IBM and in the Oracle markets. I agree with Jim that the notion of a SOA suite is very much an oxymoron. The idea of a SOA is to have "hot-swappable" software components that you could install and take out as needed in a loosely coupled architecture.

Dana, you hit upon the point that the vendors themselves have to demonstrate that they have some type of path to their installed base. They need some type of path to show that, "Yes, we are on top of the technology." In fact, if you speak with vendors out there about this strategy, even if the products or the path that they're offering are something customers aren’t adopting at the moment, it’s something they want to see with the vendor. If Oracle, hypothetically, wasn’t talking about SOA at all, there would be a lot of consternation, a lot of concern, among their installed base as to where the vendor is going.

Gardner: SAP would walk in, and their sales people would beat them up in these accounts, right?

McKendrick: Exactly. Now, Oracle is an interesting case. When I think of suites, I think Oracle demonstrates the best tendency in this area. In fact, they called their offering "The SOA Suite," and they include a number of components. I have spoken with some companies that have Oracle installations. Now, it should be noted that typically the customers for these suites are the installed base. The people who will be buying into the components of the Oracle SOA suite are companies that either have the Oracle applications, the E-Business suite or the Oracle database underneath. And, in most cases, they are buying into components of the suite.

I've heard a lot of positive things said about the BPEL Process Manager, for example. And, they are buying into pieces of the solutions, and as Steve pointed out -- it’s still in the pilot-project stage. We’re not seeing widespread enterprise implementations, but they are beginning to buy into pieces of these solutions such as the BPEL Process Manager.

Gardner: Hey, Tony Baer, how about you? Do you think that we are mature enough in SOA that we should be looking for homogeneity when it comes to tools and even deployment side? Or, is heterogeneity the issue that we are trying to manage?

Baer: As Steve was saying before, we can’t decompose it down to the age-old argument of best-of-breed versus integrated-stack. There is always going to be a tension between homogeneity and heterogeneity. For the customer, it’s going to be dictated obviously by what is already in place, basically as Joe pointed out. If 60 percent of my functionality, or even say 30 or 40 percent of my functionality, is SAP, I’m likely to listen when SAP tells me about a NetWeaver Solution.

On the other hand, if I’m in a sector that does not lend itself to package solutions, I will more than likely tend to take a best-of-breed approach -- especially if I do a lot of homegrown development, because my business is so unique. There will always be that creative tension there. That being said, the fact is that at the infrastructural level, there is a desire to have consistency. I don’t want to have five security engines. I don’t want to have three different authentications, if possible. Obviously, we’re never going to get that one, centralized identity repository in the sky, but I want to at least have my management framework be as consistent as possible and to manage what will inevitably be, in most large organizations, a federation of different installed bases of different technologies.

The other side of this is that for vendors -- and Oracle is probably the best poster child for this -- the reality in the enterprise software industry has been one of merger, acquisition, and consolidation. This means that vendors who started as organic developers now have four or five different product lines and each has had a separate lineage. The only way to put some rationality there is something like an Oracle Fusion SOA framework. Oracle has to develop this, if only out of the necessity to keep its own product offerings consistent.

Gardner: Now, back to Jim Kobielus’s point about this integrated approach being an oxymoron for SOA. Shouldn’t the vision of SOA allow us to have it both ways? If you have a culture and mindset in an organization, maybe it’s because of your legacy. Maybe it’s because of how you operate and the value you’ve perceived in past IT investments. Thus, you might want to remain with more of a single-vendor or an integrated-stack approach, but there might be other vendors without a legacy to drag along. The enterprise may want to take advantage of any innovation they can to be functionally heterogeneous and to explore and test open-source componentry as that becomes available. Shouldn’t SOA allow both of these approaches -- and pretty much equally?

Macehiter: In principle it should. We have to be careful to distinguish between the infrastructure that you require to enable SOA initiatives and what you’re trying to enable with that service-oriented initiative. Just because you want to have a loosely coupled component that you can combine in multiple ways to deliver business outcomes, doesn’t mean that the infrastructure that underpins that has to be similarly loosely coupled and based on the heterogeneous offerings from different vendors. So, there is a separation there.

We also we have to bear in mind the challenges around going for best-of-breed approach, which are well understood. It’s not so much whether the individual components can actually talk to one another but more about things like the management environment and how you manage the configuration and how do you deal with policy definition?

We’ve done some detailed assessments of service infrastructure offerings from SAP, BEA, IBM, Oracle, Sun, and webMethods. If you actually dig under the covers, you will see that each of the components has its own policy definition approach. So, the way you configure policy within the orchestration engine is inconsistent with the way you do it within the security and identity management capabilities, and that challenge occurs within suites. That’s going to be compounded as you look across different components. That introduces risk into the deployment. It reduces the visibility of the end-to-end deployment. It's those factors that are going to be important, as well as whether a communication and brokerage capability can integrate with the registry and repository. There are a number of factors that you have to bear in mind there.

Kobielus: I agree -- I think that the notion of a best-of-breed SOA suite makes more sense from an enterprise customer’s point of view. Most enterprises want to standardize on a single vendor and a single stack for the SOA plumbing -- the registries and repositories and also the development tools. They want the flexibility to plug in the different application layer components from Oracle and SAP and others, that are SOA-enabled and that can work with that single-core-plumbing-stack from a single vendor.

Gardner: Perhaps the tension here is between what aspects of SOA should be centralized, repeatable, simplified, and consolidated, and which ones should not. It’s not really a matter of SOA homogeneous or SOA heterogeneous. In moving toward SOA, should you say, "Listen, this is going to be common throughout. Let’s reuse this. Let’s manage our policy as centrally as possible.

"We might say the same for other federated and directory services. We might say the same for our tooling, so that we don’t have myriad tools and approaches from our developers. On the other hand, we want to have great flexibility and loosely coupled benefits, when it comes to which services, be they internal or external, be they traditional nature or more of a ‘software as a service’ nature that we can easily incorporate and then manage those as process."

So, is the dividing line here, Steve Garone, between what architecturally makes sense as centralized and not?

Garone: Actually I’ve just sort of been chomping on the bit here a little, because I’ve been listening to the conversation. This a really important point, mostly because there is a lot of stuff -- a lot of analyst opinion, a lot of blogging -- floating around that I’ve read, and I know you guys have probably read, on this very subject, the sort of philosophical dichotomy between what SOA is supposed to be and the notion of an SOA suite or a SOA integrated stack.

Frankly, from the end-user perspective, the message ought to be that the whole notion of SOA, as it relates to loose coupling, is really focused on the services and the applications that you’re going to deliver. That doesn't imply or even suggest that your infrastructure cannot be based on an integrated stack or software that’s designed to work well together. It allows you to work with a single vendor, and to be very efficient about how you both develop, deploy, and maintain and manage your environment.

Gardner: We also have to remember that this evolution of SOA is not happening in a vacuum. There are other major IT trends and business trends of worth. Many of them are focused on trying to reduce the cost of ongoing maintenance and support somewhere between 60 and 80 percent of total IT costs, and maybe more, to free up discretionary spending and to reduce the total spending for IT in many organizations. The trends often involved include data center consolidation, moving toward a more standardized approach for underlying hardware, embracing virtualization/grid/utility principles, and so on. Perhaps we have to recognize that even as SOA moves on its own sort of trajectory, organizations are going to be consolidating and looking for commonality of services, and improved support and maintenance types of features throughout their infrastructure.

Garone: Just to make one more small point. The one area that may diverge from the philosophy that we’ve been talking about is in the area of open source. I think that people who go out and try to implement SOA-based solutions on a variety of levels using open source technology may tend to take a more best-of-breed, individual-component approach than those who would run to their local IBM sales rep and say, “What do I do with SOA?” Even that’s going to change over time, and we’re starting to see SOA suites develop around open-source technology as well. So, that’s going to move in that direction as time goes on.

Gardner: That's another trend that is in tandem with SOA and needs to be woven together with it. It’s obviously a large undertaking. I‘m also reminded, after an interesting briefing I took this week with Informatica, and Ash Kulkarni. We had a really long, interesting discussion about the role of data, master data, and metadata when it comes to moving toward SOA. We really shouldn’t lose track of the fact that as you move to applications as services, and you go loosely coupled, and you adopt more reuse across development with common frameworks, and use rich internet application interfaces -- what about the data?

The data has to be managed as well. Increasingly, companies that have had mergers and acquisitions, or have just gotten myriad applications with varying views of something as specific as a customer identity -- there might be 10 or 15 different views of a customer, as defined by a variety of different applications. How do you manage that? And when you think about the progression of the data, it seems to me that if not in actuality, in a virtual sense, you want to become centralized with your data so that data can be used in a clean and impactful or productive way across all of your services.

Does anyone out there have some thoughts about what considerations to have when it comes to data in this decision about best-of-breed or integrated approach?

Macehiter: I was just going to say, the issue is that data has always been treated as a second-class citizen, and that it has been the product of applications which have then been subsequently analyzed. More organizations are recognizing this need to treat data as a peer, and deliver access to information, whether it’s structured or unstructured, as a service, which can be incorporated as needed into business process.

IBM was quick to identify this when they sold the information as a service strategy. And Oracle, surprisingly, given where they have come from, has actually not really enunciated data services, vision and platform. Although I did notice something on the Oracle Technology Network a couple of weeks ago, where they are just starting to talk about Oracle Data Integrator, based on an acquisition they made of a company called Sunopsis.

So, increasingly that's going to become part of the broader suite proposition. And, this is not just in the area of data but -- more broadly as customer adoption matures -- what constitutes an SOA suite. We’ve seen this around registry and repository, which historically was a best-of-breed proposition from the likes of Systinet and Infravio. Where are they now? They're part of a broader suite proposition from HP and webMethods, respectively. We’ll see this again.

Through acquisition what constitutes a suite will broaden as organizations become more mature in their approach to SOA. "Information as a service" is exactly one of those areas. Initially, that will probably be served by best-of-breed components, and then through a combination of acquisitions or very close partnership relationships will gradually be subsumed into what organizations believe is a SOA suite.

Gardner: Any other thoughts on the data services level and how that relates to this discussion?

Kobielus: I cover SOA for Current Analysis, primarily with reference to data management; and SOA in the data management realm is really consistent with master data management (MDM) as a discipline. Basically, master data management revolves around how you share, reuse, and enable maximum interoperability of your core master reference data, your single version-of-truth information, which is maintained in data warehouses and various operational data stores, and so forth.

Informatica is one of many vendors -- you mentioned Informatica earlier -- that has a strong MDM strategy. But there are are a lot of enterprise information integration (EII) vendors out there. EII revolves around really federated MDM, where you keep the data in its source repository, and then provide a virtualized access layer. This allows your business intelligence and other applications to access that data through a common object or model and a common set of access schemas -- wherever that data might reside -- but facilitated through a virtualized access layer. That’s very much EII as implemented by Business Objects, BEA, and many other vendors, and is very much the approach for federated MDM.

Gardner: Let me pause you there for a minute, Jim. If a virtualized centralization works for information, why wouldn’t it work for other aspects of SOA?

Kobielus: Oh, it does. Virtualization, of course, is one of the big themes in SOA.

Gardner: You can enjoy the benefits of a homogeneous approach, but, in fact, have great heterogeneity beneath the covers. Isn't that the whole idea of SOA -- to provide homogeneity in terms of productivity control management, and yet with flexibility and agility?

Kobielus: SOA, first and foremost, is a virtualization approach -- virtualization defined as an approach for abstracting the external call interface from the internal implementation of a resource, be it data or application functionality.

Gardner: So SOA is best-of-breed -- and it’s integrated. And you can pick and choose how to proceed, based perhaps on your legacy and your skill sets.

Macehiter: We just have to be clear to distinguish between the assets or resources that you’re virtualizing through SOA, which is typically going to be functional assets versus whether you need to virtualize the infrastructure and apply SOA to the underlying infrastructure. That’s the key distinguishing point. And that gets the point that was being raised earlier about virtualized access to information.

The infrastructure could be common, but the information assets that you’re accessing will be in heterogeneous repositories accessed in a number of different ways. This is exactly what IBM is doing with its offerings around information-as-a-service, and BEA as well. It's having the equivalent of application adapters by applying them to information assets and then exposing those through a service interface, so it’s virtualized and transparent: where the information is, how it’s stored and what format it’s in.

Kobielus: You mentioned Oracle’s acquisition of Sunopsis, which is interesting, because Sunopsis is an ETL vendor and the transform side of it is critically important. When you are extracting data from source repositories, you’re transforming it in various ways. Traditionally, Sunopsis’s tools have been used primarily to support transformation of data, which will then be loaded into centralized data warehouses.

But transformation functionality is important, whether you’re doing it in an ETL data warehousing environment -- in other words, the traditional bus for MDM -- or whether you’re doing the transformation in an EII environment. There, in fact, you are not ultimately loading the transform data into a central store, but rather simply transforming the data, keeping it in it’s original schema, but transforming it so it can be rationalized, harmonized, or aligned with a virtualized data access model provided by that EII environment.

Macehiter: Exactly. The transformation should occur behind the service interface, and this is why you need the idea of common information models and common schema models.

Gardner: Before we get down too much in the weeds on EII -- we can address that perhaps in a whole show in the future with a guest who is very much involved with that industry. Let’s move on to our second topic today, given the amount of time we have.

There are a burgeoning number of critical skill sets that need to be applied to SOA. We’ve talked about data, whether it’s cleansing, transforming, virtualizing and approaching some sort of a MDM capability. We have talked about development and process, BPEL. We talked about infrastructure. There is the management, the architectural overview, and what’s our philosophy.

It seems like we’re going to need a lot of very skilled people who are both generalists, as well as highly specific and technical. Because for SOA to work, a bunch of people who are highly specific -- but don’t share the same vision or have a general sense of the strategy -- probably won’t fare too well. This issue comes to us from Joe McKendrick. Joe, give us a little setup and overview of where you think things are headed in terms of the necessary skill sets companies are going to need in order to accomplish the promise of SOA.

McKendrick: Thanks, Dana. It’s interesting. Actually, the impetus for my thinking on this came from a report Ron Schmelzer posted and I reported on my blog this week.

Gardner: Ron being with ZapThink.

McKendrick: That’s correct. He is sounding the alarm bells that the folks that we need to drive SOA forward in the enterprise is this class of enterprise architects and enlightened architects, if you will. There are a lot of SOA projects everybody is interested in. Everybody’s kind of ginned up about SOA now, and we’ve been hearing about it. Enterprises really want to begin to either pilot or move SOA past the pilot stage, and 2007 should be a big year.

Ron Schmelzer feels there may not be enough architects who can take this high-level view and drive this process forward. Now, it’s interesting, but when I posted this on my blog, I got lot of feedback that perhaps architects are not the only ones who can really lead this effort. There are plenty of developers out there, high-level developers, who can also contribute to the process and interact with the business. The key behind this argument is that you need folks who know what’s going on technically, but can interact with the business. It can be a rare skill to have both.

Gardner: Yeah, this is going to be demanding. You can get Oracle-certified, you can get Microsoft-certified, IBM-certified. Where do you go to become SOA architect-certified?

McKendrick: Where do you go in terms of higher education institutes to get trained on architectural planning and network design? I’ve talked to lots of people who say, “Yeah, we look at the computer science graduates coming up, but how many of these people really, fully have had any training or courses whatsoever on broad architectural subjects like SOA?" Very few.

Kobielus: That’s true. Not to get reminiscent or anything, but 10 years ago, when we started seeing Java ramp up, we saw a lag there as well. A lot of organizations were really hungry for Java developers, and the universities came through with more focus on it, but later than probably most organizations wanted. What will happen here is that while this ramp-up goes on, we might see a lot of new business and new interest in service organizations that can provide the professional services required to get people through it.

Macehiter: Yeah, that’s true. That’s going to be an important -- absolutely an important source. Also, there’s some work under way. I don’t know whether any of you are familiar with the the International Association of Software Architects (IASA), which is really trying to foster a community that does try and share best practice around software architecture, including SOA.

You hit the nail on the head in terms of the key skills that are required around being able to interface with the business. One of the skills and attributes that you also need as a SOA architect is really this ability to balance supporting short-term business outcomes but keeping an eye on the longer-term objectives in terms of gaining high quality and maximizing IT value. That’s an equally difficult skill because too often architecture historically has been focused on quite discrete initiatives or infrastructure. I’m thinking about server architecture or network architecture rather than this broader perspective. There are skills occurring from such things as Oasis and what they are trying to do around things like SOA blueprints. It will be useful to get someone from Oasis in a future podcast to discuss this, because this is where the education is coming from.

Gardner: I think that if everyone goes about SOA methodically on his or her own track, and based on their own experience, and we are going to come up with a real mish-mash, then it’s going to be a problem. There needs to be some standardization around methodology.

Coincidentally, in April we’re expecting to see version 3 of the Information Technology Infrastructure Library (ITIL). This is focused on the lifecycle of services. It’s really more at the IT service-management level than pure technology, but it does offer blueprints and books and standardized approaches on how to setup an IT department and manage some of these organizational things. It strikes me that that might be another influence on bringing some kind of a cohesive approach to SOA, rather than be totally scatter-shot.

Macehiter: ITIL came out of the U.K. government. What was interesting about it is that it was driven very much from the experience of people who were grappling with these very challenges. That’s where it’s going to come from in SOA. It’s going to come from things like the IASA and others practitioners defining the best practice, rather than a more theoretical, academic approach to defining the ideal methodology.

Gardner: It's my understanding that the global systems integrators are very interested in this coming version of ITIL, and some of these other standardization-for-methodological-benefit approaches. As I’ve said before, SOA is the gift that keeps giving, if you’re a systems integrator in a professional services organization. It will be really interesting to see how successful they are at bringing a standardized set of approaches to the SOA architect role and whether that’s actually in their best interests over time.

McKendrick: And when it washes up on these shores, we’ll call it American ITIL.

Gardner: Actually the number of ITIL users is highest in the private sector and in North America, as I understand it, although it’s hard to see to what degree people actually use it. I think people use it in dribs and drabs and not in entirety.

McKendrick: It’s going to be interesting. There’s a lot of emphasis on compliance now, and data management is a big part of it as well. ITIL is really going to come into play, and should be coming into play, because processes are outsourced. Because processes are being managed by third-party firms, you need to have across-the-board standards to ensure that the data is being managed properly and in accordance with some type of universal standard. And, the regulators are going to want to see that as well.

Gardner: Well, I think we’ve come up with two separate shows we'll need to do -- one on enterprise information integration (EII) and dig in to that topic specifically; and then, perhaps, we should do an ITIL show, get someone who is familiar with some of the authoring there, and dig into its implications for SOA.

Well I think that wraps it up for today. We’ve covered quite a bit of ground in a short amount of time. I want to thank all of our guests. We’ve had Steve Garone, Joe McKendrick, Neil Macehiter, Tony Baer and Jim Kobielus. This is Dana Gardner, your host and moderator for this week’s BriefingsDirect SOA Insights Edition. Please come back and join us next week. Thank you.

If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact me, Dana Gardner at 603-528-2435.

Listen to the podcast here.

Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 10. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.

Transcript of BriefingsDirect Podcast on ITIL v3 and IT Service Management

Edited transcript of BriefingsDirect[TM] podcast with Dana Gardner, recorded Jan. 22, 2007.

Listen to the podcast here. Podcast sponsor: Hewlett-Packard.

Dana Gardner: Hi, this Dana Gardner, principal analyst at Interarbor Solutions and you’re listening to BriefingsDirect. Today, a sponsored podcast discussion about Information Technology Service Management (ITSM) and a related area, the evolving Information Technology Infrastructure Library (ITIL). These are complementary trends that are helping to mature IT as a customer-focused quality-of-service activity.

We’re not so much focused on how technology is deployed and actually used, on a product-by-product basis, but really how IT is delivered to an enterprise for its internal consumers of IT. ITSM and ITIL are following longer term trends that we’ve seen in manufacturing, such as Six Sigma and the quality initiatives that we saw in the post-World War II period. So, this is really an indication of how IT is maturing and how to take it to a further, higher plane of a customer focus and quality of service.

Joining us to look into these subjects and learn more about them as they’re now maturing and coming into some milestones -- particularly ITIL with the next version arriving in the spring of 2007 -- are executives from Hewlett-Packard's Services Consulting and Integration group. Joining us is Klaus Schmelzeisen, director of the global ITSM and security practices at HP’s Services Consulting and Integration group. Klaus is managing the solution portfolio that helps customers manage their applications and infrastructure environment. Welcome to the show, Klaus.

Klaus Schmelzeisen: Hello, everyone.

Gardner: Also joining us is Jeroen Bronkhorst, ITSM program manager within the Services Consulting and Integration group at HP and also an active participant in the ITIL version 3 editorial core team, as well as an author of the integrated ITIL process maps. At HP, he is a consulting coordinator and is helping to develop the core deliverables, as well as an ITSM reference model. Welcome to the show, Jeroen.

Jeroen Bronkhorst: Thank you, Dana. Hello, everyone.

Gardner: As I mentioned, this is part of a longer-term trend. ITIL has been around for quite some time, and ITSM services for management is a bit newer. Perhaps you could help us understand the history. How did the demand for these services come about, and what are some of the current drivers that are bringing this into the fore for an increasing number of enterprises?

Schmelzeisen: Let me take this one on. I've been observing the area of ITSM since the early '90s, and, interestingly enough, it really started with the infrastructure piece. At that point in time, corporations were introducing lots of new technologies, especially in the networking environment. This was a change from the X.25 networks into TCP/IP environments, but it was also a time when a lot of the mainframe environments were superseded and replaced by open-system environments.

Client-server infrastructures came into place. So, there was a big need for infrastructure monitoring that, once this was in place, were followed by IT services, which brought a completely different spin. That was to deliver the output of an IT organization as a service to the business. That's where ITSM started big time, and that was a couple of years later.

So, really, around the mid-'90s and since then, standards and best practices have evolved. HP has had its reference model since 1996 as a trademarked approach. Even before that, there were pre-versions of it. So, ITSM came along really in the early to mid '90s, and ITIL started around the same time.

Gardner: Do you think this is just a response to complexity? Is that what the underlying thrust was for this? Were there just more types of systems to deal with, and therefore they needed more structure, more of a best practices approach?

Schmelzeisen: Definitely. The complexity drove a lot of new and different technologies, but there were also more people in IT organizations. With more people, complexity went up, and then quickly the realization came that processes are really a key part of it. That brings you right to the heart of ITSM and then ITIL.

Gardner: So, it’s really about the complexity of the IT department itself, not necessary the technology?

Schmelzeisen: Definitely.

Gardner: Is there anything in particular about what’s going on now that makes this more relevant? Do you think the expectations for what IT provides are growing? Or is it the fact that IT is becoming much more strategic, the companies need to succeed at IT for the entire company to succeed?

Schmelzeisen: It’s actually multifold. On one side, the old challenges are still here. We see new technologies. We see the need for new services coming up. But there are also a lot of drivers that are putting pressure on the IT department. One is the ongoing topic of cost reduction. The competitiveness of an IT department is related to the efficiency and the quality of processes in place.

There is also the big theme of regulatory compliance. That is permanently on the CIO agenda and that of all C-level management. To achieve this you need to have all the processes very well under control. There is also the ongoing demand to provide more value to the business, to be more agile in your responses, how quickly can you can implement new environments and respond to the needs of the business. Those are really the challenges of today.

Bronkhorst: May I add to that as well, Dana?

Gardner: Please, yes.

Bronkhorst: What I also see is that there are organizations that have an increasing need to demonstrate the level of quality that they are providing to their customers. We now have an industry standard called ISO/IEC 20000 for IT Service Management. There is an opportunity here to become certified, which might be useful in the case, for example, an IT organization wants to go to the outside world and provide services in the open market or as a protection mechanism for the internal IT organization to prevent themselves from become outsourced. This is another driver for organizations to show the value and the quality they provide.

Gardner: So, demonstrating their role and their certification helps to establish them internally against a competing approach, but also gives them more credibility if they want to take these services to an extended enterprise approach.

Bronkhorst: Yes, that’s correct.

Gardner: Now, could you help us understand ITIL, this library of best practices? We’ve got a new refresh coming up with Version 3 this coming spring. What is the impact of ITIL and how does it relate to ITSM?

Bronkhorst: Let me speak to that a little bit. ITIL originated in the '80s actually. It was created by the British Government, which still owns ITIL. It's a set of books that describes best practice guidance in the area of, "How do I organize the operational processes that help me manage my infrastructure and he help me manage my IT services?"

When it was created in the '80s, it initially consisted of more than 30 books. They were condensed in the '90s down to eight books, and that’s basically the set that exists today. However, as we’ve seen the technology and the needs evolve, the British Government is driving a project to further condense ITIL down to five books. This will better link it to the needs of businesses today, which will then help customers to get themselves organized around the lifecycle of IT services, being able to create new services, define them, build them, test them, bring them into production, and take them out of production again once they’re no longer needed.

If I look at the traditional impact of ITIL, I would say that it is typically targeted at the operations department within an IT organization, the area where all the infrastructure and applications are maintained, and where, as a user, you would interact most on a daily basis.

What’s happening with the new ITIL is that the scope of these best practices will be significantly improved, and ITIL Version 3 will be more focused on how you organize an IT organization as a whole. In other words, taking an integral view of how to manage an IT service that consists of applications, infrastructure components, hardware, etc. This means it will be a much bigger scope of best practices compared to what is it today.

Gardner: You mentioned that this began in a government orientation. Is this being embraced by governments, or by certain geographies or regions? Globally, is ITIL something that a certain vertical industry is more likely to adapt? I guess I'm looking for where is this in place and where does it make the most sense?

Bronkhorst: ITIL is not particularly focused on a specific industry segment. ITIL is generic in the sense that it provides best practices to any type of IT organization. It’s also not restricted geographically, although the British Government created it initially. Over the past few years, we could almost say it has conquered the world. This is evidenced by the fact that there are local IT service management forum organizations, which some people call ITIL users groups, but it’s a little bit more than that.

These IT groups focus on best practices in the area of IT service management of which ITIL is a component. And so, across the globe, many of these user groups have started. Actually, HP was a founding member of many of those user groups, because it is important for people who use these best practices to share their experiences and bring it to a higher level.

Gardner: This new version, Version 3, is this a major change? Is this a modest change? I guess I'm looking for the impact. Is this is a point release or a major SKU? How different will Version 3 be from some of the past approaches for these best practices?

Bronkhorst: I would classify ITIL Version 3 as a major release. I say that not because it is changing things from ITIL as it exists today. One of the basic underlying designs is that it builds on the principles that exist in ITIL today. The reason I'm saying it’s a major release, is because it's adding so much more to the scope of what ITIL covers, plus it completely restructures the way in which the information is organized.

What do I mean by that? In the past when you looked at the ITIL books, they were focused on topics that made sense to the people who work within the IT organization. Application Management, Infrastructure Management, Software Asset Management are all topics that make sense from an IT internal view. But, few people who look at IT from the outside care about how you do it, as long as they get the service that they have agreed on with you.

The new ITIL will be organized around five phases of the service lifecycle, starting with strategy. How do you handle strategies around services, followed by how do you design a service, and how do you then transition that service into operations? Service operation is the fourth phase, and then the last phase is all about how to continuously or continually improve service delivery? That will be a major change, especially for people who are familiar with the current ITIL in the way in which it is structured.

Gardner: Now, this isn’t happening in a vacuum. There are many other large trends taking place and affecting IT and businesses, and these are very dependent on IT. I'm thinking of application modernization, services-oriented architecture, consolidation and unification, adoption of new approaches with an emphasis on agile or rapid development. Does ITIL help reduce the risk of embracing some of these new trends? How should companies view this in terms of some of the other activities that they are involved with in their IT department?

Bronkhorst: ITIL basically helps you to set the context for these trends in an IT organization. In other words, if you organize yourself according to ITIL best practices, you have a solid foundation for being able to more quickly adopt new trends in the marketplace or new, evolving technologies, as you are organizing yourself to be much more agile than you have been before.

Gardner: Are there hard numbers to apply here. Perhaps, Klaus, you have some indication? When companies look at this, it seems like it makes great sense. It’s progressive. It’s maturing -- something that is fairly recent and fast-moving in organizations. But, are there hard business metrics, ROI, reduced total cost of IT, or higher productivity? When it comes time to sell this, to convince the business to invest in such things as ITSM, and they say, “Well, what’s the pay-back,” what has been the experience?

Schmelzeisen: We definitely have a lot of numbers. The usual metrics are cost reduction. For example, one of our big customers, DHL, reports 20 percent cost reduction since it implemented their IT processes. We have other cases where they are looking at a total return on investment that includes efficiency gains, as well as staff reduction, improved quality. That showed a breakeven for one of our clients, Queensland Transport, the government agency in Australia, in the second year, and an ROI of 400 percent in five years.

There are other measurements, like decreased amount of rework, decreased response time, how many calls you can solve on the first call. All these measurements are coming together. Alcatel-Lucent, for example, is showing very good returns in terms of quality improvements, as well as things that are much less tangible, like facilitated consolidation of all systems and their subsequent decommissioning.

So, there are very tangible measurements, like cost reduction, the number of call resolutions, and things like that -- quality improvements. And, there are less tangible ones, like how quickly you can get rid of older environments, how quickly you can consolidate, etc.

Gardner: What about the impact on users? Have there been surveys? You mention some of the software paybacks around reduced the time for resolution and better call center performance. Has anyone that you're aware of done user focus surveys after ITSM approaches have been adopted. Have they gauged the satisfaction of the people who are the ones actually using IT?

Schmelzeisen: Basically, the response to the quality of service provided by the IT department?

Gardner: That’s right -- the perception and the sense of confidence in IT.

Schmelzeisen: I don’t have a precise number at hand right now, but you can easily deduce it. If you call a help desk and you get put on hold, or you have to call again and your call is continuously routed to another person, and eventually you get an answer in a couple of days, how is your satisfaction rate based on that? It’s probably going to be very low.

However, if you call, and the person at the other end has all the information available about your case, he knows what type of system you have, he knows how it’s configured, he knows what changes have be done within the last couple of weeks or months, and he knows what environment you’re working in -- and he can help you right away -- I think it does great things for customer satisfaction.

Gardner: Sure, if customers can call in and get resolution and a sense of confidence, they're less likely to go off and start doing IT things on their own, on the department and lower-division level, which then requires that to be brought into a more centralized approach. Then, you lose any of the efficiencies of central procurement, managing licenses, and reducing redundancies.

It seems as if taking this life-cycle approach has a great opportunity to improve on efficiency from a procurement, licensing, and cost basis.

Schmelzeisen: Absolutely.

Bronkhorst: May I add one more thing, Dana? I think what we also see is that it’s not only important to measure, monitor, and manage customer satisfaction. It’s also key for a lot IT organizations to manage and monitor employee satisfaction. This is something that we also do as an integral part of the way that we handle projects where we implement ITSM processes and technologies with our customer.

Gardner: As far as United States market goes -- the one that I am most similar with -- it has been a long-term trend that it’s difficult to get qualified IT people and hold them. They often jump from company to company. I suppose that’s part of the dissatisfaction, but places enterprises in a fire-fighting mode much of the time, rather than in a more coordinated and straightforward productivity approach.

Bronkhorst: It’s also key that if you implement an ITSM solution or an ITSM environment, then what you do is structure the activities within an IT organization. Those activities are performed by a piece of technology, in other words automated, or performed by people. The challenge with many of these implementations is how to configure people in a way that they execute the processes the way they were designed. Technology, you can control, but people, sometimes you can’t, and you need to do something extra in order to make that work.

Schmelzeisen: I think that’s an interesting term that’s been introduced, "configuration of people," which means training and education. As a proof point to that, in all of the big projects -- Alcatel-Lucent, DHL, and Queensland Transport -- we had actually trained and retrained a significant number of people. With DHL, we trained about 4,000 IT professionals from a number of companies. With Alcatel-Lucent, it was training for about 1,000 employees. So, it’s a significant number of people need to be "reconfigured," as you called it.

Gardner: In another economic efficiency area, companies and enterprises have been looking to outsource or offshore. They're, looking to have better choices and more options in terms of how they acquire IT. If they have the certification process, as is being described here, in place, they can go and say, "Well, are your people certified? Are they trained? I am not going to outsource to anyone that isn’t."

It seems like this could make for more professionalism and less guessing, or risk, when it comes to outsourcing. Is that a trend you are seeing as well?

Schmelzeisen: Absolutely. It is important for organizations that want to show that they can achieve a certain level of quality to consider certification. What we did in our approach was to make sure that we use methodologies that have proven themselves in reality for customers to become certified in ITSM.

Gardner: All right. Let’s look to the future a little bit. It seems that there is a life-cycle approach to ITSM itself, and its successes can build upon one another toward a whole greater than the sum of the parts. But on the other hand, with this commoditization, if all companies are certified and all IT departments are operating in the same fashion, some companies that have depended on IT for a competitive edge might lose that. Is there any risk of reducing IT to a commodity set of services that prevents companies from somehow differentiating themselves?

Schmelzeisen: In some respects that’s a valid question, because a lot of IT services will be commoditized over time. On the other side, there is an ongoing wave of new things coming in, and there will always be leaders and followers. So, we will see more and different services being deployed. In the future, you won’t be able to differentiate just through an email service, to give you one example of an IT service.

However, it's different when it comes to other things: the way you manage your environment, integrate things like SOA or deploy SOA in your environment, embrace new technologies, drive mergers and acquisition from an IT integration point of view, how you select whether you are outsourcing, out-tasking or keeping things in-house.

Those are really differentiating points for the future, and I'll elaborate a little bit on the latter one. We are moving to a full IT service provider environment. A lot of these service provider ideas really come down to what you keep in-house, where you compete with others, and where your capabilities complement others. So, they are really looking at a whole supply chain in the sense of looking at complementors and competitors. It’s becoming a value net that IT organizations will have to look at and will have to manage. That is where the differentiation will be in the future.

Gardner: Anything else for us on that subject, Jeroen, about the competitive issues and commoditization? On one hand, we're saying that commoditization happens, but it is good in that it levels the playing field for you to be innovative.

Bronkhorst: I agree with what Klaus said, especially in the area that new technologies keep coming up. You can find new things in the stores almost every day, and the more new technology that’s introduced the more complex the world becomes, especially for IT organizations that have to keep it all up and running.

The challenge for a lot these IT departments is to make the right choices about which technologies to standardize on at what moment in time, and how to balance the cost associated with that with the quality you provide to your customer base. The real challenge is in doing that in a way that you distinguish yourself from the world surrounding you and being aware of the role you play in relation to your competitors and your complementors, as Klaus indicated.

Gardner: On a more pragmatic level, for those companies that are not quite into this yet, but want to be, how do you get started? How do you say, "I want to have a professional approach to ITSM? I also want to learn more about ITIL and how that could be useful tools for me?" Should you do one before the other? Are they something you can do on a simultaneous track? How do you get started?

Schmelzeisen: You always have to look at three main components, and we have mentioned them a couple of times before. It's people, process and technology. As people are driving most of the changes it’s definitely a good idea to have at least a certain number of people trained and certified, so that they can make educated decisions on technologies and processes later on.

When it comes to the process work, this can start in parallel, but definitely requires trained people. Technology is something that is definitely very important, but technology alone will not solve the problem. What's your view on this, Jeroen?

Bronkhorst: I agree with that. For those organizations that do not know yet whether a process-oriented approach is right for them we have a very interesting simulation game from our education department. We simulate processes in a non-IT environment, and make people aware of the value that can bring to their daily job.

We don't go into any of the ITIL or ITSM specifics right away, although there is some theory in the training. It’s really a simulation, and that is what a number of organizations start with. There are others who are more knowledgeable in this area already, and they typically want to go straight into a discussion as to how to compare themselves to industry best practices and what areas to address to improve. Then, we get more into a project simulation and assessment type approach, where you basically have a discussion with each other as to where we are today and where we want to be in the near future.

Gardner: I've been thinking about this as something for very large organizations, but perhaps that’s not the right way to look at it. How does this scale down? Does it fit well with small- to medium-sized businesses, or even smaller divisions within larger corporations? What’s the shakeout in terms of the size of the organization?

Schmelzeisen: You can deploy it to very small organizations as well. There might be one significant change: the need for automation. My experience is that this grows with the size of the organization. So, if you are a 170,000-person company with a huge IT department, you ought to have automated processes. This obviously means the processes need to be standardized and well understood, and people need to be trained on it.

If you are a 10-person IT department, you still have to have processes, but probably if you are such a small group, and you might even be located in one place, you can still do this without automation, using more basic tools, even on paper. Nevertheless, the need to understand your processes and have them well defined is independent of the size of the company.

Bronkhorst: There is actually a book from one of the ITSM’s chapters around how to apply ITIL in a small-size business environment, though I think that underlines the point that Klaus is making.

Gardner: Great. Well, thanks very much. This has been an interesting discussion about IT Service Management, making IT a professional organization with customer-focused quality of service as goals, and how to go about that on step-by-step basis.

Discussing this with us today have been two executives from Hewlett-Packard -- Klaus Schmelzeisen, the global director of the Global ITSM and Security Practices at HP Services Consulting and Integration group, and also Jeroen Bronkhorst, the ITSM program manager with HP Services Consulting and Integration group. I want to thank you gentlemen both for joining us.

Schmelzeisen: Well, thanks, Dana.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions, and you have been listening to a sponsored BriefingsDirect podcast. Thank you.

Listen to the podcast here.

Podcast sponsor: Hewlett-Packard.

Transcript of Dana Gardner’s BriefingsDirect podcast on ITIL v3 and IT Service Management. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.