Transcript of Dana Gardner's BriefingsDirect SOA Insights Edition Vol. 3 Podcast with Analysts Steve Garone, Neil Ward-Dutton and Guest Jeff Pendleton

Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition, recorded Oct. 20, 2006.

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.

Dana Gardner: Hello and welcome to the latest Briefings Direct SOA Insights Edition, a weekly discussion and dissection of services oriented architecture- (SOA)-related news and events, with a panel of independent IT Industry analysts and guests. I’m your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions. This week, the week of October 16, 2006, our SOA panel includes Steve Garone. Steve is an independent industry analyst, a founder of the AlignIT Group, and a former vice president at IDC. Welcome again to the show, Steve.

Steve Garone: Thanks, Dana. It's great to be here, and I’m looking forward to some spirited discussion.

Gardner: It’s always spirited on SOA, and no one agrees on anything, right? Also joining us for the first time -- and welcome -- is Neil Ward-Dutton, a research director at Macehiter Ward-Dutton, an IT analysis and consulting firm based in the U.K. Hi, Neil.

Neil Ward-Dutton: Hello, Dana, thanks for having me on.

Gardner: My pleasure. Also joining us as a guest is Jeff Pendleton, a former IT executive who has filled many roles, at BEA, HP and other firms. Welcome to the show, Jeff.

Jeff Pendleton: Thank you, Dana. Pleasure to be here.

Gardner: Thanks. Give us a brief rundown of your background, Jeff, so people can appreciate where you’re coming from.

Pendleton: Well, I’m pretty much a jack-of-all-trades. I spent 16 years at HP, alternating between IT, marketing, and operations management. So I got a pretty good, 360-degree view of HP, and how it approaches the world. I made a run at a startup, spending a year in the garage, working on a SOA appliance startup with a bunch of really smart guys from Cisco, just before Cisco announced their whole Application-Oriented Networking (AON) initiative.

So I played around with that. I picked absolutely the wrong time to try to launch a startup, in 2000-2001. Then I moved over to BEA about four and a half years ago and ran their IT group, ran their education services division. And then I moved over and began a role as a BEA SOA community development evangelist, and also ran the product marketing group -- the whole AquaLogic, WebLogic, and Tuxedo product marketing function.

Gardner: And you’re not affiliated with any particular vendor at this time?

Pendleton: No, I left BEA at the end of May to really look at SOA from a different vantage point.

Gardner: The first major topic of discussion is the convergence of SOA and open source. This is an interesting development. We have a number of different projects in incubation and being supported by a variety of different contributors, including some of the largest vendors in SOA and software infrastructure. These projects run the gamut from approaches to tools into runtime governance, enterprise service bus (ESB), and even the possibility of some frameworks. These include some complete frameworks, stacks for SOA within an open source environment, as well as promoting and developing a commercial open source business model, a variety of which we’ve seen emerge in the past several years.

We’re also going to discuss this week the topic of SOA and market evangelism, and that’s primarily why Jeff is here. The idea is that SOA is a concept, a methodology, a paradigm shift in the latest approach to IT, computing and applications. But the fact remains that there is no one entity that represents or sells SOA as a concept. SOA is being brought to market piecemeal, through standardization efforts, through commercial products, from a variety of perspectives -- not always with a lot of user input, or at least evident user input. And, so we want to discuss this whole notion of how SOA should emerge in the market -- whose responsibility is it to define it and promote it.

Let's get to the news around open source. I attended, just over a month ago, the EclipseWorld Conference in Cambridge, Mass., and talked with a number of folks here, including IONA Technologies, and IBM, as well as Eclipse Foundation, about a variety of different activities that are now under way, several of which are in Apache incubation.

So there’s not a whole lot of publicly available information about these activities, but let me just give you a quick rundown to demonstrate the breadth of what’s going on. IONA has an Artix commercial ESB, and they spun off an open source project from there called Celtix, maybe two years ago. They have now taken Celtix into the Apache Software Foundation, and joined it with Codehaus XFire, an open source Java SOAP framework, to create a new initiative, CeltiXFire (CXF).

CeltiXFire is aimed at providing an open source services framework, and it's going to join a number of other SOA-oriented open source projects, including the Eclipse SOA tools platform project. Also in Apache incubation is Yoko, a CORBA initiative. Also in Apache incubation is Tuscany, a services component architecture (SCA) initiative, and also Qpid, a message broker project that aims to define protocols -- in a sense take up where Java Message Service (JMS) leaves off.

So, there’s the possibility here of a rather robust and ecology-driven SOA infrastructure stack, that could play a role as an entire SOA approach for some enterprises, ISVs, and software as a service (SaaS) providers. Or bits and pieces of this could be cherry picked -- particularly, I imagine, from the tools perspective -- and used in conjunction with other commercial SOA products.

Let's take a quick level-set on this. How seriously should we take these open source SOA projects? Why don’t we begin with you, Neil?

Ward-Dutton: We should take them pretty seriously as people who look at the market. I think for too long the industry, the IT industry, and this community has not really looked hard enough at open source and freely offered technology products. It's time that we really should take them very seriously.

It’s interesting to think a bit about the distinction between open-source and free, and how much that matters to people, particularly to what you might call end-customers. Certainly, if you’re going to expand the definition to include free, but not necessarily completely open source, today you could just look at Sun Microsystems and what’s now called the Sun Java Composite Application Platform Suite (CAPS), which is basically SeeBeyond's old portfolio.

It's been reengineered to a degree to support SOA, and there’s a hell of a lot stuff in there, which is available at no cost whatsoever. As usual with the open source model, if you want paid support or enterprise support, you have to pay for that, but you can get the software for free. So, it's not just about Eclipse or Apache incubator software projects, it's also about the really big gorillas of the industry taking big steps toward making stuff freely available.

I don’t see why that should appear strange because this is all infrastructure. It's all boxes and wires, just plumbing, and increasingly that is commodity technology. We’ll get on in a bit to talk about the softer issues around SOA, and I think that’s where the real competitive differentiation, and the real challenge, actually come -- working out some of the more business-focused issues, and some of the more methodology-focused, and quality-focused issues.

Gardner: One of the things that I find interesting about the emergence of SOA, and the emergence of open-source SOA, is that this is happening very early in the development of SOA. We saw other open-source products, perhaps Linux, come a number of years after Unix and Windows were quite mature. And some people would even claim that there was some reengineering involved. Also the open source Apache Web Server followed the Netscape Web Server and Microsoft IIS Web server and became very prominent in the market, and so, again open source followed the commercial lead. What I think might be different here is that open source has an opportunity to lead the commercial vendors when it comes to SOA. Does that make any sense, Steve?

Garone: Yes, it does. I think what you’re saying makes a lot of sense, although I think it’s less of an issue in terms of the connection between open source and SOA, and more an issue of the timing of SOA. The reality is that open source, in the case of SOA, was around for a fairly long period of time. Whereas in the other examples you gave it wasn’t. So, you naturally expect the open source community to kind of jump on this new initiative, as it will with other new initiatives as they come along.

I agree with everything Neil said. I think it’s important to take this very seriously, which does not unfortunately imply that everything at this particular point in time has stabilized. One of the things that one likes to see when you talk about technologies and issues that are “open” is that standards bodies are sort of leading the way, and we see a lot of that. But, what ultimately happens, or what happens along the way, is that you get competition even on that level.

You see organizations like ObjectWeb and Apache, and others, going off and doing their own thing. In similar areas, some are supersets of others. But that introduces a level of confusion to the end-user. We hope that eventually that will shake out, but I don’t think in the case of SOA it has done so as yet. One interesting example of that, by the way, is the example you brought up of IONA and Celtix. Now, Celtix originally was hosted by ObjectWeb. I think one of the factors in that choice was the fact that IONA is a European company, and ObjectWeb is already active in Europe.

But now, what they’ve essentially done is move that technology, in the context that we talked about earlier, over to Apache Foundation. So, even in the case of one particular vendor, there wasn’t a lot of clarity over the last year or two in terms of where that technology would reside, and who would be leading the charge from the standard’s body point of view.

Gardner: Jeff, let’s go over to you. It seems to me another opportunity with open source is that the users, large enterprises -- something along the lines of General Electric, Ford Motor Co., General Motors, and Boeing -- can come in and say, "Listen, we want a seat at the table too. And we want to have a say in how these technologies evolve." So first, do you take these open source projects seriously, and is there something new and different here, where we are able to get end-user input, and an open source approach to some technologies that have not yet matured?

Pendleton: I spent the last couple of years at BEA, really looking at open source, first as a threat, and then one day realizing, as a lot of vendors have realized, that open source is actually a stimulus for change within these large enterprise software and hardware companies. When you’re sitting in the middle of these software companies you have these machines that you have to keep running, whether it's your maintenance streams, or your product streams, or what have you. And it’s very, very difficult to change those things without some sort of a very severe external catalyst.

So from my perspective, open source is innovating and causing innovation that the vendors are at first reluctantly but then wholeheartedly beginning to accept because they really don’t have much choice. But as I’ve talked to CIOs through the briefing center at BEA, what I‘ve noticed is there is a real fear -- and almost a deer-in-the-headlights phenomenon that’s occurring -- because there’s so much open source and there’s so much change.

What these folks are worried about is, first, they’re still a little bit in the woodshed from the last big, exciting IT wave. Second, they’re worried about the complexity of what they’re currently managing, and the complexity of all of these new ideas and standards that are coming out. To a certain extent open source is really having probably as much, if not more, impact on the vendor community to catalyze change there than it is in terms of really having a dramatic impact across the board in a lot of these enterprise companies. I think they’re selectively picking up open source components. But I think that, if anything, it's adding to just the churn out there. It’s an interesting dynamic, but as far as SOA goes, I agree open source really has been, arguably, a SOA poster child for years.

Gardner: In what sense?

Pendleton: Well, by the fact that we‘re talking about a lot of independent components that are really attacking very specific aspects of the plumbing of IT, doing it in a collaborative way, bringing the best minds together, and really providing a loosely coupled set of capabilities that then theoretically can be woven by architects and developers into a richer platform. I think that to a certain extent open source has been living the SOA loosely coupled federated approach for years.

Gardner: I suppose the only way that you could manage open source approaches is to divide things into small manageable chunks, and then develop those chunks in a way that they can be, at least to a large extent, dropped, like a LEGO piece, into an existing or heterogeneous environment.

Pendleton: What’s really cool about it is that you are able to draw people with passion and with a certain level of expertise into that specific LEGO, and so you get a much richer service offering. Then you look at the vendors, and they take that and blend it into their capability over time. So you really start to get those composite effects when you blend what’s happening in the standards world with what’s happening in the vendor world.

Gardner: Do you think we can take this another step further, which is to say that we might not even be at this level with SOA as we define it if open source were not such a major trend at this time? Would we still be looking at monolithic SOA stacks from specific vendors?

Pendleton: Are you asking if the movement toward a comprehensive stack for SOA would not be as far along without open source?

Gardner: Well, SOA has loosely coupled parts that use messaging and a variety of technologies across boundaries for purposes of integration and process refinement, and publish-and-subscribe capabilities. Would we even be at this point, in this openness, if open source as a trend were not an accelerant or a catalyst to promote that?

Pendleton: Having lived through a multi-billion dollar experiment at HP, I would say the reason e-services -- as a vision for the industry -- didn’t succeed back in the mid- to late-1990s was because we only had within our portfolio the existing monolithic, tightly integrated capabilities. There were no standards. I was trying to build basically an SOA, a billion-dollar SOA prototype, with no standards, no open source, really a very narrow gene pool to work with. What we ended building was another monolithic stack from a very poor source of ingredients.

So, yes, I absolutely agree that open source has in many cases created a richer gene pool for us to create the next wave of IT.

Garone: I would agree with that to a limit. I don’t think you needed open source to be able to move in the direction of openness and interoperability to the level that’s required for SOA. What I think open source might have done is sort of held back the tendency of vendors to add their own little hooks, and their own little proprietary extensions and so on that often take open standards and industry standards and make them a little more difficult to work with in terms of putting together a solution with components from a lot of different areas.

Gardner: Perhaps this is a three- or a four-leg stool, and SOA is the top of the stool. The legs that are supporting it over time, and we need all of them there, would be open source, open standards, and the move toward distributed Java computing over the last 10 years. Perhaps a fourth standard or pillar on this would be this notion of the extended enterprise. If we didn’t have the need for all of these things, or they weren’t in place, then perhaps SOA would not be as we know it. Does anyone want to react to that?

Ward-Dutton: I’ve been kind of scratching my head for a couple of minutes, so I’m glad you mentioned the last leg there, Dana, because I was going to jump in and say that there has to be a need for it as well. Maybe when you said "extended enterprise" computing, that captures that. Certainly SOA would not be here if people didn’t actually need it, and that’s actually the biggest hurdle that we collectively have to help people get over. It’s not primarily a technology question anymore. It’s actually convincing people that SOA is a good thing to do.

Gardner: It’s about the business.

Ward-Dutton: That’s exactly right. It’s about explaining why a SOA-approach to delivering IT capabilities is really a sensible thing do, given challenges: connecting organizations together, dealing with transparency, and compliance initiatives, becoming more effective -- that kind of cross-departmental business processing.

Gardner: That makes for a very nice natural segue into the next major discussion point today, which is this notion of evangelizing and educating on SOA. But before we go there, I want to ask one more question on open source in SOA.

I’ve heard several people theorize that the number and complexity, as Jeff pointed out, of the open source projects and componentry are going to be a bit overwhelming for your average enterprise. Therefore they predict a consolidation, and we’ve already seen that with the Codehaus and the IONA Celtix combination.

So what’s going to be the right balance between this componentization within an open-source environment of SOA and the need for simplicity, and a bit more integration and unification around a common approach, or at least a common methodology that might give you some choices among the components you choose or use? What do you think the market will require for this balance? And I will go to you first, Steve.

Garone: Well, that’s a really good question. And it’s a good question because it’s an interesting one for decision-makers. It’s also a very difficult one to answer.

For me, the criteria are not going to be so much: To what degree do we componentize versus have a more integrated approach for some application domains. To me the real issue is how do you transition an organization? Neil used the words "make the business case," and it’s a good thing to do.

It's also important to make the case that SOA is not a bad thing to do. And where that manifests itself is in: "What do I have installed today, and how do I best leverage that within the context of a SOA-based environment." To me, the answer is not so much how many components I use, how granular are they, and how much variety I have, but rather, "Can I make new application logic that I build within a SOA context componentize, and so on? Do I make that work well with what I already use, and what I already have installed, from the standpoint of applications, especially enterprise applications?"

Gardner: How about you, Neil? What’s your position on the proper balance between open source componentization in SOA, and an open source integrated stack approach?

Ward-Dutton: I think the best way to answer that question is to think about supply chains, about the delivery of software as a supply chain. The degree of componentization that makes sense depends on where you sit in that supply chain.

The degree of componentization we have historically had and what we are experiencing now is the reflection of two things. First off: The main people who are actually doing something with this stuff aren’t end-users, but they are really getting in there and making things happen. They’re still actually within the supply chain. They’re not at the end -- that’s one.

The other is that where it is an end-user situation that’s occurring where those people are playing, those are very leading-edge adopters of technology. And so there’s a high degree of tolerance for a high degree of componentization of these things. As the market matures I would fully expect to see much lower tolerance for that, and a much greater interest in aggregated offerings.

So you look at what SpikeSource does, for example, or you look at the announcement from Novell a couple of days ago around integrated stacks of Novell technology, IBM technology, open source, closed source. As you get into segments and scenarios, which are less leading edge, they actually want the reassurance that comes with bundling, and that comes with aggregation and comes with, "Don’t tell me about the details, just tell me it works."

It’s a question of maturity, of where you sit in the software supply chain. To a degree we're kind of dancing on the head of a pin, because -- don’t forget -- this is open source. Although there is a consumer predisposition to a certain level of granularity, actually it doesn’t really matter. Because within a project if someone wants -- metaphorically speaking -- to break something up within an aggregation they can absolutely do that because it's open. So, they can break something apart and mess about with it that way.

Gardner: Right. I would like to answer my own question through a little slightly different lens or focus, and that is around the politics, or the power politics, within infrastructure decisions. If I were an enterprise I might look to bring in open source components for those which I view as most likely to be a lock-in type of a technology. I might be more comfortable going with a commercial vendor on parts that I think will remain in some competition, and that I might be able to pick and choose among different commercial vendors as well as open-source components.

But for something perhaps like an ESB or a data-services approach or framework, and certainly from a tools perspective, I might be more inclined to go open source so that I can avoid lock-in and provide myself with a reduction of risk moving into the future, a future which I have very little insight into. Can you react at all to that, Jeff?

Pendleton: Well, that comes from a position where the architect is a key decision maker within the IT community. In organizations where architecture matters that makes a lot of sense. But my experience is that there’s kind of this interesting politic within IT communities where a lot of the open source decisions are still being made by what I call the "fighter jocks" that are in the development organizations.

To a certain extent they are bringing open source in because it makes their job a little easier, but also because it's cool. It's interesting to look at the political dynamic that’s happening right now within IT to figure out how to break that architecture-vs.-developer struggle that’s going on. So when you talk about bringing in choke-holds and things like that, it makes a lot of sense when the architects are in charge. But it’s a different kind of flavor when the development organization, which is being sponsored by a powerful line-of-business team, is really trying to drive an innovative piece of applications. I don’t argue your point so much as I think its only 50 percent of the equation. I think that a lot of the open source is coming in because it’s cool.

Gardner: Does a SOA by definition require a bit more coordination, communication, and harmony between the development teams and the architects -- and even the operators?

Pendleton: Architecture, and I mean the "A" in SOA, is really the defining element -- and the disruptive element. In my opinion that is going to really define the enterprise of the 21st century. And I’m not just talking about IT architecture. So, absolutely! I’m just pointing out that I think we don’t really have strong architecture in most corporations today.

Gardner: So people are often still thinking tactically about different parts of this but not holistically from a strategic overview?

Pendleton: When you talk about not wanting to get locked in it's generally something that’s more applied to vendor lock-in, traditional vendor lock-in, and it's generally more of a decision that’s being made by the CIO for very pragmatic reasons. But when it comes to open source there’s still a fair amount of the old West cowboy activities going on in most IT organizations.

Garone: If I could just jump in and add something briefly. That’s a great point Jeff, and in fact in my experience, especially over the last year or two, SOA within organizations has typically been done on a small scale, a pilot project and so on, which would be initiated in many cases by the development community by establishing a set of technologies. Maybe it's an ESB, maybe it's an application server, or open source in the situation we’re talking about here.

Then, when it comes time to expand this, when you have success, you want to expand it throughout the organization, and only then do the architects get involved. Now, you’ve got a technology and a basis of experience in a particular technology and there’s an incentive to some extent to stick with that. I think that’s really where what you’re saying comes into play.

Gardner: Well that makes another natural segue into our next discussion point. And that’s about how we evangelize and educate the concept of SOA as strategic, as architecture, as a long-term approach, when we’re still stuck in kind of a tactical decision-making process, and we have a variety of different vendors, and open source projects approach to componentry on the tactical level.

Let's start with you, Jeff. Perhaps you can explain some of your thoughts about evangelizing SOA and why you’re heading in that direction, both as defining the problem and then perhaps we can all think about some solutions.

Pendleton: Okay, as I mentioned early on I’ve been suffering from schizophrenia for a number of years, in the sense that I would be on the IT side really trying to drive application development. Then I’d jump over to the general management side. It was always amazing how my perspective on IT would change, depending on which hat I was wearing.

In one case, as IT, I was trying to bang the table saying, "We can really add competitive advantage here," and then moving over to the other side and looking at IT as an inhibitor and a road-block to achieving my quarterly numbers, and IT as something that was very, very expensive, and very risky.

So when I looked at SOA and talked to a lot of customers we were all in agreement that SOA was very, very disruptive, and in fact probably will be the defining element of the 21st-century enterprise. But for some reason we weren’t able to bring that message to the line-of-business guy, who still had this parochial, or somewhat skeptical, view of IT. They just weren’t hearing and understanding the potential.

So this summer we brought a bunch of folks together from some of the fiercest competitors, from some of the largest companies, to start talking about what is it about SOA that really is going to the define the 21st-century organization. I’m not sure we have the answer yet, but one of the things that we’ve noticed is that the vendor community is preaching to the choir for the most part. They’re talking about the power of SOA to folks who kind of understand the potential of SOA.

But when you go to the people that really need to see IT as strategic again we’re delivering messages like "agility," "flexibility," "adaptive," "liquid," which are like motherhood and apple pie. The real challenge is telling what it is about SOA that's so disruptive because I’m not sure line-of-business guys are going to care about SOA any more than they cared about client-server during the second wave.

What is it that is so disruptive? It’s not the LEGO approach per se because when I was at HP -- talk about a LEGO company; every LEGO was completely autonomous -- it was a cat-herding exercise. Loosely coupled was the HP way, and that didn’t work. Then you go to these large monoliths, where they have very much a top-down driven execution, and that doesn’t work.

So, what is it, and how do we start to make the potential of SOA a practical and pragmatic strategy? ... Make it something that IT people can bring to the business, so that the business people can say, "I get it, and what’s more, I can measure it, and I can see how it’s going to affect the various financial statements."

That’s what the industry is struggling with -- to break out of this preaching-to-the-choir marketing and really being able to take these very generalized notions of agility and LEGO-like use and translate them into something that’s consistent with what we saw with the second wave of IT, where we were talking about quality and the customer, and the notion of process core-competencies. We need things that business people can get their heads wrapped around, that are aspirational enough but also practical enough that they can execute over a couple of years.

Gardner: Let’s go to Neil. What sort of terminology do you think is required in order to bring to those line-of-business folks a business case for this fundamentally different IT approach?

Ward-Dutton: The challenge is that it's very difficult to say one thing that’s going to suit everyone, because SOA is kind of both everything and nothing. It's like dancing on a head of a pin.

Garone: Well, that message isn't going to work.

Ward-Dutton: Yeah, exactly.

Gardner: Well, that is the message right now.

Ward-Dutton: SOA, by itself, isn’t really anything. It’s just a way of thinking. It doesn’t do anything. You apply that way of thinking to a problem.

Just take a step back. The fundamental challenge we have today is that looking through five decades of “IT innovation” we’ve ended up in a situation where no one really knows where to go because the level of complexity in systems is so high, the level of brittleness is so high. Businesses change and changing requirements is very rapid.

The number of stake-holders involved in anything to do with IT is ridiculous. It’s a kind of locking up of the very gears that should help business and IT work together. And the reason we’ve got here is that business and IT together have kind of sleepwalked toward this situation because they didn’t have the ability to generate consensus between themselves that a short-term view had to be balanced with a long-term view.

You have to do both. What we have with SOA is a catalyst to start doing that. There are reasons and there are methods for actually keeping the short-term at the front of our minds, but also keeping the long-term in the picture at the same time. That comes back to be idea about architecture, but fundamentally it has to tied into the short-term because you can’t make something real that is about a "big" vision. People don’t buy it.

Even with business process re-engineering in the 1990s, it didn’t really work that well for everyone because they couldn’t sustain that level of commitment. There are a few poster children but it didn’t really happen broadly. So there have to be short-term tactical hooks, but at same time a much longer-term broader-value message just sits behinds it. And that’s the challenge we all face with SOA, because when you’re looking at the tactical side the message that an IT shop has to give to its “business customers” is absolutely tailored to that particular business situation.

That’s what I mean when I say SOA is everything and nothing. You can’t have one set of messages that works for both the long-term and the short-term story, and that works for everyone. Does that make sense?

Gardner: Yes, it certainly emphasizes the challenge.

Ward-Dutton: It didn’t give us your answer, of course.

Gardner: Well, you probably wouldn’t give it to us on this show, if you had it -- right? That’s probably a pretty valuable piece of information.

Steve, you and I have talked in the past about how risk reduction is a pretty good message around SOA -- that you can reduce your risk going backward in time, that you can leverage your investments and you can modernize and you can continue to deliver applications and services and data as people have been accustomed to.

But you can also reduce your risk moving forward, either into the foreseeable future where you know that you’re going to have certain requirements and a certain approach of agility, and you can reduce time-to-completion, and higher quality, and take advantage of a wider variety of services, and perhaps embark on some general reuse and object oriented principles. But you might reduce your risk even going beyond that into things you can’t predict and understand, or know yet.

But risk reduction is still also rather nebulous, and it's not something you can take to line-of-business people and say, "We’re going to reduce your risk. Can you double our IT budget?" Do you have any other thoughts here about the proper message that can be both tactical, strategic, IT, and business?

Garone: Wow! First of all, that was a great synopsis of the benefits and advantages of SOA. I think it’s right on. We’ve been talking here about the long-term versus the short-term, the tactical versus strategic and everything you just said, Dana, sort of plays into that.

To me the messaging, really the gap in the messaging, manifests itself in what you’re actually saying versus what you can actually demonstrate. It's the story versus the evidence. There’s no magic here. Vendors have for a very long time gone out to their prospects and customers with potentially very impactful and very interesting studies and case-studies that demonstrate ideally within their particular type of business how this technology has been used to create real advantages in terms of not only costs, but also in terms of business value and increasing the ability to do business more efficiently and so on.

To me that’s really the key. The messages are there, but the question is how do you demonstrate to a particular customer that this will work for them? For me, the only real way to do that is for vendors to work very, very closely with customers to make it happen for them in individual cases, and then bring that story to the rest of their customers.

Gardner: I think that sounds a little bit like a rehash of what we’ve been through for the last five years. After the dot-com bust, after the telecom bust, after the contraction in IT spending, everything was about ROI and TCO. And it sounds to me like you’re still trying to do an ROI-TCO cost-benefit analysis approach to SOA.

Garone: Certainly that's part of it but I wasn’t implying that it's all you need to do. Again, there are distinct advantages in terms of all the "... ilities" that you just went through that we recognize unto themselves, but may not be very effective to a business manager. If you then demonstrate those "... ilities" with real examples -- how it was done within their industry -- I think that can have a very positive effect. And, it’s not just restricted to numbers.

In fact I would make the case that not only should one not restrict yourself to that, but it maybe impossible to do anyway. A lot of the end users I know don’t really want that kind of information presented to people who are their potential competitors. Whereas in a qualitative sense they like the PR associated with being able to say we’ve done a really good job at this.

Gardner: Let’s get back to you, Jeff. Obviously we still need to work on the message. What about the messenger? We don’t seem to have a figurehead for SOA, like we’ve had in some cases in the past. We certainly had Linus Torvalds for Linux. We’ve had Larry Ellison for databases. We’ve had Bill Gates for client/server. Do we need a better messenger, in addition to a better message for SOA?

Pendleton: Well, I think there’s two sides to the coin. One is the messenger to the IT community, and then the messenger -- or messengers -- to the business community. The client/server, despite Bill Gates's evangelical power, was not what really catalyzed that wave. I don’t think line-of-business people bought client/server. They bought some higher level of abstraction. They were buying into the total quality movement. They were into this whole notion of core competency -- really understand your processes, and which ones add value, and which ones don’t ...

Ward-Dutton: ... And freedom.

Pendleton: Yeah. Go talk to SAP about taking over the processes that really don’t add value. That catalyzed the whole ERP wave, which catalyzed the client/server. There was this very interesting dynamic that met in the middle. What we don’t have right now are those inspirational, aspirational, definitional messages that define the enterprise of the 21st century.

Gardner: So we need a sort of a passion, and also a spiritual level to the drive to SOA?

Pendleton: Yeah, the Tom Peters way -- and that may be out of vogue. People may be very skeptical. But having watched HP spend billions of dollars executing strategies and then looking at the ROI after-the-fact, or looking at the ROI to justify a decision that had already been made, I think that we don’t yet have those agility strategies that will then drive the conversation with IT: When the executives ask, "So how are we’re going to do this?" and then IT says, "Well, it’s all about architecture, and look at what we’re doing with SOA." Somehow we need to marry what’s going on in the IT community with something equivalent in the business community.

Gardner: So, a complete narrative that brings in the tactical and strategic, and crosses the chasm between IT and business?

Pendleton: Yes, look at business intelligence. You can argue that it was catalyzed by Sarbanes-Oxley and all of the regulation, but the reality is that most corner-office executives really find out what’s happening in their business through interrogating their managers, and their managers' Excel spreadsheets.

How many guys are going to bed at night really wondering if they know what’s going on in their organization? The whole compliance-regulation thing has made it more powerful, but even without that as these corporations have gotten larger and more global it’s very uncomfortable to understand you don’t really have control. You’ve got this powerful enterprise with a lot of capability, and they want to know: "How do I bring that together, and bring a better offering to my customers, a richer offering? How do I get a bigger share of the wallet, taking advantage of my total enterprise?"

Gardner: Well you know who I need to invite on this show -- and I’ll go ahead and do it, but I’m not going to hold my breath -- Steve Jobs.

Pendleton: Absolutely. Everybody keeps coming back to that guy.

Gardner: If we could apply his genius of creating passion and drive around IT for its own sake -- never mind for these larger issues of strategy and ROI and TCO, which he usually doesn’t go to -- if we could get Steve to put his special sauce on SOA that might help a lot.

Pendleton: I bet he’d never even talk about SOA. I bet he’d never ever mention it, because that’s not what business people are buying. That just happens to be there to enable it but they’re buying something else, and that’s where we’re having the problem.

Ward-Dutton: Dana, it’s interesting the examples you gave when you were talking about evangelists. They were all really technical examples. Remember the point that -- I think it was Jeff -- made about people not buying client/server. I talked to people. Those guys were buying freedom. They were buying freedom from the shackles of the mainframe, which was something that was very closed, very powerful, and [freedom from that] held a lot of promise. A lot of people were very excited by it.

Gardner: It was mysterious. You never knew what was going on behind those glass doors.

Ward-Dutton: Right, and there was no way in hell you were ever going to get close to it. It was reserved because it was very, very expensive. In the mainframe era people bought dependability, efficiency, and accuracy because it was all about very high volume and very reliable transaction processing.

So that’s what people bought. They bought a tool to help them automate things that had to be done quickly and by rote, very, very dependably. In client/server, they bought freedom. They bought the freedom to use what was a radically different model of IT to devolve power and responsibility to individual lines of business. So it didn’t have to depend on those weirdoes sitting in the data center.

With e-commerce they bought into a promise of global markets, and the ability to radically change business models. SOA gives us all of those things, but the problem is that the IT community has created its pitch, as they would say over here. They’ve cried wolf too many times over their promises. Why should they believe us now?

The problem is that SOA actually does all those things. It helps organizations by aligning IT and business more closely. It helps organizations become more service-oriented and componentized, which enables organizations to more quickly adapt to new business conditions, enter new markets, compete globally, and do all that kind of stuff. It helps them be rock solid and dependable in how they get hold of information, so they know where they are. If you don’t know where you are, you can’t innovate.

Gardner: Let’s look at this lineage of freedom. We had the freedom of the PC, which then bled over into the freedom of client/server, which then bled over into the freedom of the web, which then bled over into web services, and is now bleeding over into SOA.

So, it's all about individual empowerment and freedom, which comes at a very auspicious time because this "echo boom," that is to say, the children of the baby-boom generation, are now thinking quite a bit differently. They like independence. They do not like a top-down approaches. They do not like to be told how to do things. They like to explore on their own, as evidenced by such things as Web 2.0 and social networking, and MySpace.

To appeal to this younger, echo-boom generation, we need to encourage that level of exploration on your own terms, individual approaches, not a cookie-cutter kind of methodology, but a kind of a messy, creative-chaos approach. So, do we take this continuation of freedom, and apply it in some better way to what services on your terms is all about? Jeff?

Pendleton: Well, freedom is great but when you have to hit your numbers every quarter, when you’re signing up for a two-year plan, you need to have confidence that you’re ultimately going to execute on a portfolio of strategies that execute against those management-by-objectives (MBOs). The MBO is what drives line-of-business guys.

I think that you'd want freedom to invest and enable some percentage of your strategy, but at the end of the day we’re kind of handcuffed by this need to hit our numbers every quarter and every year. I’m not sure how that’s actually going to manifest over time, but the last thing I would want to do is have more cowboys in my IT organization.

What I’d like to try to figure out is how to have a blueprint, and a strong architecture team ... imagine if you were building a corporate headquarters. You probably wouldn’t want to do that with just a free-wheeling set of cement layers and plumbers, and what have you. You’d probably want to have a really rich architecture and blueprint.

Ward-Dutton: It's about who has the freedom, isn’t it?

Gardner: But wait. I read about this guy, Frank Gehry, who builds buildings that look like they were put together by creative chaos, but are actually highly architected in order to make that possible.

Pendleton: But are there a thousand developers involved in actually building that blueprint. He draws the picture, and then he works with sub contractors and contractors to execute on that.

Gardner: Do you think this is a valid metaphor for SOA, a Frank Gehry-type architecture?

Pendleton: Absolutely! Positively! I was looking at a picture of a rabbit warren. I don’t know if you’ve ever seen one of those, but you take a bunch of rabbits and you put them on a 100-acre field, and basically you build the enterprise of the 20th century. It's just holes going everywhere. They just dig, dig, dig. It's kind of is a picture of what the architecture of most enterprises look like. We don’t have the same type of pride and passion going into the internal architecture and workings of the enterprises that we do going into the corporate headquarters.

Gardner: That very interesting, isn’t it? Perhaps from the IT architecture perspective we've got a Frank Gehry-looking application that actually is as messy inside as it is outside. But what we really want is to have an elegant creation that’s beautiful on the outside and the inside.

Ward-Dutton: It’s about the right freedom for the right people. You can’t build a creation in enterprise IT because change is too constant. So you can’t build something. You can’t build anything. All you can do is build scaffolding.

Gardner: You can build an architectural approach, right?

Ward-Dutton: Right. A great approach to architecture is to partition a business and to partition IT up into domains which have different qualities. Some of them will be very stable, and very predictable. And for those you can actually optimize for those things you may not use a SOA approach.

In certain areas, particularly around the edge of the organization, where you want to connect with customers, with partners, with suppliers -- where you really want to innovate in terms of how you build products and services, that's for SOA. Actually, you don’t want to build a building. You don’t even want to build an open-plant building, where you can move partitions and cubicles around, although that’s better.

What you actually want to build is foundations and scaffoldings, so that prefabricated chunks can be pulled together very, very quickly, and torn down very quickly. That’s not about building a building, it’s about building the tools to build and tear down bits of buildings very, very quickly. And in some places you want to do that and in some places you don’t. It’s about balancing the two.

Pendleton: Sounds like a Hollywood sound stage.

Ward-Dutton: For some bits of a business, absolutely. Not every thing.

Gardner: All right, gentlemen, I’m afraid we’re going to have to leave it there. We’re out of time, and obviously this is a very interesting subject that we’ll be revisiting over and over again. And perhaps we’ll get closer to how to best conceptualize, and go to market and provide messaging for SOA.

So I’d like to thank our guests, Steve Garone and Neil Ward-Dutton, as well as Jeff Pendleton. I’ve been your host Dana Gardner, principal analyst at Interarbor Solutions. You’ve been listening to a weekly Briefings Direct SOA Insights Edition. Come back and listen again next week. Thanks everyone.

I would also like to point out to our listeners that if you'd like to learn more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, feel 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. 3. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.

Transcript of Dana Gardner's BriefingsDirect Podcast on PC Remote Administration in the Ramp-Up to Windows Vista

Edited transcript of BriefingsDirect[TM] podcast with Dana Gardner, recorded Oct. 18, 2006.

Podcast sponsor: LogMeIn.

Listen to the podcast here.

For an instant trial of LogMeIn Rescue, the solution Rent-A-Geek relies on for its highly successful remote support business, visit www.LogMeInRescue.com/podcast. Within five minutes of signing up, you can conduct your first remote support session. And, through this special link, you’ll receive an automatic three-week trial (a full week longer than the standard trial). Get your trial going at www.LogMeInRescue.com/podcast.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to a sponsored BriefingsDirect podcast. Today, a discussion about PC remediation remote service, using the Internet with some very powerful new tools that allow people to get into PCs and fix them, keep them well-maintained, and, of course, also gain remote access business opportunities.

To help us understand the burgeoning market opportunity for such remote remediation, we are joined today by Keith Schiehl. Keith is president of Rent-A-Geek in British Colombia, Canada. Thanks for coming along Keith.

Keith Schiehl: It’s pleasure to be here, Dana. Thank you for having us.

Gardner: Keith, tell us a little bit about what has been going on with remote PC tech remediation. It seems like it has gone from a high-touch, retail, and local business to suddenly a global software-as-a-service capability.

Schiehl: Absolutely. And the remote aspect has been around for years, with programs like Remotely Anywhere, PCAnywhere, etc. But what’s really happened here in just the last few years are the remote technologies that don't require software on the end-user’s side. All it requires is that the end user enter a certain pin code or go to a Web site and download a Java applet.

Now, we are able to help anyone, anywhere in the world, as long as they have an Internet connection. Whereas before -- with the other products -- it required that you install the client product, that you open up port forwarding on their routers and firewalls. This works right through the network, and that’s what makes it so widely available now -- that anyone out there can get support.

Gardner: Interesting. Now tell us about Rent-A-Geek -- of course that kind of sums it all up in the three words. But tell us of the story of Rent-A-Geek. How did you start, and where do you expect to be going on in the next couple of years?

Schiehl: I’m in British Colombia, Canada. I came up here in late 1998 from New Orleans. And my background in New Orleans was doing data warehousing. I had worked at the university level, at the government level, did my graduate studies in information systems. When I came up here, I came camping and decided that I didn’t want really to leave. I made my home here.

But Canada was in a recession at that time, so there wasn’t job availability in my expertise area. So I did what I have always done, which was work at the PC level -- fixing PCs. It just started as a one-man shop, and in the next two years it grew and grew to the point where we went from just myself to having seven technicians full-time.

Then, we took on the remote aspect of our business -- where we are no longer focusing on our little valley here, but now we are using LogMeIn products. We’ve reached out from our little valley and now we have clients on four continents.

Gardner: And how far do you reach?

Schiehl: Our customers are in every state in the U.S. and every province in Canada, so North America. We have got Australia. We’ve got a little community in China, where it's all U.S. executives. They have their own little community over there to do business. So we have several clients there. And then also in Europe: in England and in Germany.

Gardner: Okay, so in the olden days -- and we're really talking just a few years ago -- somebody would have a problem with their PC. They’d probably look in the Yellow Pages and they’d see "Rent-A-Geek," and give you a call. And you’d probably have to go to see them, or have them schlep their PCs to you. Tell us of what kind of problems you deal with on that level?

Schiehl: Sure. We have the brick-and-mortar store, and we do on-site as well as in our valley -- and that’s how customers still find us. Originally, very few of our customers even understood that we did the remote thing. Many of our international clients who call have called because they had heard or seen a geek-type name, or they Googled for help and found us. They go to our Web site and they assume that we’re there in their neighborhood. So they call us.

Actually many of our clients call us for on-site service because that’s all that they know. Then we have to educate them and say, “Hey, you know what? We are not in Illinois, but we can fix this right now. Do you want to try this and sit back and watch?" And they go, "okay." Then, we begin and they are just blown away that we can actually do that.

Gardner: Now what if your PC is totally crashed, all you get is maybe a blue screen or some kind of a nasty message. Can you take them from that point and get a remote access to their PC?

Schiehl: Yeah, as long as the hard drive, for example, has not completely failed, or the power supply has not completely failed. If we can get that thing powered up, we can get them through the process, no matter how quick or long it takes. We can get them bootable. And once we can get them bootable and into safe mode, then we can fix it.

Gardner: What’s the growth opportunity here? How fast are you growing now, and where do you think this can go from now, for let's say the next two or three years?

Schiehl: Well, in the last two years we have grown at an average rate of 500 percent per year. It's been phenomenal, but really that’s just been off of referrals and people in our valley referring us to family and friends all across North America.

Beyond that, the opportunities here are astounding. Our target market, the people that we really serve, are the small-office, home-office (SOHO) end users. We have a very fiercely defined target market. These are the people we work with, and there's a total market of $30 billion right now for outsourced IT support. So, how much of that and how big we can go is simply a matter of how scalable we make our operation. And that’s a whole other story. We’ve got a business model and plan in place to address that.

Gardner: So, you can scale up on the warm bodies, and you can use these technologies. But let me understand the breadth of the service here, not just for recovery. I am a small-business owner myself, and if I have a problem and I find you guys and you help me out. I think my next question would be, "Well, what can you do to help me not have to go through this again?” And what’s your typical response?

Schiehl: Prophylactic measures against viruses and spyware, after we do the clean up, is the big part of our business model. It’s about the education. It’s about putting the pieces in place, putting in a guarantee that this won’t happen again for a certain number of days. With the end users, it's all about education. And we get clients calling us for very simple problems to us. But for them, they are very intense, very stressful problems.

Gardner: All right, so how do you keep those people from losing it? How do you make their day, and what are some of the enabling technologies that you can bring in, so that this is a pleasant experience and they do want to come back for more?

Schiehl: Well, we always start with the human aspect of it. We have some very defined core values in our business, the first of which is: fun. Then, we have education, success and understanding. These are all based on interpersonal reactions, and we use something called the "Fish Philosophy," based on the Seattle Pike Place Fish Market. It's all about being present, choosing your attitude, making his or her day -- looking for that opportunity to make somebody’s day.

Our guys are actually trained to actively listen first, before they formulate a response, to ask the right questions and then look for that opportunity -- to really make someone’s day. Because if they can do that everyday, for 365 days a year, times the number of technicians, times the number of years we are in business, then we can create a massive change out there in tech support.

Gardner: So, you’re probably providing a little bit of psychotherapy. Because I know when I'm at that blue screen position, I am ready to toss the whole thing out the window. I am stressed and not in a happy situation, particularly if I am losing work and money as a result. Tell us about that personal touch in terms of what the technology can bring?

Schiehl: Okay, and really we consider ourselves as relationship counselors first, and technicians second -- and we mean that. Because the relationship between the end user and their technology can be as tenuous as any marital relationship. And that always comes down to communication, just understanding why the other person -- or computer, in this case -- is behaving that way, and that it's not personal. We can help you guys communicate better and help fix this. And sometimes it’s a case of helping to fix the user.

Gardner: You can’t afford to have technology go bad on you when you are helping somebody with his or her technology.

Schiehl: That's right. Given that somebody is already in a stressful situation, the enabling technologies of the LogMeIn Rescue product that we use for remote support makes it so easy for the end user. They are initially very stressed and they say, “Well, I am already not good at working with computers, and now you’re asking me to launch a remote support session? This is absolutely foreign to me. I'm not comfortable with that.”

And so, we simply ask them, "Can you open an email? Do you know how to do that? Do you know how to view a Web page?" Because if you can view a Web page or you can open an email, we can help you.

Gardner: Okay, so you mentioned LogMeIn. How did you settle on that? What was the process for choosing that?

Schiehl: Well, before LogMeIn Rescue came about we had for years used things like PCAnywhere. It almost required a technician on-site to set up the software, to do a remote session. But after that we used another product that came out a couple of years prior. But the problem with that one was that it was at the price of about $450 per user-license, and you’re only enabled to do one session per license at any given time.

So, we used that for two years, but every month when we paid for it we just sat there shaking our heads saying, “There’s got to be a better way.” And then when LogMeIn’s product came out, when Rescue came out, they were offering it as a free trial. So there was absolutely no commitment. But it was $99 per month thereafter, if you chose to keep it. Moreover, you could do up to 10 simultaneous sessions with the LogMeIn product as opposed to the one with the $450 product.

So, for us, we immediately downloaded it onto five machines in the shop and began generating revenue. And at that point there was just no turning back. In fact, we felt so bad about generating revenue on a free trial that we signed up right away.

Gardner: So, this was a benefit to your business model, but also suited your technology needs, and architecturally because this is a peer-to-peer technology, and that’s got some benefits too, right?

Schiehl: You bet! They’ve got 256-bit security, end-to-end so it’s absolutely encrypted for the data, for transfers that are taking a place. The end user doesn't have to install software. It's just phenomenal, and makes this so easy for the client; they don’t have to have any technical knowledge to make this work.

Gardner: How has the type of problems that people are coming to you with changed over time? Now you're servicing four continents, you’ve got people remote – are you facing the same types of problems? And could you also explain what PCs you are mostly working with? It's Microsoft Windows XP and Windows 2000, is that right?

Schiehl: Yes, XP, 2000 -- and also Windows 98 and Windows 95 are still out there, and we still work with them. But the problems are pretty well universal, whether it's just a software issue with Outlook Express, for example, not downloading messages, not able to send things; whether it's a firewall or something blocking it.

Of course, there's the huge, huge problem of malware, spyware, and viruses that are coming in today without the user even having to open an email. All they have to do is view a Web page that’s infected, where the malformed image or whatever the exploit of the day is, and they are getting infected without any interaction.

Gardner: This is disaster remediation. More and more small businesses are getting more dependent on their PCs, and yet at the same time probably losing precious time that they need. They can’t go down, they are working on a mission-critical basis, just like large enterprises.

Tell me a little bit more about the managed-services industry. It seems like if you’re growing 500 percent year over year for two years, there's a big business opportunity and a potential $30 billion market to go after. How do you take your business and continue to grow it, and do you think that this is unique to you? Where do you see industry as a whole going?

Schiehl: I don’t see it so much as being unique to us. However, we are being very intent in the way that we are growing. We have very specific goals and landmarks that we set for ourselves, benchmarks that we set for ourselves. We’re managing our growth through a series of referrals first. Then, we have some affiliates that we set up, second. And then, in the end, when we create our new model, we’ll be dealing with more mass exposure. But, right now, we’re trying to limit our growth if anything, so that we can manage it properly.

Gardner: Okay. When you get control over someone’s PC, does that tend to flip him or her out a little bit? I guess I’d worry about privacy and security, if all of a sudden some guy in British Columbia is monkeying around with my PC. How do you keep people trustful and sort of comfortable with that?

Schiehl: Well, certainly there's apprehension initially. The first time somebody sees their mouse moving without them touching it, that tends to freak them out a little bit. So, we have to overcome some of that resistance through a dialogue.

Initially, the people say, “Well, I was really expecting to have somebody come over to my house. I am not really comfortable with you being up in Canada and I am down here in Denver, and you’re coming into my computer.” And we say, “Well, look, we’ve got this product, but you’ll always have overriding control of the mouse, of the keyboard, etc. You’ll always have the ability to end the session anytime you want. Now, we stay on the phone with you while we’re doing this, so it's like we’re there. But would you rather have a complete stranger come into your house, where he has access to everything and not just your computer?"

And they're like “Well, okay. I guess they didn’t think about that."

Gardner: And once the session ends with the technician on your end, the "geek," they can’t get back in unless the other party allows him, right?

Schiehl: That’s right, it’s a dead cookie at that point. That’s one thing we explain to them, because we give them a unique six-digit pin code, and they always want to write it down, and we say, “Well, don’t bother writing it down, because it’s no good after this session. It will never work again.” And they go, “Oh! Okay.”

Gardner: Let's get back to that situation where I’ve just suffered some malware. I am frozen, but I am able to at least have someone on the phone talk to me into safe mode, I can get this session going with you, and then my first reaction is, "I can’t go through this again. Is there some sort of a routine maintenance?"

Can I just say, “Listen, I am now comfortable with you guys coming into my PC. We have a business relationship. I know that I can turn it off as I need to, but can you come in here behind the scenes and help me so that I am clean and up and running, and I don’t have to worry about this stuff?”

Schiehl: Yes, and we have two ways of doing that. We either have the on-demand model, which requires them to call us and initiate a session. Or we have the model where we just come in and do it, and that involves another LogMeIn product, called LogMeIn IT Reach. That’s a unique and special product that we use for customers who are very comfortable with it, because what that product does is it stays active on their computer, all the time, and it monitors critical system processes.

Then it will email us, it will instant message us, whenever an event fault comes up or an XP event comes up; or if, for example, their temperature gets too high in the computer. There are certain trigger points, things that you can set to monitor that we get informed about. So, we call the customer and say, “Hey, look, this is happening to your computer. We’re thousands of miles away, but your fans are not working properly. So, you need to get that addressed immediately.”

Gardner: And LogMeIn IT Reach has the sensors in the PCs that can tell them this? Or is that your scripts and your stuff?

Schiehl: That’s IT Reach.

Gardner: So, we’ve got routine maintenance. There must be more services. What about backup? That’s another thing that I use as a small business. I am doing it myself manually, but I kind of like the idea of it being up in the cloud and automatic.

Schiehl: That’s something that we’re just starting to get into -- being able to do backups. And not only for the client at their particular site, like setting backup routines for them that will operate with their own external drives, for example, but also using a new product that LogMeIn just acquired called Hamachi. Hamachi sets up a software VPN between our computers and the client’s computer.

So, it’s just like having a VPN in your office, or in your remote offices, where you have direct access to specific folders on the hard drive, and you can map them locally. You can actually run a back-up routine on their system – from their system -- that drops the data into one of our folders on our computers, just as if our computer were on their network.

Gardner: And why would I want an encrypted VPN to do that? Why couldn’t I just do that otherwise, or would my data be vulnerable if I didn’t have a VPN going?

Schiehl: The VPN sure makes it easier to do the job, just because you are able to map the drive as a local drive. The security is just an added benefit, but certainly if you did it outside of a VPN, your security would be compromised or could be easily compromised.

Gardner: What kind of prices do you charge for this? I know what I am paying for a guy that I physically bring my PC to when I have the issues, and that I do have sort of maintenance contract with them. As a small business owner, how much am I going to be out of pocket to get an ongoing maintenance relationship on this remote basis?

Schiehl: We price ourselves for our market, the small office, home-office market. We are not always the cheapest, but we have a lot of value on top of it. We have per-hour pricing that is $65 per hour, very reasonable for that market. We have fixed-price products such as our branded PC Oil Change, which is a complete system tune up, clean up, and virus scan, ensuring all your updates are in there. That’s a fixed price product at $100.

Gardner: So, that’s like a Jiffy Lube for my PC.

Schiehl: Well, that’s exactly what it is. The thing is that we draw off from different industries to create our own business models. We draw off from very successful businesses to create a same business model for the computer world.

Gardner: Yes, so you are doing psychotherapy and car-like computer maintenance. That’s pretty good.

Schiehl: That’s right.

Gardner: So, I get all this for $100 a year?

Schiehl: No, that’s for one of the particular PC Oil Changes. We recommend a couple of those a year. So, we have a fixed product package, called the one-year security guarantee that we offer at $225. For that we will install anti virus software, we will install anti-malware software, specifically Spyware Doctor.

Then we will monitor your system for one year and guarantee that no malware gets into it, no viruses get into it, plus we’ll do two of these cleanups per year. So, for one year you have peace of mind that if anything happens we are going to come in there, and fix it for free.

Gardner: And that means that I don’t have to go out and get my own anti-virus malware programs. You are going to include that software within that price?

Schiehl: That’s right.

Gardner: Wow. Well, I've got to tell you, that’s like half what I'm paying now and I'm paying for the software on top of that.

Schiehl: Right, and we are picking up what we feel is better software -- more compatible for the users' needs.

Gardner: Okay, so this is a no-brainer for me. And what's really enabling this is your ability to scale with this remote connectivity benefit?

Schiehl: That’s correct, because now we can leverage ourselves by being able to watch and monitor thousands of computers out there. One technician can simultaneously work on up to 10 people. Typically, four is my mental maximum, before I start falling apart, losing track. But the nice thing is when I'm working on someone’s computer, I can start a scan, which is going to take 30 minutes, and then I can work on an another session at the same time, do all the work leading up to the scan -- and then move on to another system, eventually going back to the first, and then second, and then third again.

Gardner: And because your customers can be in four continents, I'm going to guess that probably your "geeks" can be on four continents too, right?

Schiehl: That’s correct, however, we are building a model that’s not going to quite work that way. We won’t go too much into it because its right now it’s in the funding phase, the venture capital phase. But, nonetheless, we are looking more for a centralized model for sure.

Gardner: Let’s look at one of the big issues in the news right now that could have an impact on all of this, I guess both positive and negative. And that’s the arrival of Microsoft’s new operating system, Windows Vista, coming into the consumer base and the business base in 2007. Does Vista have tools built into it that changes your approach, and do you expect that the people transitioning to it or buying new PCs with Vista are going to actually give you more business?

Schiehl: We think that effect, the later effect, will be big, will be huge. But we feel that it will be slow at first, as the adoption takes place with Vista and the upgrade process. Bear in mind, yes, there are tools in there, but there are also tools in XP. There's the remote desktop feature or the remote support feature in XP, but both of these products -- and we have already tested the Vista one as well -- are absolutely inferior to the one from LogMeIn, the Rescue product, because the Rescue product is made specifically for technicians to do outsourced IT. So, it is filled with features that we won’t get on the other products.

Gardner: So, the features that are in Vista are designed probably more to let people access their home PC from a browser, but not designed for a maintenance and remediation function?

Schiehl: Right, or they allow access for your IT person within your office, with the lower level of security -- and not as feature-rich.

Gardner: I see. Their approach is to say, "Listen, we sell these to large enterprises and we want to help the IT desk in that enterprise be able to reach across the LAN and do some patch and other distribution types of functions."

Schiehl: Sure. One feature, for example, in the LogMeIn product, is System Information. As soon as we are connected, there is a tab on there for system information. Without having to ask the client, I know everything about their system, every driver in there, the processor, the RAM memory, the capacity of the hard drive used. I have an advanced view of all this information without actually having to ask the client. Those aren't in the built-in products in Windows XP or Windows Vista.

Gardner: Okay, so there are some elements here that are going to make your job easier. You are going to have a big churn in the marketplace, which is going to have people get a little bit confused and needing some help. And then you’ve got a better remote product and service than what's provided internally -- and you are doing that at a competitive price point.

Schiehl: Absolutely. Again our clients, our typical clients, are small-office, home-office users. They like things to look familiar, to feel familiar. So, there is going to be some huge hand-holding needed because Vista looks different, it feels a little different. So, in that aspect, yes, we feel there will be a huge opportunity in supporting these. But at the same time we feel it won’t be one great huge impact on release. It will be a slow roll-out.

Gardner: Very interesting. Well Keith, I think that about covers it. I’ve learned a lot more about this remote managed services business. I just wish there were some companies I could invest in. To be honest, it sounds like a very good growth industry. It’s been nice speaking with you.

We've been speaking with Keith Schiehl, president of Rent-A-Geek, about remote remediation and PC administration, and the use of LogMeIn products. And we also want to thank our sponsor, LogMeIn, for making this podcast possible. Keith, thanks for joining us.

Schiehl: Thank you, and thanks to LogMeIn for a creating a great product. We always feel thrilled when they come out with an update.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You’ve been listening to BriefingsDirect. Thanks very much.

For an instant trial of LogMeIn Rescue, the solution Rent-A-Geek relies on for its highly successful remote support business, visit www.LogMeInRescue.com/podcast. Within five minutes of signing up, you can conduct your first remote support session. And, through this special link, you’ll receive an automatic three-week trial (a full week longer than the standard trial). Get your trial going at www.LogMeInRescue.com/podcast.

Listen to the podcast here.

Podcast sponsor: LogMeIn, Inc.

Transcript of Dana Gardner’s BriefingsDirect podcast on PC remediation and remote access technologies. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.

Transcript of Dana Gardner's BriefingsDirect Podcast on Application Modernization

Edited transcript of BriefingsDirect[TM] podcast with Dana Gardner, recorded Aug. 21, 2006. Podcast sponsor: Hewlett-Packard.

Listen to the podcast here.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to a sponsored BriefingsDirect podcast. With us today are two executives from Hewlett-Packard (HP) to discuss application modernization. The idea is to deeply analyze an enterprise's applications and legacy code base to determine what could -- and just as importantly, should -- be redeployed on modern, agile platforms.

We are told that there are some 10,000 mainframes operating worldwide, consisting of some 200 billion lines of code. These are mostly on older systems. Today’s modern architecture allows for a great deal of lower-cost standardization and agility. How do we bring these two trends together? With us to discuss this are Rick Slade, the America’s practice principal for HP’s Application Modernization Service. Welcome to the show, Rick.

Rick Slade: Hi, Dana.

Gardner: Also, joining us is Paul Evans, the worldwide practice leader for application modernization for HP Services. Welcome to the show, Paul.

Paul Evans: Hi, Dana. Pleased to meet you.

Gardner: As I mentioned in our set up, we have a vast amount of mainframe applications worldwide. There is also a move now toward some finalization of architecture benefits around Services Oriented Architecture (SOA). There is a need for companies to become agile and fleet.

So I am wondering, are we just talking about mainframe applications, or is there a larger set of applications inventory involved? What is the addressable resource or asset library, if you will, for what we’re discussing around application modernization?

What’s the inventory here? Why don’t you try to take that, Rick?

Slade: Sure, Dana. Inventory, it’s a big subject. It certainly is a lot more than just mainframe applications. You talk about the big number of mainframe installations in the world today, and it is a big number. But there are also a lot of applications that many would consider legacy, that are running on more modern platforms or other platforms -- even on our own platforms from HP.

And so, what we’re looking to do is to help our customers transition or transform those applications to platforms and to software architectures that allow them to respond to change quicker, and hopefully cheaper. As far as an appropriate application ... for us it is any applications that constrains your business -- by not allowing you to move as you quickly as you’d like, due to competitive pressures or regulatory requirement changes.

Our goal is to look at these older applications built on more linear monolithic architectures, and transform those onto platforms and server architectures that promote flexibility. Architectures that actually let an organization achieve the "Adaptive Enterprise" vision that HP has been talking about for years.

Gardner: This is a scary proposition for a mainframe CIO, for someone who has been living in the mainframe world for a long time, and [where the systems have] been actually performing quite well and living up to expectations. I suppose the old adage, “If it’s not broken, don’t fix it,” plays into their thinking. What do you tell someone who seems to be in the mainframe environment and is satisfied with it?

Slade: That’s a great question, Dana. Let me say this, the mainframe is a stable platform, it’s a solid platform. The problem is, it’s a very expensive platform on which to deliver business services. The problem that organizations are having today are not so much from a stability standpoint, their problems are their inability to respond to change fast enough.

I read an article recently from Gartner, and their contention, based on research that they’ve done, is that 80 percent of an information technology (IT) budget is typically spent in maintenance -- in just maintaining their existing application stacks. Our objective would be to reduce that maintenance cost. If we can take that down by 20 percent for an organization, that’s a substantial amount of money. And then resources that can be applied to new value creation by the IT organization.

I think these modern architectures will allow our customers to ... respond [better] to these competitive pressures, as well as regulatory requirement changes -- certainly faster than they are today. We recently had an instance where a customer took their time-to-market, regarding adding new customers to a particular system, from nine months down to six weeks. That’s real business value that IT can now deliver back to the business due to use of these more modern application architectures.

Gardner: Now, we’ve seen a tremendous improvement in the functionality of hardware. We’ve seen a wide embrace of open standards and open source approaches. What are we talking about when we look at targets?

We’ll talk about a little bit later about the "how," but we’re still into the "why" to do application modernization. In order to understand the benefits of this change, this disruption, what is it that we are going to take these applications and their logic to? What are the typical targets these days for application platform modernization?

Evans: I’ll answer that one, Dana. I think the point is that there are several forces out there. And I think that Rick has hit on some of them. But in addition to that, this whole emergence of the SOA is making customers look at what they’ve got, and begin to ask themselves the question, "If we like some or all of the aspects of SOA, are we ready for it? Can we embrace it? Can we move toward it easily?"

So for most customers that have legacy applications ... running a stable but costly environment called the mainframe, this becomes quite a complicated task. What we’ve been trying to do is work with customers to begin to understand where the biggest bang for the buck is. Where should you go first in order to start gaining improved agility, lower cost, and the reduction of the maintenance cost of the software.

A lot of organizations spend upward of 70 percent of their IT budget just keeping what they’ve got going, just doing the routine adds, moves, and changes that keep those applications delivering to the business. But the challenge is that a lot of those applications are written in COBOL. For a lot of those applications, we’re seeing that the actual amount of COBOL written is still going up by 10 percent a year. That’s not because people are writing new applications, it’s because they’re just amending the old ones.

And many senior-level IT people understand this is a one-way street. We just have to turn around at some stage and begin to identify the sort of applications that would respond well to a modernization approach, and that may well take them toward this sort of infrastructure Nirvana, as it were, called SOA.

But sometimes it's difficult to understand, "Where do I start?" Do I start with a simplistic application that would have limited business impact? Or do I go to the other end of the scale and choose very complicated applications that run the business, which could be viewed as risky.

So, what we’ve been trying to do is go with an approach that allows us to identify where you should move first, to gain an accepted service level. But more importantly, we believe in taking the essential step of actually modernizing the software architecture.

Gardner: All right. So perhaps I was not thinking of it in quite the right way. It's not so much about where I'm going in terms of a definitive destination, but how can I actually take these assets and resources and put them on an architecture journey -- perhaps a lifecycle journey -- that might end up on a number of different targets over a period of time. Is that the end goal here?

Evans: It is very much so. I think most people in IT would state that the systems they have today have been relatively organic. There was never a master plan. Most mature, large companies have grown their IT resources over 20, 30, or 40 years. They have seen enormous change in technology during that time -- especially in the hardware platforms. The amount of power we can put into a system today has just grown beyond anybody’s wildest dreams.

So, once we’ve been able to harness that power -- to produce systems that are smaller, faster, cheaper, and develop less heat output -- we can effectively shrink datacenters. I think the IT industry has responded extremely well in harnessing that capability and delivering it to customers. Users have similarly utilized virtualization or consolidation. But we see a lot of customers today reducing their datacenter footprint because they can harness a lot more power in a much smaller space.

The days when mainframes were run by people with white coats behind locked doors are gone. The point is, we have seen enormous growth on the hardware side, and software technologies have grown up and matured, too. The real benefits, we believe, for customers to really exploit that power comes when you apply a similar amount of focus and attention to the software environment; just as you’ve done in the past to the hardware environment.

Rather than take an organic approach, I think customers and companies and organizations are striving for a master plan. It doesn’t have an end date, but it's like a journey. They know where they’re going. They want to develop a system architecture that allows them to make the decisions of what am I going to include going forward, and what am I not going to include. And that will help them make the decisions about choice and moving forward.

Slade: I'd like to make a point. I believe that architectural-targeting decisions are driven by business requirements. I think you said it properly earlier, in that we don’t have pre-defined targeting solutions. Our attempt, our goal, is to look at the business requirements and to help the customer determine what is the right platform -- what is the right application architecture -- on which to deliver that business service.

That doesn’t mean we don’t take into account existing corporate standards or existing corporate policies. Those things are important, and they feed into the decision-making equation. But again, the belief is to let business requirements dictate technology solutions, so that the organization can respond as cost-effectively and as quickly as possible.

Gardner: And just expanding on that point about business requirements, what is the business rationale typically? Is this strictly a dollars-and-cents thing? Is it a bit more qualitative than that? Obviously we want to cut down the ongoing operating costs. When it comes to bringing the chief financial officer (CFO) and the chief executive officer (CEO) in on this to get the funding -- to get the go-ahead -- what typically are the business rationales for embarking on application modernization?

Slade: Cost is always a part of the discussions, but it's not strictly the only element. In fact, most organizations that are talking to us today have a need to be more responsive to their business users.

I was talking to a chief operating officer (COO) not long ago, and he made it very clear to me about the potential cost reductions that he could have by modernizing his application stack. His response was, "That’s good, Rick, and that’s certainly something we need to talk about. But my problem is more about time than cost." And that’s an important point.

It takes IT organizations too long to respond to business-change requirements today. We, as IT professionals, have to determine how we can be more responsive to the business. Quite often the only way to do that is to change the software architecture, to use more modern architectures that allow us to make changes fast.

I think that is what this is all about. So cost certainly is an issue. I certainly believe that we can reduce the cost every time. I think that’s been proven time over time. But I think the big issue that is causing organizations to look at this today is through their inability to respond as fast as a business would like.

It’s been an age-old problem between the business users and the IT departments -- businesses always complain that IT can’t respond quickly enough. And the problem is that typically it takes so much time to do impact-analysis and impact-testing on these very monolithic and linear software applications. If we can reduce that time-of-maintenance, we can improve their time-to-market as an IT organization.

Gardner: Before we get into the "how," let’s probe a little bit into the "what" of application modernization.

It seems to me that we are going to have to look at identifying code, cleansing code, making logic extractible, looking at the data set and separating that out and allowing it to emerge into another environment. And then there’s presentation logic, and going from one type of user interface (UI) to other accepted standards. Can you give us a sense of what is required, what does the process boil down to? What do we have to do in order to extract and modernize some of these typical applications?

Evans: The first thing that we don’t do is look at code, because that just wouldn’t tell us anything. I think, as Rick said, it’s the alignment between IT and business that counts.

Today, any business manager will complain, "It takes IT too long to innovate or change anything." Business wants to innovate. Their idea of maintenance is that it’s sort of interesting, but not essential. What they are interested in is innovation: "I want to do something, I want to improve my business, and I expect IT to be right by my side."

In some instances, there is lag -- there is a significant lag -- from when innovation is sought and when it happens. It’s as Rick said, what we want to buy people is time. And what we want to do is synchronize to some degree where the business wants to be and where IT is. And in many instances that’s just not the same. Business asks for something, and then six, eight, 12 weeks -- whatever it is -- later there’s a response. And in some business managers’ minds, that’s not acceptable. So, the first thing we are trying to do is to align these two -- business and IT -- much better.

But in terms of responding to a modernization request, the first thing we have to do is to understand just what is in the applications portfolio. You would be surprised, there are a lot of large customers we work with who are more than happy to admit that they don’t actually know all of the applications they have, and what those applications do. Because they grow up organically, no one has kept track of all these things.

So the first thing we may have to do is to perform an inventory of the critical applications a customer has, and then determine how they constructed them. We perform an Applications Rationalization. And what we are looking at here is the intersect of the criticality of an application to the business, versus its technical quality. What we are looking for is applications that are critical to the business, but that their technical quality is below par, below standard, holding the company back.

A typical example would be a mainframe-based application running in COBOL, monolithic in nature, very difficult to make significant changes to, where the documentation may have been lost or may have been never been produced, in which maybe the original architect no longer works for the company. And therefore it becomes quite a challenge if you are going to make significant adds, moves, and changes to those applications.

We are looking initially for the applications that are critical, and yet the technical quality is not what the customer needs. There’s really no point spending time on an application that is well-written, well-documented, and is actually not in the mainstream. And that application could be running on a mainframe too. As Rick said, we are not going in there just to get things off the mainframe -- we are going in there to help a customer understand what is critical to their business, what we could improve for them, irrespective of the platform it is running on.

Gardner: Anything to offer on that, Rick?

Slade: I agree completely with Paul. The first thing to do is to identify where you have a problem. And then to attack it from a more technical perspective. We look at the application stack and categorize different components that make up that stack.

From our perspective, most applications are made up of three major categories or components. We have runtime, development, and management components. From a runtime standpoint, you’ve got source-code, you’ve got data, you’ve potentially got a third-party or utilities purchase. As Paul indicated, we have got to take inventory of all those components to understand what the mapping strategy will look like.

So before moving to a target environment ... we have to understand how are they maintaining those applications today, especially those custom applications. I think one of the problems in the industry today is not looking at those components. [We need to examine] the management components before making this type of move, transformation or modernization.

One of the things that we try to do is take a very holistic perspective of modernizing an application, by looking at what it's going to take to support and maintain all of the application. We want to understand what is being used today to manage a particular application, what are the tools that you going to use to monitor it in production, and to make sure that we have the same capabilities going to the new target environment. These are critical to being able to provide the reliability and the availability of the business customers’ needs and demands in their production application stacks.

Gardner: Now, this does not sound in anyway trivial. Not only are you talking about finding and auditing all of the applications, but weighing those applications in terms of their use -- and not just in terms of their quantitative use but also their qualitative value to the company. And not only now, but perhaps in the future.

So, this sounds pretty tricky. Is there a secret sauce? Is there a specific methodology? How do you go about searching for these applications and then rating them in such a way as to say, “Here are the sweet spots, here are the ones that are going to be important, here’s what’s going to bring business agility and reduced-time-to-market?" And, at the same time, then move these customers to platforms that will reduce the total cost of ownership.

What’s the secret sauce here?

Evans: We would look very silly in front of a customer if we said, "This was easy." Because he would say, "Well, if you think it’s easy, then you don't understand." So, the first thing: This is complicated.

That’s why customers turn to the outside of their own organizations, because they are then dealing with people who have done these things before. It’s like anything, you know. But in terms of what customers ask for, they are looking for a process. They are looking for methodologies. They are looking for experience. They are not looking to be the guinea pigs.

They are looking for organizations that have done it all before. But they also need a methodology that can be explained to them, and that makes them understand the steps in order to start extracting data. And also to understand the basis of how we are going to make a decision.

This is not just about coming in and saying, "You are running a mainframe in COBOL. You need get rid of it. We’ll do a rip-and-replace over the weekend. And by Monday morning, we are back online." That isn’t going to happen. Anybody who says that will be out of the door by any credible customer.

This is a process that we have to move quickly in order to demonstrate to the customer that there is money to be saved and money to be made. So, our whole approach is to get in and at least do an initial exploration that will define where are we going, and what we are going to do and not do. And then after that, we begin the deep-dive to look at the code. Then we can determine, “Hey, is this good code, is this bad code, is this dated code?” We can find out if the code hasn’t been used in years, whether it supports any form of business process, or whether it is just sitting there taking up space.

So, those are the things we have to demonstrate to a customer in order to give him confidence. Those are the things that help us with the application modernization decision-making process. Rick?

Slade: Oh, I absolutely agree. I think the key, Dana, in modernization efforts -- especially against these mission-critical production applications -- is a very systematic process. And we believe that we have put one together that is very robust. It's very disciplined. Quite honestly, a lot of engineering rigor is built into the system -- all for the purpose of mitigating risk.

Risk mitigation should be one of the key characteristics of modernization efforts. Again, we are talking about your production applications. Transitioning those, as Paul indicated, is a complex task. We believe we have built a rigorous approach based on our own experience. And we have implemented best practices from software engineering to our overall methodology to help us manage risk, and then to extrapolate the information we need to properly diagnose and determine what the targeting strategy should be.

The other key component in our solution -- and maybe a part of that secret sauce, as well -- is in the use of technology and tools to help us with the different phases of modernization and analysis. I think that to manually go through a lot of these systems is a complex, difficult, and expensive proposition. To do it manually is unacceptable.

So the use of the right technology is essential -- and we have spent a tremendous amount of resources, time, and money looking at this technology. We’ve developed in-house technology, as well as technology available in the market. And we are constantly looking at technologies to help us be more efficient in the analysis work that we do. Once that analysis step has been completed and a strategy developed in the proper use of technology, then we actually assist with the transformation process.

Again, it is not a simple exercise. It’s a very complex exercise. The use of technology allows us to minimize risk because we are working in an automated fashion, a consistent fashion. And I think that’s critical in transforming these applications. So, two major components that are key to our success: The proper use of process, and the proper use of technology -- both are needed to manage and mitigate risk.

Gardner: I would like to understand a little bit more about how you’ve applied this internally at HP. HP to me symbolizes a perfect organization for this sort of activity. You are decades old. You have gone through some massive mergers and acquisitions. There probably has been Digital mainframes, there’s a lot of HP UNIX platforms. You’ve been running a lot of systems. You are a global company.

How successful have you been at modernizing your own applications, and what have been some of the unanticipated consequences of going about this?

Evans: I think we would love to answer that with, "No, no, HP has never had this problem." [Laughter]

Unfortunately, you are absolutely right. I mean, mergers, acquisitions, etc. And therefore our internal IT folks are challenged just like everybody else’s. We may have a slight preference on supplier, but putting that to one side, the challenges faced in terms of an applications portfolio are no different than for any other organization.

So, we have seen significant gains. As I started off saying at the beginning of the chat, the situation is that we have seen significant gains when we have investigated our applications portfolio and then aligned that to the business need. This is especially true if you are in mergers and acquisitions -- and every major organization today is either been acquired or is being acquired.

And the point being is, it can lead to massive duplication. And like I said, if you’re going to be spending 70 percent of your IT budget to stay exactly where you are, you are not innovating. You’ve to go to look around and start to understand where the lower-hanging grapes are, to address application duplication, and determine which applications are absolutely critical.

And inside of HP, one of the first things we’ve done, is to really have the dialogue with the businesses, to ask, "What do you need? And more importantly, what do you not need?" And that’s very difficult, because everybody is obviously keen to start new projects and to develop new applications.

It’s amazing what we have found internally, that applications have been identified as being redundant and not supporting the current business processes. It's amazing. As soon as you claim that an application is redundant, then overnight it becomes strategically important. But you’ve got to get through that. You’ve got to understand the business processes that you are really looking for. And, of course, the challenges here are with the older applications, those business processes that are embedded in COBOL.

They are not exposed. They are business processes that are just mired away in millions of lines of code. And in the market today there are tools that can bring to the surface these business process. So you can say to a business unit manager, "Do you need this, really? Do you want us to spend 500,000 pounds, dollars, Euros, or whatever, per year in keeping this alive? Is it necessary for your business?"

The more of these processes that they agree are no longer required, the less money is spent on modernizing and maintenance, and the more that can be spent on real innovation. And that is where we have seen some really significant strides forward internally. There is this rationalization of the portfolio and by retiring applications in a well-managed and graceful way.

You are not walking in on a Friday night and turning it off. This is communicating to people that as of a certain day, an application is going to be shut down, and that you’ll be using a new application that is probably centralized and that works across a group of organizations rather than in a siloed one. And that process also puts in place a strategy that takes the old data and the application and archives it. For many of our customers, it’s a legal requirement for them to do that. They just can’t throw it all away.

Gardner: Okay, Rick, any unintended consequences in terms of what HP has discovered internally in going about application modernization?

Slade: The learnings are great, Dana, from a practical standpoint. I think that most people are aware of the huge datacenter consolidation network project that’s under way at HP. It’s been in the press. We in the consulting side do work with our IT organization. Quite honestly, our IT organization provides a lot of information back to the consulting organization. So it’s been a very nice environment. We have learned a tremendous amount in our own experience in the consolidation and modernization work that’s still in progress. But I think that we have also been able to share with our own IT organization some of the best processes that we have incorporated into our methodology. That allows them to move a little faster. It’s been a good marriage, and the work continues.

Gardner: Now, in trying to then put this into a larger context, application modernization isn’t happening within a vacuum. There are other larger trends afoot in a simultaneous fashion, which perhaps leads to the notion of, "A whole greater than the sum of the parts." I am thinking of virtualization, SOA, IT shared services, portfolio management, application life cycle management.

Are there other payoffs to application modernization? When we look at application modernization and we put it in the context of these other trends, is this a cog in the gear that grinds toward the fruition of some of these other productivity trends?

Slade: Well, absolutely. I was involved in meetings just recently about work occurring at HP and with their architecture and strategy groups in helping transform IT organizations. Application modernization simply becomes a component of that overall IT transformation. All of the initiatives that you talked about are things that companies are looking to do to help them deliver services better and more cost-effectively.

IT transformation is a major issue right now with HP. It's something that we are looking at and, in fact, are proving out. What we are doing now is to take those different services and roll them up under a common IT transformation umbrella framework. The possibilities are very exciting. The Adaptive Enterprise vision that HP came up with a few years back is an incredible vision. I think what we are seeing now is the realization of that vision -- how to achieve that vision -- and we are helping our customers with the services to actually make that vision a reality.

Gardner: Are there some larger competitive economic issues here? For example, let's say you are an established enterprise, you have been around for decades, you’ve gone through mergers, you’ve built out geography after geography. And now, perhaps, you’re going to be competing against a greenfield company that has just sprung up. Perhaps a Web 2.0-type of concern, built of outside services, using SOA. And they can be fleet. They can also be run inexpensively.

It seems to me that to compete with some of the newer companies that application modernization becomes a bit more critical. Is that overstating it?

Evans: No, I think this is where the "agility" word comes in. I think that’s why large companies, or parts of large companies, understand why this term "agility" has resonated so well. It's not a marketing buzz word -- it's what people want to be like.

When each of us gets out of bed in the morning, goes in the bathroom and looks in the mirror, we would like to look and see agile, nimble, you know, people that can respond to change extremely well. Organizations are no different. Things happened that they can’t predict.

As you say, new, very fleet-of-foot, greenfield company startups -- they have no legacy. They could move extremely quickly into markets, and large organizations have appreciated that. You know that painfully from the past. I now understand that if there is one attribute that IT systems need to be, it is agile. I want to do something in the morning that’s going to effect something in the afternoon. I do not want to be told when I want to do something in the morning that it is going to take six months. Because that’s just not acceptable.

Gardner: Well, I think that’s a good closing point. I want to thank you both very much for sharing your thoughts on application modernization.

We’ve been discussing this topic in a sponsored BriefingsDirect podcast with two executives from Hewlett-Packard: Rick Slade, the America’s practice principal for HP’s Application Modernization Services, and also Paul Evans, who runs the worldwide practice for application modernization for HP Services. Thank you both for joining in.

Slade & Evans: Thank you.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening.

Listen to the podcast here.

Podcast sponsor: Hewlett-Packard.

Transcript of Dana Gardner’s BriefingsDirect podcast on IT shared services. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.