Careful Advance Planning Averts Costly Snafus in Data Center Migration Projects

Transcript of a sponsored BriefingsDirect podcast on proper planning for data-center transformation and migration.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Today, we present a sponsored podcast discussion on the crucial migration phase when moving or modernizing data centers. So much planning and expensive effort goes into building new data centers or in conducting major improvements to existing ones, but too often there's short shrift in the actual "throwing of the switch" -- in the moving and migrating existing applications and data.

But, as new data center transformations pick up -- due to the financial pressures to boost overall IT efficiency -- so too should the early-and-often planning and thoughtful execution of the migration itself get proper attention. Therefore, our podcast at hand examines the best practices, risk mitigation tools, and requirements for conducting data center migrations properly, in ways that ensure successful overall data center improvement.

To help pave the way to making data center migrations come off nearly without a hitch, we're joined by three thought leaders from Hewlett-Packard (HP). Please join me in welcoming Peter Gilis, data center transformation architect for HP Technology Services. Welcome to the show, Peter.

Peter Gilis: Thank you. Hello, everyone.

Gardner: We're also joined by John Bennett, worldwide director, Data Center Transformation Solutions at HP. Welcome back, John.

John Bennett: Thank you very much, Dana. It's a delight to be here.

Gardner: Arnie McKinnis, worldwide product marketing manager for Data Center Modernization at HP Enterprise Services. Thanks for joining us, Arnie.

Arnie McKinnis: Thank you for including me, Dana. I appreciate it.

Gardner: John, tell me why migration, the process around the actual throwing of the switch -- and the planning that leads up to that -- are so essential nowadays?

New data centers

Bennett: Let's start by taking a look at why this has arisen as an issue. It makes the reasons almost self-evident. We see a great deal of activity in the marketplace right now of people designing and building new data centers. Of course for everyone who has successfully built their new data center, they have this wonderful new showcase site, and they have to move into it.

The reasons for this growth, the reasons for moving to other data centers, are fueled by a lot of different activities. Oftentimes, multiple factors come into play at the same organization.

In many cases it's related to growth. The organization and the business have been growing. The current facilities were inadequate for purpose, because of space or energy capacity reasons or because they were built 30 years ago, and so the organization decides that it has to either build a new data center or perhaps make use of a hosted data center. As a result, they are going to have to move into it.

It might be that they're engaged in a data-center strategy project as part of a data-center transformation, where they might have had too many data centers -- that was the case at Hewlett-Packard -- and consciously decided that they wanted to have fewer data centers built for the purposes of the organization. Once that strategy is put into place and executed, then, of course, they have to move into it.

We see in many cases that customers are looking at new data centers -- either ones they've built or are hosted and managed by others -- because of green strategy and green initiatives. They see that as a more cost-effective way for them to meet their green initiatives than to build their own data centers.

There are, of course, cost reductions. In many cases, people are investing in these types of activities on the premise that they will save substantial CAPEX and OPEX cost over time by having invested in new data centers or in data center moves.

Whether they're moving to a data center they own, moving to a data center owned and managed by someone else, or outsourcing their data center to a vendor like HP, in all cases you have to physically move the assets of the data center from one location to another.

The impact of doing that well is awfully high. If you don't do it well, you're going to impact the services provided by IT to the business. You're very likely, if you don't do it well, to impact your service level agreements (SLAs). And, should you have something really terrible happen, you may very well put your own job at risk.

So, the objective here is not only to take advantage of the new facilities or the new hosted site, but also to do so in a way that ensures the right continuity of business services. That ensures that service levels continue to be met, so that the business, the government, or the organization continues to operate without disruption, while this takes place. You might think of it, as our colleagues in Enterprise Services have put it, as changing the engine in the aircraft while it's flying.

Gardner: Peter, tell me, when is the right time to begin planning for this migration?

Migration is the last phase

Gilis: The planning starts, when you do a data-center transformation, and migration is actually the last phase of that data center transformation. The first thing that you do is a discovery, making sure that you know all about the current environment, not only the servers, the storage, and the network, but the applications and how they interact. Based on that, you decide how the new data center should look.

John, here is something where I do not completely agree with you. Most of the migrations today are not migration of the servers, the assets, but actually migration of the data. You start building a next-generation data center, most of the time with completely new assets that better fit what your company wants to achieve. This is not always possible, when your current environment is something like four or five years old, or sometimes even much older than that.

Gardner: Peter, how do you actually pull this off? How do you get that engine changed on the plane while keeping it flying? Obviously, most companies can't afford to go down for a week while this takes place.

Gilis: You should look at it in different ways. If you have a disaster strategy, then you have multiple days to recover. Actually, if you plan the disaster in a good fashion, then it will be easy to migrate.

On the other side, if you build your new engine, your new data center, and you have all the new equipment inside, the only thing that you need to do is migrate the data. There are a lot of techniques to migrate data online, or at least synchronize current data in the current data centers with the new data center.

Usually, what you find out is that you did not do a good enough job of assessing the current situation, whether that was the assessment of a hardware platform, server platform, or the assessment of a facility.

So, the moment you switch off the computer in the first data center, you can immediately switch it on in the new data center. It may not be changing the engines online, but at least near-online.

Gardner: Arnie, tell me about some past disasters that have given us insights into how this should go properly? Are there any stories that come to mind about how not to do this properly?

McKinnis: There are all sorts of stories around not doing it properly. In most cases, you start doing the decompose of what went wrong during a project. Usually, what you find out is that you did not do a good enough job of assessing the current situation, whether that was the assessment of a hardware platform, server platform, or the assessment of a facility.

It may even be as simple as looking at a changeover process that is currently in place seeing how that affects what is going to be the new changeover process. Potentially, there is some confusion. But it usually all goes back to not doing a proper assessment of the current mode of operations, or the current mode of that operating platform as it exists today.

Gardner: Now, Arnie, this must provide to you a unique opportunity -- as organizations are going to be moving from one data center to another -- to take a hard look at what they have got. I'm going to assume that not everything is going to go to the new data center.

Perhaps you're going to take an opportunity to sunset some apps, replace some with commodity services, or outsource others. So, this isn't just a one-directional migration. We're probably talking about a multi-headed dragon going in multiple directions. Is that the case?

Thinking it through

McKinnis: It's always the case. That's why, from Enterprise Services' standpoint, we look at it from who is going to manage it, if the client hasn't completely thought that out? In other words, potentially they haven't thought out the full future mode of what they want their operating environment to look like.

We're not necessarily talking about starting from a complete greenfield, but people have come to us in the past and said, "We want to outsource our data centers." Our next logical question is, "What do you mean by that?"

So, you start the dialog that goes down that path. And, on that path you may find out that what they really want to do is outsource to you, maybe not only their mission-critical applications, but also the backup and the disaster recovery of those applications.

When they first thought about it, maybe they didn't think through all of that. From an outsourcing perspective, companies don't always do 100 percent outsourcing of that data-center environment or that shared computing environment. It may be part of it. Part of it they keep in-house. Part of it they host with another service provider.

What becomes important is how to manage all the multiple moving parts and the multiple service providers that are going to be involved in that future mode of operation. It's accessing what we currently have, but it's also designing what that future mode needs to look like.

What becomes important is how to manage all the multiple moving parts and the multiple service providers that are going to be involved in that future mode of operation.

Gardner: Back to you, Peter. You mentioned the importance of data, and I imagine that when we go from traditional storage to new modes of storage, storage area networks (SANs) for example, we've got a lot of configuration and connection issues with how storage and data are used in conjunction with applications and processes. How do you manage that sort of connection and transformation of configuration issues?

Gilis: Well, there's not that much difference between local storage, SAN storage, or network attached storage (NAS) and what you designed. The only thing that you design or architect today is that basically every server or every single machine, virtual or physical, gets connected to a shared storage, and that shared storage should be replicated to a disaster recovery site.

That's basically the way you transfer the data from the current data centers to the new data centers, where you make sure that you build in disaster recovery capabilities from the moment you do the architecture of the new data center.

Gardner: Again, this must come back to a function of proper planning to do that well?

Know where you're going

Gilis: That's correct. If you don't do the planning, if you don't know where you're starting from and where you're going to, then it's like being on the ocean. Going in any direction will lead you anywhere, but it's probably not giving you the path to where you want to go. If you don't know where to go to, then don't start the journey.

Gardner: John Bennett, another tricky issue here is that when you transition from one organizational facility to another, or one sourcing set to another larger set, we're also dealing here with ownership trust. I guess that boils down to politics -- who controls what. We're not just managing technology, but we're managing people. How do we get a handle on that to make that move smoothly?

Bennett: Politics, in this case, is just the interaction and the interrelationship between the organizations and the enterprise. They're a fact of life. Of course, they would have already come into play, because getting approval to execute a project of this nature would almost of necessity involve senior executive reviews, if not board of director approval, especially if you're building your own data center.

But, the elements of trust come in, whether you're building a new data center or outsourcing, because people want to know that, after the event takes place, things will be better. "Better" can be defined as: a lot cheaper, better quality of service, and better meeting the needs of the organization.

This has to be addressed in the same way any other substantial effort is addressed -- in the personal relationships of the CIO and his or her senior staff with the other executives in the organization, and with a business case. You need measurement before and afterward in order to demonstrate success. Of course, good, if not flawless, execution of the data center strategy and transformation are in play here.

Be aware of where people view their ownership rights and make sure you are working hand-in-hand with them instead of stepping over them.

The ownership issue may be affected in other ways. In many organizations it's not unusual for individual business units to have ownership of individual assets in the data center. If modernization is at play in the data center strategy, there may be some hand-holding necessary to work with the business units in making that happen. This happens whether you are doing modernization and virtualization in the context of existing data centers or in a migration. By the way, it's not different.

Be aware of where people view their ownership rights and make sure you are working hand-in-hand with them instead of stepping over them. It's not rocket science, but it can be very painful sometimes.

Gardner: Again, it makes sense to be doing that early rather than later in the process.

Bennett: Oh, you have to do a lot of this before you even get approval to execute the project. By the time you get to the migration, if you don't have that in hand, people have to pray for it to go flawlessly.

Gardner: People don't like these sorts of surprises when it comes to their near and dear responsibilities?

Bennett: We can ask both Peter and Arnie to talk to this. Organizational engagement is very much a key part of our planning process in these activities.

Gardner: Arnie, tell us a little bit more about that process. The planning has to be inclusive, as we have discussed. We're talking about physical assets. We're talking about data, applications, organizational issues, people, and process. We haven’t talked about virtualization, but moving from physical to virtualized instances is also there. Give us a bit of a rundown of what HP brings to the table in trying to manage such a complex process.

It's an element of time

McKinnis: First of all, we have to realize that one of the things that happens in this whole process is that it's time. A client, at least when they start working with us from an outsourcing perspective, has come to the conclusion that they believe that a service provider can probably do it more efficiently and effectively and at a better price point than they can internally.

There are all sorts of decisions that go around that from a client perspective to get to that decision. In many cases, if you look at it from a technology standpoint, the point of decision is something around getting to an end of life on a platform or an application. Or, there is a new licensing cycle, either from a support standpoint or an operating system standpoint.

There is usually something that happens from a technology standpoint that says, "Hey look, we've got to make a big decision anyway. Do we want to invest going this way, that we have gone previously, or do we want to try a new direction?"

Once they make that decision, we look at outside providers. It can take anywhere from 12 to 18 months to go through the full cycle of working through all the proposals and all the due diligence to build that trust between the service provider and the client. Then, you get to the point, where you can actually make the decision of, "Yes, this is what we are going to do. This is the contract we are going to put in place." At that point, we start all the plans to get it done.

. . . There are times when deals just fall apart, sometimes in the middle, and they never even get to the contracting phase.

As you can see, it's not a trivial deal. We've seen some of these deals get half way through the process, and then the client decides, perhaps through personnel changes on the client side, or the service providers may decide that this isn't going quite the way that they feel it can be most successful. So, there are times when deals just fall apart, sometimes in the middle, and they never even get to the contracting phase.

There are lots of moving parts, and these things are usually very large. That's why, even though outsourcing contracts have changed, they are still large, are still multi-year, and there are still lots of moving parts.

When we look at the data center world, it just is one of those things where all of us take steps to make sure that we're always looking at the best case. We're always looking at what is the real case. We're always building toward what can happen and trying not to get too far ahead of ourselves.

This is little bit different than when you're just doing consulting and pure transformation and building that to the future environment. You can be a little bit more greenfield in your environment and the way you do things.

Gardner: I suppose the tendency is to get caught up in planning all about where you're ending up, your destination, and not focusing as much as you should on that all-important interim journey of getting there?

Keeping it together

McKinnis: From an outsourcing perspective, our organization takes it mostly from that state, probably more so than you could do in that future mode. For us, it's all about making sure that things do not fall apart while we are moving you forward. There are a lot of dual systems that get put in place. There are a lot of things that have to be kept running, while we are actually building that next environment.

Gilis: But, Arnie, that's exactly the same case when you don't do outsourcing. When you work with your client, and that's what it all comes down to, it should be a real partnership. If you don't work together, you will never do a good migration, whether it's outsourcing or non-outsourcing. At the end, the new data center must receive all of the assets or all of the data -- and it must work.

Most of the time, the people that know best how it used to work are the customers. If you don't work with and don't partner directly with the customer, then migration will be very, very difficult. Then, you'll hit the difficult parts that people know will fail, and if they don't inform you, you will have to solve the problem.

Gardner: Peter, as an architect, you must see that these customers you're dealing with are not all equal. There are going to be some in a position to do this better than others. I wonder whether there's something that they've done or put in place. Is it governance, change management, portfolio management, or configuration databases with a common repository of record? Are there certain things that help this naturally?

You have small migration and huge migrations. The best thing is to cut things into small projects that you can handle easily.

Gilis: As you said, there are different customers. You have small migration and huge migrations. The best thing is to cut things into small projects that you can handle easily. As we say, "Cut the elephant in pieces, because otherwise you can't swallow it."

Gardner: But, even the elephant itself might differ. How about you, John Bennett? Do you see some issues where there is some tendency toward some customers to have adopted certain practices, maybe ITIL, maybe service-oriented architecture (SOA), that make migration a bit smoother?

Bennett: There are many ways to approach this. Cutting up the elephant so you can eat it is a more interesting way of advising customers to build out their own roadmap of projects and activities, but, in the end, implement their own transformation.

In an ideal data center project, because it's such a significant effort, it's always very useful to take into consideration other modernization and technology initiatives, before and during, in order to make the migration effective.

For example, if you're going to do modernization of the infrastructure, have the new infrastructure housed in the new data center, and now you are just migrating data and applications instead of physical devices, then you have much better odds of it happening successfully.

Cleaning up internally

If you can do work with your applications or your business processes before you initiate the move, what you are doing is cleaning up the operations internally. Along the way, it's a discovery process, which Peter articulated as the very first step in the migration project. But, you're making the discovery process easier, because there are other activities you have to do.

Gardner: A lot of attention is being given to cloud computing at almost abstract level, but not too far-fetched. Taking advantage of cloud computing means being able to migrate a data center; large chunks of that elephant moving around. Is this something people are going to be doing more often?

Bennett: It's certainly a possibility. Adopting a cloud strategy for specific business services would let you take advantage of that, but in many of these environments today cloud isn't a practical solution yet for the broad diversity of business services they're providing.

We see that for many customers it's the move from dedicated islands of infrastructure, to a shared infrastructure model, a converged infrastructure, or an adaptive infrastructure. Those are significant steps forward with a great deal of value for them, even without getting all the way to cloud, but cloud is definitely on the horizon.

What we're moving toward, if done properly, is a breaking off, especially in the enterprise, of the security and compliance issues around data.

Gardner: Can we safely say, though, that we're seeing more frequent migrations and perhaps larger migrations?

McKinnis: In general, what we've seen is the hockey stick that's getting ready to happen with shared compute. I'll just throw it out there as what this stuff is in the data centers, kind of a shared-compute environment. What we're moving toward, if done properly, is a breaking off, especially in the enterprise, of the security and compliance issues around data.

There is this breaking off of what can be done, what should be done at the desktop or user level, what should be kept locally, and then what should be kept at a shared compute or a shared-services level.

Gardner: Perhaps we're moving toward an inflection point, where we're going to see a dramatic uptake in the need for doing migration activities?

McKinnis: I think we will. Cloud has put things back in people's heads around what can be put out there in that shared environment. I don't know that we've quite gotten through the process of whether it should be at a service provider location, my location, or within a very secure location at an outsourced environment.

Where to hold data

I don't think they've gotten to that at the enterprise level. But, they're not quite so convinced about giving users the ability to retain data and do that processing, have that application right there, held within that confinement of that laptop, or whatever it happens to be that they are interacting with. They're starting to see that it potentially should be held someplace else, so that the risk of that data isn't held at the local level. Do you understand where I am going with that?

Gardner: I do. I think we are seeing greater responsibility now being driven toward the data center, which is going to then force the re-architecting and the capacity issues, which will ultimately then require choices about sourcing, which will then of course require a variety of different migration activities.

McKinnis: Right. It's not just about a new server or a new application. Sometimes it's as much about, "How do I stay within compliance? Am I a public company or am I am a large government entity? How do I stay within my compliance and my regulations? How do I hold data? How do I have to process it?"

Even in the world of global service delivery, there are a lot of rules and regulations around where data can be stored. In that leveraged environment that a service provider provides, potentially storage is in somewhere in Eastern Europe, India, or in South America. There are plenty of compliance issues around where data can actually be held within certain governmental regulations, depending on where you are -- in country or out of country.

Planning is key -- not only planning the migration itself, but also doing "plan B" -- what if it doesn't work -- because then you have to go back to the old rule as soon as possible and within the time frame given.

Gardner: Let's move to Peter. Tell me a bit about some examples. Moving back to the migration itself, can you give us a sense of how this is done well, and if there are some metrics of success, when it is done well?

Gilis: As we already said in the beginning, it all depends on planning. Planning is key -- not only planning the migration itself, but also doing "plan B" -- what if it doesn't work -- because then you have to go back to the old rule as soon as possible and within the time frame given.

First, you need to plan, "Is my application suitable for a migration?" Sometimes, if you migrate your data centers from place A to place B -- as we've done in EMEA, from Czech Republic to Austria -- the distance of 350 kilometers gives an extra latency. If your programs, and we have tested them for the customer, already have performance problems, the little extra latency can just kill your program when you migrate.

One of the things we have done in that case is that we've tested it using a network simulator on a real-life machine. We found that the application was not adaptive, or the server was not adaptive for migration. If you know this beforehand, then you remove a risk by just migrating it on its own.

In another customer I saw that people had divided the whole migration process into multiple streams, but there was a lack of coordination between the streams. This means that if you have a shared application related to more than one stream, the planning of the one stream was totally in conflict with the planning of another stream. This means that the application and the data moved without informing the other streams, causing huge delays in real life, because the other applications were not synchronized anymore in the same way they used to be, assuming they were synchronized before.

So, if you don't plan and work together, you will definitely have failures.

Gardner: You mentioned something that was interesting about trying to do this on a test basis. I suppose that for that application development process, you'd want to have a test and dev and use some sort of a testbed, something that's up before you go into full production. Perhaps we also want to put some of these servers, data sets, and applications through some sort of a test to see if they are migration ready. Is that an important and essential part of this overall process?

Directly to the site

Gilis: If you can do it, it's excellent, but sometimes we still see in real life that not all customers have a complete test and dev environment, or not even an acceptance environment. Then, the only way to do it is to move the real-life machine directly to the new site.

I've actually seen it. It wasn't really a migration, but an upgrade of an SAP machine. Because of performance problems, the customer needed to migrate to a new, larger server. And, because of the pressure of the business, they didn't have time to move from test and dev, to acceptance, and to production. They started immediately with production.

At two o'clock in the morning we found that there was a bug in the new version and we had to roll back the whole migration and the whole upgrade. That's not the best time in the middle of the weekend.

Gardner: John Bennett, we've heard again and again today about how important it is to do this planning, to get it done upfront, and to get that cooperation as early as possible. So the big question for me now is how do you get started?

Bennett: How you get started depends on what your own capabilities and expertise are. If these are projects that you've undertaken before, there's no reason not to implement them in a similar manner. If they are not, it starts with the identification of the business services and the sequencing of how you want them to be moved into the new data center and provisioned over there.

We have successfully undertaken customer data center migration projects, which had minimal or zero operational disruption, by making clever use of short-term leases to ensure that business services continue to run, while they are transitioned to a new data center.

In order to plan that level of detail, you need to have, as Peter highlighted earlier, a really good understanding of everything you have. You need to fully build out a model of the assets you have, what they are doing, and what they are connected to, in order to figure out the right way to move them. You can do this manually, or you can make use of software like HP's Discovery and Dependency Mapping software.

If the size of this project is a little daunting to you, then of course the next step is to take advantage of someone like HP. We have Discovery Services, and, of course, we have a full suite of migration services available, with people trained and experienced in doing this to help customers move and migrate data centers, whether it's to their own or to an outsourced data center.

Peter talked about planning this with a disaster in mind to understand what downtime you can plan for. We have successfully undertaken customer data center migration projects, which had minimal or zero operational disruption, by making clever use of short-term leases to ensure that business services continue to run, while they are transitioned to a new data center. So, you can realize that too.

But, I'd also ask both Peter and Arnie here, who are much more experienced in this, to highlight the next level of detail. Just what goes into that effective planning, and how do you get started?

Gardner: I'd also like to hear that, Peter. In the future, I expect that, as always, new technologies will be developed to help on these complex issues. Looking forward, are there some hopeful signs that there is going to be a more automated way to undertake this?

Migration factory

Gilis: If you do a lot of migrations, and that's actually what most of the service companies like HP are doing, we know how to do migrations and how to treat some of the applications migrated as part of a "migration factory."

We actually built something like a migration factory, where teams are doing the same over and over all the time. So, if we have to move Oracle, we know exactly how to do this. If we have to move SAP, we know exactly how to do this.

That's like building a car in a factory. It's the same thing day in and day out, everyday. That's why customers are coming to service providers. Whether you go to an outsourcing or non-outsourcing, you should use a service provider that builds new data centers, transforms data centers, and does migration of data centers nearly every day.

Gardner: I'm afraid we're just about out of time and we're going to have to leave it there. I want to thank our guests for an insightful set of discussion points around data center migration.

As we said earlier, major setups and changes with data-center facilities often involve a lot of planning and expense, but sometimes not quite enough planning goes into the migration itself. Here to help us better understand and look towards better solutions around data center migration, we have been joined by Peter Gilis, data center transformation architect for HP Technology Services. Thanks so much, Peter.

Gilis: Thank you.

Gardner: Also John Bennett, worldwide director, Data Center Transformation Solutions at HP. Thanks, John.

Bennett: You're most welcome, Dana.

Gardner: And lastly, Arnie McKinnis, worldwide product marketing manager for Data Center Modernization in HP Enterprise Services. Thanks for your input, Arnie.

McKinnis: Thank you, Dana. I've enjoyed being included here.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect podcast. Thanks for listening and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.

Transcript of a sponsored BriefingsDirect podcast on proper planning for data-center transformation and migration. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

Executive Interview: HP's Robin Purohit on How CIOs Can Contain IT Costs While Spurring Innovation Payoffs

Transcript of a BriefingsDirect podcast with HP's Robin Purohit on the challenges that CIOs face in the current economic downturn and how to prepare their businesses for recovery.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Today, we present a sponsored podcast executive interview that focuses on implementing the best methods for higher cost optimization in IT spending. [See HP news from Software Universe on cloud enablement technologies.]

To better define the challenges facing CIOs today, and to delve into what can help them properly react, we are here with Robin Purohit, Vice President and General Manager for HP Software and Solutions. Welcome back to BriefingsDirect, Robin.

Robin Purohit: Wonderful to be here again with you, Dana.

Gardner: Clearly, the cost-containment conundrum of "do more for less" -- that is, while still supporting all of your business requirements -- is going to be with us for quite some time. I wonder, Robin, how are CIOs reacting to this crisis, now that we're more than a full year into it?

Purohit: Well, just about every CIO I've talked to right now is in the middle of planning their next year’s budget. Actually, it's probably better to say preparing for the negotiation for next year’s budget. There are a couple of things.

The good news is that this budget cycle doesn’t look like last year’s. Last year’s was very tough, because the financial collapse really was a surprise to many companies, and it required people to very quickly constrain their capital spend, their OPEX spend, and just turn the taps off pretty quickly.

We saw a lot of CIOs getting surprised toward the end of year 2009 and the beginning of year 2010, and just having to stop things, even things that they knew were critical to their organization’s success, and critical to their business success.

So, the good news is that we're not in that situation anymore, but it's still going to be tough. What we hear from CIO Magazine is that about two-thirds of the companies out there plan to either have flat or down IT budgets for next year. A small amount are trying to actually increase spend.

Every CIO needs to be extremely prepared to defend their spend on what they are doing and to make sure they have a great operational cost structure that compares to the best in their industry.

They need to be able to prepare to make a few big bets, because the reality is that the smartest companies out there are using this downturn as an advantage to make some forward looking strategic bets. If you don't do that now, the chances are that, two years from now, your company could be in a pretty bad position.

Gardner: Given that we are either flat or refining still and that this might last right through 2010, it means we have to look at capital spending. I think probably a lot of costs are locked in or have been already dealt with. When it comes to this issue of capital spending, how are these budgets being managed?

Important things

Purohit: Well, with capital spend, there are a couple of pretty important things to get done. The first is to have an extremely good view of the capital you have and where it is in the capital cycle.

You need to know what can be extended in terms of its life, what can be reused and what has to be refreshed? Then, when you do refresh it, there are some great new ways of actually using capital on server storage and networking that's at a much lower cost structure, and much easier to operate, than the systems we had three or four years ago.

Quite frankly, we see a lot of organizations still struggling to know what they have, who is using it, what they are using it for, and where it is in the capital life cycle. Getting all of that information that is timely, accurate, and at your fingertips, so you can enter the planning cycle, is extraordinarily important and fundamental.

Gardner: It certainly seems that the capital spending you do decide on should be of a transformational nature. Is that fair?

Purohit: Yes, it's true. I should have said that. Capital, as we all know is not only the hardware, but software. A lot of our customers are taking a hard look at the software licenses they have to make sure they are being used in the best possible way.

"Today's innovation is tomorrow’s operating cost."

Now, the capital budget that you can secure needs to be used in very strategic ways. We usually advise customers to look in two buckets.

One, when you are going to deploy new capital, always make sure that it's going to be able to be maintained and sustained in the lowest-cost way. The way we phrase this is, "Today's innovation is tomorrow’s operating cost."

In the past, we’ve seen mistakes made, where people deployed new capital without really thinking how they were going to drive the long-term cost structure down in operating that new capital. So that's the first thing.

The second is, the company wants to see the CIO use capital to support the most important business initiatives they have, and usually they are associated with revenue growth, by expanding the sales force, and new business units, some competitive program, or eventually a new ecommerce presence.

New business agenda

It's imperative that the CIO shows as much as possible that they're applying capital to things that clearly align with driving one of those new business agendas that's going to help the company over the next three years.

They are clearly in bucket that either dramatically lowers the ongoing cost structure of new technologies, or clearly rides the capital spend with something that a line of business executive is trying to do over the next two or three years. They have the best chance of getting what they think is really necessary.

Gardner: It seems that in order to know whether your spend is transformational, you need to gain that financial transparency, have a better sense of the true cost and true inventory, and move toward the transformational benefits. But, then you also need to be able to measure them, and I think we are all very much return-on-investment (ROI) minded these days. How do we reach that ability to govern and measure once we put things into place?

Purohit: It's a great point. The reality is the CIO has been a bit of a cobbler’s child for some time. They've done a great job putting in systems and applications that support the business, so that a sales executive or a business unit executive has all of the business process automation and all of the business information at their fingertips in real-time to go, and to be competitive and be aggressive in the marketplace.

It's imperative that the CIO shows as much as possible that they're applying capital to things that clearly align with driving one of those new business agendas that's going to help the company over the next three years.

CIOs traditionally have not had that same kind of application. While they can go through a manual and pretty brutal process to collect all this information, they haven’t had that real-time financial information, not only in what they have or plan to do, but to track, on an almost weekly basis, their spend versus plan.

I guess, all the CFO cares about is whether you are on track on your financial variance, and if you aren’t on track, what are you doing to real-time optimize to the changing realities of the budget that are adjusting monthly these days for most CIOs.

This is where we really see an opportunity. They help customers put in place IT financial management solutions, which are not just planning tools -- not just understanding what you have -- but essentially a real-time financial analytic application that is timely and accurate as an enterprise resource planning (ERP) system, or a business intelligence (BI) system that's supporting the company’s business process.

Gardner: If we have a ratio in many organizations where we have 70 percent roughly for maintenance and support and 30 percent for innovation, we're going to need to take from Peter to pay Paul here.

What is it that you can do on that previously "untouchable" portion of the budget? How can we free up capacity in the data-center, rather than build a new data center, for example?

It's a cyclical thing

Purohit: The joke I like to tell about the 70:30 ratio is that, unfortunately, we've been talking about that same ratio for about 10 years. So, somebody is not doing something right. But, the realty is that it's a cyclical thing. Today’s innovation is tomorrow's maintenance.

It's important to realize that there are cycles where you want to move the needle and there are cycles where you can't. Right now, we are in a cycle where every CIO needs to be moving that 70:30 to 30:70. That's because, first of all, they'll be under cost pressure. I really believe that the leaders of tomorrow in the business world are going to be created during the downturn. That's historically what we’ve seen. McKinsey has some good write-ups about that.

It means that you need to be driving as much innovation as possible and getting to that 70 percent. Now, in terms of how you do that, it's making sure that the capital spend that you have, that everything in the data center you have, is supporting a top business priority. It's the most important thing you can do.

One thing that won't change is that demand from the business will all of a sudden strip your supply of capital and labor. What you can do is make sure that every person you have, every piece of equipment you have, every decision you are making, is in the context of something that is supporting an immediate business need or a key element of business operation.

When we work with a lot of customers, we help them do that assessment, and I'll give you one example. A utility company I worked with was able to identify up to $37 million of operational and capital cost savings in the first couple of years just by limiting stuff that wasn't critical to the business.

It also means there are more things and more new things to manage.

There are lots of opportunities to be disciplined in assessing your organization, both in how you spend capital, how you use your capital, and what your people are working on. I wouldn't call it waste, but I would call it just a better discipline and whether what you're doing truly is business critical or not.

Gardner: I suppose having that financial visibility and transparency that allows that triage to take place, and then moving towards this flip of 70:30 ratio, we have to involve people and process and not just technology, right?

Purohit: That's right. If you don't get the people and process right, then new technologies, like virtualization or blade systems, are just going to cause more headaches downstream, because those things are fantastic ways of saving capital today. Those are the latest and greatest technologies. Four or five years ago, it was Linux and Windows Server.

It also means there are more things and more new things to manage. If you don't have extremely disciplined processes that are automated, and if you don't have all of your team with one play book on what those processes are, and making sure that there is a collaborative way for them to work on those processes, and which is as automated as possible, your operating costs are just going to increase as you embrace the new technologies that lower your capital. You've got to do both at the same time.

Gardner: Now, HP Software Solutions has been describing this as operational advantage, and that certainly sounds like you're taking into consideration all the people and process, as well as the technology. Tell me a little more about what you’ve been doing in the past several months and how this will impact the market in 2010.

Best in class

Purohit: We talk about operational advantage, we talk first of all about getting close to a best-in-class benchmark of your IT costs as a percentage of your company’s revenue.

They say close to best, because you never want to race to the bottom and be the lowest-cost provider, if you want to be strategic. But, you'd better be close. Otherwise, your CFO is going to be breathing down your neck with lots of management consultants asking why you are not there.

The way you get there is through a couple of key steps that we have been recommending. First and foremost, you have to standardize and automate as much as you can.

The great news is that, right now, there is really sophisticated technology that we have. Many companies have to apply this to this problem, where you can take a lot of the stuff that you know how to do every day and that involves a lot of people, and eventually a lot of manual work that could be done incorrectly, if you are not careful.

Standardize and automate them to make sure they get done in a very efficient way, in the cheapest possible way, and in the same way every time. We've seen customers take $10 million of operating cost out in 6 to 9 months just by automating what they know to do and what they know they need to do repeatably every time.

We’ve done a ton of work to roll out and automate those best practices, and how to get the advantages of faster innovation using Agile development, without creating a bunch of risks as you move faster.

The second thing that we really work on with people is getting that financial visibility, and getting all of their financial information on labor, projects, capital, and plans in one place, with one data model, so that they have a coherent way to plan and optimize their spends.

Those two things are huge levers. The third thing that we've really started to work with people on is all of these innovation projects, which are really brand new innovative techniques, like Agile development?

How do you make that labor tool extremely effective using that new technique like Agile development? We’ve done a ton of work to roll out and automate those best practices, and how to get the advantages of faster innovation using Agile development, without creating a bunch of risks as you move faster. Those are three really fundamental elements of what we're doing right now.

Gardner: I suppose that when you are picking on something quite as complex as this, you need to have some goal and some vision and direction about what are the realistic goals for some of these cost optimization activities. You mentioned the percent of revenue for IT spend as one gauge. What sort of results do you think people can meaningfully and realistically get in terms of some of these larger metrics?

Important goal

Purohit: We've seen the best companies actually implement this swap from 30:70 to 70:30. So, getting to 30 percent of your spend on operating costs in this cycle, where you need to be investing for the future, is absolutely an achievable and important goal. The second thing is to make sure that you’re benchmarking yourself on this cost of IT versus revenue on the most important competitors in your industry.

The reason that I phrased it that way is that it's not a general benchmark and it's not just the lowest-cost provider in your geography or industry, but you want to know what your most important competitor is doing, using technology as an advantage for both cost structure and innovation.

You want to understand that, spending probably something similar to that, and then hopefully be smarter than them in how you implement that strategy. Those are two really important things.

The third thing is that, depending where your IT organizational maturity is, there are opportunities to take out as much as 5 to 10 percent of your operating cost just by being more disciplined.

Say that you're a new CIO coming to organization and you see a lack of standardization, a lack of centers of excellence, and a lot of growth through merger and acquisition, there is a ton of opportunity to take out operating cost.

We've seen customers generally take out 5 to 10 percent, when a new CIO comes on board, rationalizes everything that's being done, and introduces rigorous standardization. That's a quick win, but it's really there for companies that have been probably a little earlier in the maturity cycle of how they run IT.

The same thing is happening now that happened in 2001, when we had our last major downturn. In 2001, we saw a rise of outsourcing and off-shoring, particularly to places like India.

Gardner: Another way of reducing this percentage of total revenue, I have to imagine, from all the interest in cloud computing these days, comes from examining and leveraging, when appropriate, a variety of different new sourcing options, both, new and old. How does that relate to this cost optimization equation?

Purohit: That's a great point. The same thing is happening now that happened in 2001, when we had our last major downturn. In 2001, we saw a rise of outsourcing and offshoring, particularly to places like India.

That really helped companies to lower their cost structure of their labor dramatically and really assess whether they needed to be doing some of these things in-house. So, that clearly remains as an option. In fact, most companies have figured out how to do that already. Everybody has a global organization that moves the right labor to the right cost structure.

A couple of new things that are possible now with the outsourcing model and the cloud model -- whether you want to call it cloud or software as a service (SaaS) -- is that there's an incredibly rich marketplace of boutique service shops and boutique technology providers that can provide you either knowledge or technology services on-demand for a particular part of your IT organization.

That could be a particular application or a business process. It could be a particular pool of knowledge in running your desktop environment. There's really an incredible range of options out there.

Questions for the CIO

What every CIO needs to be doing is standing back and saying, "What do we really need to be the best at, and where is critical intellectual property that we have to own?" If you're not running at the best possible cost structure for that particular application or business process or you're not operating this infrastructure at the best possible cost structure, then why don't we give it to somebody else who can do a better job?

The cost structures associated with running infrastructure as a service (IaaS) are so dramatically lower and are very compelling, so if you can find a trusted provider for that, cloud computing allows you to move at least markets that are lower risk to experiment with those kind of new techniques.

The other nice thing we like about cloud computing is that there is at least a perception that is going to be pretty nimble, which means that you'll be able to move services in and out of your firewall, depending on where the need is, or how much demand you have.

It will give you a little bit of agility to respond to the changing needs of the business without having to go through a long capital-procurement cycle. The only thing I would say about cloud is be cautious, because it's still early, and we're seeing a lot of experimentation.

The most important thing is to pick cloud providers that you can trust, and make sure that your line of business people and people in your organization, when they do experiment, are still putting in the right governance approach to make sure that what's going out there is something that doesn’t introduce extra risk to your business.

There’s a lot of diligence that needs to be put in place, so that cloud becomes less an experiment and more a critical element of how you can address this cost-structure issue.

Trust your provider, if you are putting data out there in the cloud. Do you trust how that data is being handled? If that cloud infrastructure is part of a business critical service, how are you measuring it to make sure that it's actually supporting the performance availability security needs of what the business needs?

There’s a lot of diligence that needs to be put in place, so that cloud becomes less an experiment and more a critical element of how you can address this cost-structure issue.

Gardner: Now, when we talk about cost structure, I would think that's even more critical for these cloud providers in order for them to pass along the savings. They themselves must put into place many of the things we have talked about today.

Purohit: That's right. Cloud providers have to push the needle right to the edge in order to compete. They're using the best possible new technology around blade computing, virtualization, automating everything, new service oriented architecture (SOA) technologies, so that you can do small component applications and stitch them together super fast.

The right governance

That's the value that they're providing. Then, the challenge is that you've got to make sure that not only do they have the great innovation, and great cost structure, but you trust what they are doing and that they have the right governance around it. I think that's really going to be what separates the lowest-cost cloud providers from the ones that you want to bet your business on.

Gardner: Is there anything else you want to offer in terms of thinking about cost optimization and how to get through the next year or two, where we are flipping ratios but are also maintaining lower total cost?

Purohit: I want to go back to this innovation bucket, because, as I said, you don't want to come out of this cycle as a CIO who was associated only with lowering cost and didn't fundamentally move the needle out, making the business more competitive.

You have limited ability to make those bets. So, the best bets are ones that are very prevalent, very top of mind for the business executives who really change the dynamic in terms of competitiveness, sales productivity, or the way they engage their customers.

The most consistent project that we have seen, the kind of project we see out there that are good bets for those innovation dollars, is around a theme you call application modernization.

The most consistent project that we have seen, the kind of project we see out there that are good bets for those innovation dollars, is around a theme you call application modernization.

What's happening right now in the industry is what we believe is the biggest revolution in application technology of the enterprise in probably 10 years. That's a composite of things that you build applications with these new Agile development methods.

All of these rich Internet protocols are revolutionizing the way you visualize and interact with applications, crossing over from the consumer world into the enterprise world. A whole, new wave of application platform technology is being introduced by SAP, Oracle, and Microsoft. And, SOA is becoming very real, so that you can actually integrate these applications very quickly.

Our view is that the companies who use this opportunity to modernize their applications and have this rich interactive visual experience, where they can nimbly integrate various application components to innovate and to interact with their customers or their sales people better, are the ones that are going to emerge from this downturn as the most successful leveraging technology to win in the marketplace.

We really encourage customers to take a very hard look at application modernization, and are helping them get there with those scarce innovation dollars that they have.

Gardner: Very good. We've been discussing the need for implementing best methods and achieving higher cost optimization by looking at reverse ratios from maintenance and support to innovation and transformation. Helping us along our journey in our discussion, we've been joined by Robin Purohit, the General Manager and Vice President for HP Software Solutions. Thanks so much, Robin.

Purohit: Thanks, Dana.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to a sponsored BriefingsDirect Podcast. Thanks for listening, and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.

Transcript of a BriefingsDirect podcast with HP's Robin Purohit on the challenges that CIOs face in the current economic downturn and how to prepare their businesses for recovery. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

You may also be interested in:

• In 'Everything as a Service' Era, Quality of Services and Processes Grows Paramount, Says HP's Purohit
  
  
• Application Transformation Case Study Targets Enterprise Bottom Line with Eye-Popping ROI
  
  
• Caught Between Peak and Valley -- How CIOs Can Survive Today, While Positioning for Tomorrow

BriefingsDirect Analysts Unpack the Psychology of Project Management Via 'Pragmatic Enterprise 2.0' and SOA

Edited transcript of BriefingDirect Analyst Insights Edition podcast, Vol. 47 on new tools for measuring and building trust in technology adoption.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.

Dana Gardner: Hello, and welcome to the latest BriefingsDirect Analyst Insights Edition, Volume 47. I'm your host and moderator Dana Gardner, principal analyst at Interarbor Solutions.

This periodic discussion and dissection of IT infrastructure related news and events -- with a panel of industry analysts and guests -- comes to you with the help of our charter sponsor, Active Endpoints, maker of the ActiveVOS visual orchestration system, and through the support of TIBCO Software.

Our topic this week on BriefingsDirect Analyst Insights Edition, and it is the week of Nov. 9, 2009, centers on how to define, track and influence how people adapt to and adopt technology.

Any new information technology might be the best thing since sliced bread, but if people don’t understand the value or how to access it properly -- or if adoption is spotty, or held up by sub-groups, agendas, or politics -- then the value proposition is left in the dust.

A crucial element for avoiding and overcoming social and user dissonance with technology adoption is to know what you are up against, in detail. Yet, data and inferences on how people really feel about technology is often missing, incomplete, or inaccurate.

Today, we're going to hear from two partners who are working to solve this issue pragmatically. First, with regard to Enterprise 2.0 technologies and approaches. And, if my hunch is right, it could very well apply to service-oriented architecture (SOA) adoption as well.

I suppose you can think of this as a pragmatic approach to developing business intelligence (BI) values for people’s perceptions and their ongoing habits as they adopt technology in a business context.

So join fellow ZDNet bloggers, Michael Krigsman, president and CEO of Asuret, as well as Dion Hinchcliffe, founder and chief technology officer at Hinchcliffe & Co. as they explain how Pragmatic Enterprise 2.0 works. Together with our panel, we can plumb whether this could help with SOA adoption -- and maybe even other types of technology- or creative pursuit-adoptions as well.

Before we delve into this and hear more about Pragmatic Enterprise 2.0, please allow me to introduce our panel this week. We're joined by Joe McKendrick, prolific blogger and analyst. Welcome to the show, Joe.

Joe McKendrick: Thanks, Dana. Pleased to be here, and hello to everybody.

Gardner: We’re also joined by Miko Matsumura, vice president and chief strategist at Software AG. Welcome, Miko.

Miko Matsumura: Great. Good to be here.

Gardner: Ron Schmelzer, managing partner at ZapThink. Welcome back, Ron.

Ron Schmelzer: Hola. Bienvenido.

Gardner: Tony Baer, senior analyst at Ovum. Hi, Tony.

Tony Baer: Hey, Dana. Hi, everybody. Good to be here.

Gardner: We're also joined by Sandy Rogers, independent industry analyst. Welcome, Sandy.

Sandy Rogers: Great, Dana. Glad to be here.

Gardner: And, last but not the least, Jim Kobielus, senior analyst at Forrester Research. Welcome, Jim.

Kobielus: Selamat petang. There, I matched Ron Schmelzer in gratuitously using a foreign language to welcome everybody.

Gardner: Okay, let's hand this off to Dion Hinchcliffe. Tell me, Dion, about how you thought that you needed more pragmatism when it came to bringing Enterprise 2.0 technologies into practice, how you found Michael Krigsman, and how you two hooked up on this?

Social software

Dion Hinchcliffe: Absolutely, Dana, thanks for having us on the show. It's a real honor to be in front of such an august audience. As many of you know, we've been spending a lot of time over the last few years talking about how things like Web 2.0 and social software are moving beyond just what’s happening in the consumer space, and are beginning to really impact the way that we run our businesses.

More and more organizations are using social software, whether this is consumer tools or specific enterprise-class tools, to change the way they work. At my organization, we've been working with large companies for a number of years trying to help them get there.

This is the classic technology problem. Technology improves and gets better exponentially, but we, as organizations and as people, improve incrementally. So, there is a growing gap between what’s possible and what the technology can do, and what we are ready to do as organizations.

I've been helping organizations improve their businesses with things like Enterprise 2.0, which is social collaboration, using these tools, but with an enterprise twist. There are things like security, and other important business issues that are being addressed.

Businesses are about collaboration, team work, and people working together . . .

But, I never had a way of dealing with the whole picture. We find that that folks need a deep introduction to what the implications are when you have globally visible persistent collaboration using these very social models and the implications of the business.

We see organizations like the public sector getting more into this. Government 2.0 is one of the hottest topics. Increasingly, as these things become reality in large organizations, people are worried about what kind of control they're giving up and what kind of risk they're incurring?

Michael, of course, is famous for his work in IT project risk -- what it takes for projects to succeed and what causes them not to succeed. I saw this as the last leg of the stool for a complete way of delivering these very new, very foreign models, yet highly relevant models, to the way that organizations run their business.

Businesses are about collaboration, team work, and people working together, but we have used things like email, and models that people trust a lot more than these new tools.

Understanding projects

I've been working on big IT projects most of my life. I've been a solo architect and also focused on people in the enterprise. What Michael brings to the table is all his experience in terms of understanding. But, it requires understanding what’s really taking place inside projects where, one, the technology is not necessarily well-understood by the organization and, two, the implications on the business side are not well-understood.

There is usually a lot of confusion and uncertainty about what’s really taking place and what the expectations are. And Michael, with Asuret, brings something to the table. When we package it as a service that essentially brings these new capabilities, these new technologies and approaches, it manages the uncertainty about what the expectations are and what people are doing.

What we have designed is not specific to Enterprise 2.0 at all. It's really for when you are bringing in any new transformative technology with the same set of issues. I want Michael to speak more about what he is doing and how his side works.

Gardner: Sure. Michael, tell us a little bit about Asuret, and how your process works, maybe specifically with Enterprise 2.0, but with technology generally?

Michael Krigsman: Think about business transformation projects -- any type. This can be any major IT project, or any other type of business project as well. What goes wrong? If we are talking about IT, it's very tempting to say that the technology somehow screws up. If you have a major IT failure, a project is late, the project is over budget, or the project doesn’t meet expectations or plan, it's extremely easy to point the finger at the software vendor and say, "Well, the software screwed up."

If we look a little bit deeper, we often find the underlying drivers of the project that is not achieving its results. The underlying drivers tend to be things like mismatched expectations between different groups or organizations.

For example, the IT organization has a particular set of goals, objectives, restrictions, and so forth, through which they view the project. The line of business, on the other hand, has its own set of business objectives. Very often, even the language between these two groups is simply not the same.

As another example, we might say that the customer has a particular set of objectives and the systems integrator has its own objectives for the particular project. The customer wants to get it done as fast and as inexpensively as possible. The systems integrator is often -- and I shouldn’t make generalizations, but -- interested in maximizing their own revenue.

If we look inside each of these groups, we find that inside the groups you have divisions as well, and these are the expectation mismatches that Dion was referring to.

If we look at IT projects or any type of business transformation project, what’s the common denominator? It's the human element. The difficulty is how you measure, examine, and pull out of a project these expectations around the table. Different groups have different key performance indicators (KPIs), different measures of success, and so forth, which create these various expectations.

Amplifying weak signals

How do you pull that out, detect it inside the project, and then amplify what we might call these weak signals? The information is there. The information exists among the participants in the project. How do you then amplify that information, package it, and present it in a way that it can be shared among the various decision-makers, so that they have a more systematic set of inputs for making decisions consistently based on data, rather than anecdote? That’s the common thread.

Gardner: Michael, what you're doing here is providing this as a service, right? People don’t have to install this. They don’t have to do it themselves. You're offering a web interface-based approach to gathering inference from different players within this project, portfolio, what have you, implementation adoption pattern, sussing out what those folks are feeling, and then bringing that in a visual way to the attention of the project leaders. Is that right?

Krigsman: Yes. We offer a service. We're not selling software. We offer a service, and the service provides certain results. However, we've developed software, tools, methods, techniques, and processes that enable us to go through this process behind the scenes very efficiently and very rapidly.

Gardner: I had a chance to look at a demo of this. I haven’t tried it myself. I can’t vouch for it and I am not endorsing it, but what struck me as interesting is the fact that we're actually approaching the right part of the problem, when it comes to adoption.

Let's go to Sandy Rogers. Now, you headed up the SOA practice at IDC not too long ago. We kept encountering, in some of the discussions I had with you, this issue about why the projects stumble from time-to-time. What’s the hold up? It almost always came back to these people issues, and yet we had very little at our fingertips to apply to it. Does this sound like something that is a start for going in the right direction. Do you have any takeaways?

Rogers: What we discovered in our studies is that one of the fundamental needs in running any type of business project -- an SOA project or an Enterprise 2.0 IT project -- is the ability to share information and expose that visibility to all parties at levels that will resonate with what matters to them the most, but also bring them outside of their own domain to understand where dependencies exist and how one individual or one system can impact another.

One of the keys, however, is understanding that the measurements and the information need to get past system-level elements. If you design your services around what business elements are there and what matters to the business, then you can get past that IT-oriented view in bringing business stakeholders in aligned management and business goals to what transpires in the project.

Any way that you can get out -- web-based, easy-access dashboard with information -- and measure that regularly, you can allow that to proliferate through the organization. Having that awareness can help build trust, and that’s critical for these projects.

Gardner: Ron Schmelzer, we had a roundtable discussion in Boston several months ago, looking at the SOA topic and whether it was dead or not. I think some of the feelings from the panelists there were that it's not dead, but that it needs to be done better and differently. Is this what we're describing here with Michael and Dion? It sounds like it's moving in the right direction toward that balance of people, process, and technology.

More than technology

Schmelzer: Certainly, a lot of what people are doing with SOA is really just trying to do the things that people have established with enterprise architecture (EA). As we all know EA isn't about technology and buying things. It's about applying things and it's about people and process, much more than it’s about technology. That’s the hope.

The last thing you want to be doing is constantly scrambling and redoing your architecture because somebody somewhere in the organization has introduced some new technology. The wonderful paradise that we're trying to achieve is the stability of architecture, even though everything else is changing, the process is changing, and the technology is changing.

Given that, one of the things that we realized pretty early in this coverage of SOA, maybe about a decade ago, is that companies really need to manage their people, their governance, and their organization much more than they need to worry about buying the right tools.

As a matter of fact, you can buy the wrong tools, have great processes, and still have great outcomes. But if you buy the best tools, whatever that means, and you've got poor processes, you are guaranteed to have poor outcomes.

. . . It's mostly up to people and process to make sure the whole thing functions in a way that's returning value to the business.

It's like buying a pair of pants and putting them on. We have a complex system with a lot of moving parts, with a lot of interactions that are visible and hidden, and it's mostly up to people and process to make sure the whole thing functions in a way that's returning value to the business.

Gardner: Joe McKendrick, you’ve been covering SOA for some time, as a blogger on ebizQ and ZDNet. Often times, these topics around politics, fiefdoms, misunderstandings, and allowing people to communicate well come up again and again. Like the weather, we keep talking about it, but no one does anything about it.

It sounds as if Michael and Dion are trying to do something about it, at least for Enterprise 2.0. How does this strike you as to getting inside in data, into perceptions, and then being able to work with that? Is it a significant part of the problem and solution?

All about organization

McKendrick: Michael and Dion, I think you're on the right track with that. In fact, it's all about organization. It's all about the way IT is organized within the company and, vice-versa, the way the company organizes the IT department. I’ll quote Mike Hammer, the consultant, not the detective, "Automate a mess and you get an automated mess." That's what's been happening with SOA.

Upper management either doesn't understand SOA or, if they do, it's bits and pieces -- do this, do that. They read Enterprise Magazine. The governance is haphazard, islands across the organization, tribal. Miko talks about this a lot in his talks about the tribal aspect. They have these silos and different interest groups conflicting.

There's a real issue with the way the whole process is managed. One thing I always say is that the organizations that seem to be getting SOA right, as Michael and Dion probably see with the Enterprise 2.0 world, are usually the companies that are pretty progressive. They have a pretty good management structure and they're able to push a lot of innovations through the organization.

The companies that really could use these processes, the companies that really could use a good dose of service orientation, are the companies that just don't get it. It's a paradox.

Gardner: Miko Matsumura, as a supplier of software and services at Software AG, are you all looking for people like Dion and Michael to come up with these ways in which those tribal elements can be addressed? Is this something that intrigues you?

Matsumura: Absolutely. I had a wonderful conversation with Michael earlier and I appreciate his invite to come join this conversation. This type of an approach really reflects the evolution of the best practice of adoption. Some of the themes that we've been talking about today around this sharing of information, communication, and collaboration, are really are essential for success.

I do want to caution just a little bit. People talk about complexity and they create a linkage between complexity and failure. It's more important to try to look at, first of all, the source of the problem. Complexity itself is not necessarily indicative of a problem. Sure, it's correlated, but ice-cream consumption is correlated with the murder rate, just as a function of when temperatures get hot, both things happen to increase. So complexity is also a measure of success and scale.

I’d like to point to a different culprit, which I call "entropy" or "waste," and look at waste as being either over-complexity -- or over-simplicity in some cases. Over-simplicity can be as much of a villain as over-complexity. To me one of the biggest sources of complexity is tribalism and people fighting each other.

Providing a really transparent flow of measurements and metrics is obviously a tremendously important step. We have a methodology that we call the performance-driven organization that uses KPIs to increase organizational alignment. But, really, what you're doing is just shifting the fight. You're basically saying, "Let's not fight about one set of things. Let's fight about a set of so-called objective KPIs."

All about trust

The issue it comes down to for me is what Sandy said, which is that the word "trust," which is thrown in at the very end, turns out as extremely expensive. That alignment of organization and trust is actually a really important notion.

What happens with trust is that you can put things behind a service interface. Everything that's behind a service interface has suddenly gotten a lot less complex, because you're not looking at all that stuff. So, the reduction of complexity into manageability is completely dependent on this concept of trust and building it.

Gardner: The interesting thing you mentioned here is the metrics and the data. Having some kind of objective or constant way of evaluating what's going on and how that's changing over time, whether it's positive or negative, and then how to adapt, creates some sort of a positive feedback process loop.

Jim Kobielus, you deal with data analysis all the time. Tell me your impressions about bringing a data-analysis capability to how people react to something like implementing and adopting and adapting to Enterprise 2.0 or SOA.

Kobielus: A dashboard is so important when you are driving a vehicle, and that's what a consolidated view of KPIs and metrics provides. They are a dashboard in the BI sense, and that's what this is, project intelligence dashboard for very complex project or mega programs that are linked projects. In other words, SOA in all of its manifestations.

In organization, you have to steer your enterprise in a different direction. You need obviously to bring together many projects and many teams across many business domains. They all need to have a common view of the company as a whole -- its operations, various stakeholders, their needs, and the responsibilities internally on various projects of various people. That's highly complex. So, it’s critical to have a dashboard that's not just a one-way conduit of metrics, from the various projects and systems.

In the BI world, which I cover, most of the vendors now are going like crazy to implement more collaboration and work-flow and more social community-style computing capabilities into their environments. It's not just critical to have everybody on the same page in terms of KPIs, but to have a sideband of communication and coordination to make sure that the organization is continuing to manage collectively according to KPIs and objectives that they all ostensibly agree upon.

This is important. Social computing must come to the very heart of dashboarding to enable collaborative SOA project governance.

Gardner: But perhaps not just social from the gut, but social with some science, metrics, and real data.

Kobielus: Exactly. It has to be real data that's grounded in project objectives and in current status and delivering on those objectives.

Gardner: Tony Baer, what are we missing here? Is there some part of this equation that we're glossing over? Is there any cold water we should be pouring on here, just to be safe?

Recipe for tribalism


Baer: Oh, you read my mind on this one. I can quote from a project that my wife is currently involved with, which is basically a whole recipe for what you're talking about.

What Dion and Michael are talking about is an excellent idea in terms of that, in any type of environment where there is a lack of communication and trust, data is essential to really steer things. Data, and also assurances with risk management and protection of IT and all that. But, the fact is that there are some real clear hurdles, especially when you have what Miko talks about with tribes.

An example is this project that my wife is working on at the moment. She was brought in as a consultant to a consulting firm that's working for the client, and each of them have very different interests. This is actually in a healthcare-related situation. They're trying to do some sort of compliance effort, and whoever was the fount of wisdom there postponed the most complex part of this problem to the very end. At the very end, they basically did a Hail Mary pass bringing a few more bodies.

They didn't look for domain expertise or anything. Essentially it's like having eight women be pregnant and having them give birth to a baby in a month. That's essentially the push they are doing.

On top of that, there is also a fear among each tribe of the other coming up with a solution that makes the other tribes look bad. So, I can't tell exactly the feedback from this, but I do know that my wife came in as a process expert. She had a pretty clear view on how to untie the bottlenecks.

As soon as the project leader learned that she had this expertise, she was excluded from this, because this consulting firm was very afraid that her knowledge would make their firm look bad to the customer. In this case, they would rather risk complete failure of the project than have the firm be upstaged by someone who had been brought late in the process.

That pattern that you described there is essentially a factor about distribution of individual risk versus enterprise risk. The enterprise becomes a dumping ground for individual risk and it creates this kind of very large aggregate risk.

This is just an example of social and tribal challenges that you face. I very much agree that having a data-oriented approach and a risk management approach won't necessarily solve the problem. But, in case like this, that might be the only way out, provide cold, hard data from some neutral third-party.

Matsumura: I just want to jump in quickly and, first of all, applaud Tony Baer, the carrier of the cold water. That pattern that you described there is essentially a factor about distribution of individual risk versus enterprise risk. The enterprise becomes a dumping ground for individual risk and it creates this kind of very large aggregate risk.

Gardner: Let's take that point to Michael Krigsman. Michael, in what you're doing, are you allowing risk to be assigned? Are you be able to identify risk factors across different groups of people involved in a fairly large project? Is that part of what's going on here?

Essential elements

Krigsman: We gather a lot of data. The essential elements have been identified during this conversation. As Miko said, it's absolutely accurate to look at this tribally. Tony spoke about tribal divisions and the social tribal challenges.

The fundamental trick is how to convert this kind of trust information. Jim was talking about collaborative project governance. All of this relates to the fact that you've got various groups of people. They have their own issues, their own KPIs, and so forth. How do you service issues that could impact trust and then convert that to a form that can then be examined dispassionately. I'd love to use the word "objectively," but we all know that being objective is a goal and it's never outcome that you can ultimately reach.

At least you have a way to systematically and consistently have metrics that you can compare. And then, as Miko said, when you want to have a fight, at least you are fighting about KPIs, and you don't have people sitting in a conference room saying, "Well, my group thinks this. We believe the project 'blank.' If somebody says the same, my group thinks that." Well, let's have some common data that's collected across the various information silos and groups that we can then share and look at dispassionately.

Gardner: So, we want to get some objectivity about perception. It almost sounds like an oxymoron, but actually I think it's quite essential. Let's go back to Dion Hinchcliffe. Dion, you announced your Pragmatic Enterprise 2.0 initiative just a week or two ago. There is quite a bit of information about it on your website at Hinchcliffe & Co. Tell me a little bit about what the results are. When you bring this to bear, are they tangible results? Is there data about how well your data-driven process works?

Hinchcliffe: The way the process works is that we come into a client with an end-to-end service. Most organizations -- and this is going to be true of Enterprise 2.0 or SOA -- are looking at solving a problem. There's some reason why they think that this is going to help, but they're often not sure.

There are often a lot of unstated assumptions about how to apply technology to a business problem and what the outcome is going to be.

We start with this strategy piece that looks at the opportunity and tries to identify that for them and helps them correct the business case to understand what the return on investment (ROI) is going to be. To do that, you really have to understand what the needs of the organization are. So, one of the first things we do is bring Michael's process in, and we try and get ground truths.

There are often a lot of unstated assumptions about how to apply technology to a business problem and what the outcome is going to be. Particularly with SOA, you have so many borders that are typically involved. It's the whole concept around Conway's Law that the architecture tends to look back at the structure of the organization, because those are the boundaries in which everything runs.

One of the ways that we can assure that we have ground truth is by applying this dispassionate measurement process upfront to understand what people's expectations are, what their needs are, and what their concerns are. It's much more than just a risk-management approach. It's a way to get strategic project intelligence in a way that hasn't been possible before. We're really excited about it.

A lot of uncertainty

My specialty has always been focusing on emerging technology. There is always a lot of uncertainty, because people don't know necessarily what it is. They don't know what to expect. They have to have a way of understanding what that is, and you have an array of issues including the fact there are people who aren't willing to normally admit that they don't know things.

But, here is a way to safely and succinctly, on a regular basis, surface those issues and deal with them before they begin to have issues in the project. We then continue on through implementation and then regular assessments on the KPIs that can cause potential issues down the road. I think it's a valuable service. It's low impact, compared to another traditional interview process. This is something most organizations can afford to do on a regular basis.

Gardner: I'd like to go around our panel and get some more reaction to this.
Ron Schmelzer, the idea of this strategic project management caught my attention when Dion mentioned it. We've had lots of software products thrown at project management and portfolio management. Those don't seem to work. What's the difference between the project and portfolio management approach to some of these issues -- and what Michael Krigsman and Dion Hinchcliffe are doing with this more social inference gathering and measurement approach.

Schmelzer: I'm glad that you brought up the difference between project and portfolio management. This may be something unique in our perspective, or maybe it's becoming common. It's hard to tell when you talk to yourself a lot. We think that the whole idea of project management is just an increasing fallacy in IT anyway. There is no such thing now. It's really a discrete project.

Can you really say that some enterprise software that you maybe buying or building yourself or maybe even sourcing as a service is really completely disconnected from all the other projects that you have going on or the other technology? The answer is, they are not.

The enterprise is a collection of many different IT projects, some of which are ongoing, some of which may have been perceived to be dead or no longer in development, or maybe some are in the future.

So, it's very hard to do something like discrete project management, where you have defined set of requirements and a defined timeline and defined budget, and make the assumption or the premise, which is false, that you're not going to be impacting any of the other concurrently running projects.

We think of this like a game of pick-up sticks. The enterprise is a collection of many different IT projects, some of which are ongoing, some of which may have been perceived to be dead or no longer in development, or maybe some are in the future. The idea that you could take any one of those little projects, and manipulate them without impacting the rest of the pile is clearly becoming false.

In portfolio management you're basically managing a variety of ongoing concurrent tasks that either have budget or don't have budget and you're trying to achieve some sort of change with the least form of destruction within the business requirements and the money and the resources you have.

That's very different from this whole idea of, "Let's put together a Gantt chart. Let's throw a bunch of resources at it. Let's have some defined requirements. Let's build to it. Let's hope and pray that we're right." The industry, as a whole, is moving away from this idea of discrete IT project management.

Gardner: Joe McKendrick, thinking about discrete as something in the rear-view mirror, that means that we need to factor in cloud computing and software as a service (SaaS). They were not just going to have internal constituencies that need to be monitored and brought to some sort of a level set for understanding. We're going to have external influences, be they hosting organizations or applications that are being delivered and pulled across the wire.

How do you view the complexity of a project or portfolio management or enablement, when we're starting to bring in more and more parties to the process?

IT no longer internally focused

McKendrick: Dion, I'm an avid fan of your writings and, in particular, your ideas around web-oriented architecture (WOA), the next evolution of SOA, Enterprise 2.0, and those forces converging. I love the way you express it.

Dana is exactly right. IT is no longer an internally-focused effort. There are a lot of external factors at play. In the first stage, you have a lot of external business partners you need to expose interfaces to and you need to share information with. Right there, that dramatically increases the complexity of what you need to do.

Down the road, as you talk about cloud, you're talking about the sharing of services across enterprise borders. Everyone is going to be a producer, a publisher, or a creator of services, as well as consumers of services. It's going to be a two-way street.

There is a lot of discussion about cloud computing and the way these services will be consumed from the cloud. I don't think enough people are thinking about the services they will be producing and offering up to the cloud for others to consume. I'd be curious. Dion and Michael, do you address that in your model, in your web-based offering?

Hinchcliffe: Right now, we're going to validate some Enterprise 2.0 markets, looking at potential things as how they process. Then, of course, we'll be expanding particularly on next-generation SOA maturity. Enterprise 2.0 is getting very big right now, so that's our focus at the moment.

It needs to be much more federated, and a lot of companies, when they first took on SOA, tried to control things from a central unit.

Gardner: Sandy Rogers, another thought that I've had about this is how important governance, policy, and automation are in making SOA successful. If we have more inference information, a dashboard if you will, about the social landscape, about the buy-in or lack of buy-in from different participants in a adoption and/or execution phase of this sort of thing, can we take some of that information and then use it in the context of governance, policies, and management that are more traditional software-based SOA functions and features?

Rogers: One of the keys here is that it's a constant feedback loop of what you can automatically provide in what you are measuring and assessing, and then be able to look at that and change whether something should be standardized and should be collected.

It becomes this incremental cycle of building out that information. One of the keys that everyone is talking about here is this needs to be much more distributed. It needs to be much more federated, and a lot of companies, when they first took on SOA, tried to control things from a central unit.

When you start expanding SOA into the enterprise, especially with Enterprise 2.0, the idea of changing behaviors is something that has to start. This information that's distributed could help individuals gain knowledge and then be able to change their own behaviors.

Everyone realizes that people need to understand current state, before they can actually get to that next state, and then eventually to that ideal state. They also need to feel comfortable that in this federated approach. They may not want to share everything right-away, but incrementally contribute to the whole, and make it much more of a community.

Analysis benefit

Gardner: Michael Krigsman, we were using words like feelings and behavior. Is it fair to say that you're bringing some sort of an analysis benefit to an IT project or adoption pattern? Are we getting closer to a psychological participation project?

Krigsman: I am so hesitant to use the term psychological, because it has so many connotations associated with it. But, the fact is that we spoke about perception earlier, and there has been a lot of discussion of trust and community and collaboration. All of these issues fundamentally relate to how people work together. These are the drivers of success, and especially the drivers of lack of success on projects of every kind.

It therefore follows that, if we want our projects to be governed well and to succeed, one way or another we have to touch and look at these issues. That’s precisely what we're doing with Asuret and it’s precisely the application that we have taken with Dion into Pragmatic Enterprise 2.0. You have to deal with these issues.

Gardner: Jim Kobielus, this kind of reminds me of Star Trek: The Next Generation where there was this counselor. Deanna Troi was on the bridge with all the technicians, the leaders, drivers at warp speed, and the executive decision-makers. Is that what we need in IT, a virtual counselor along the way with us?

Kobielus: Virtual counselor? Hmm. I’ll answer that by tossing another metaphor. It really seems like the enterprise is becoming a cloud of stakeholders and interested parties that coalesces based on various needs and then scatters in the way that clouds tend to do.

The way open-source projects coalesce, certain people are first among equals, and they are the committers who defend, the general scope of common hopes and dreams.

The common denominator for getting things done in this new world is that responsibility needs to somehow precipitate out of the cloud and that certain individuals or teams take it upon themselves to get certain things done at certain times, because they recognize that things, results, need to happen.

So, virtual counselor ... I like that concept. The virtual counselor in this federated, distributed, or social-SOA governance environment. A virtual counselor is simply that person who takes command of or masters a set of channels or media -- Twitter, Facebook, blogging, and whatever else you have out there -- to be able to share all the KPIs and metrics to get others to wheedle them or cajole them to taking their responsibilities and their domains to get things done.

That person or persons will make sure there's one particular work stream within this broader project or program. This one person makes sure that certain things happen at certain times, and then gracefully, when necessary, hands off that virtual counselor post to others who pick up the baton. I'm extending metaphors here.

That’s absolutely what has to happen in a world of shifting alliances, shifting responsibilities, and shifting budgets across domains. It's like the open-source world. The way open-source projects coalesce, certain people are first among equals, and they are the committers who defend, the general scope of common hopes and dreams.

Gardner: Miko Matsumura, do you agree with my perception that this is a big step forward? In the context of a IT project or roll out, they're thinking about people’s feelings and behaviors and perceptions. It strikes me as a big step forward. Isn’t this long overdue?

Objectivity and rationality

Matsumura: About two months ago, I tweeted, "Enterprise does not need architecture. Enterprise needs psychiatrists." It does sort of preface some of this discussion. The reason I made such a point is that, the word "architecture" unfortunately implies this kind of objectivity and rationality that I, to some extent, resist when I hear words like data, rationality, objectivity, whatever.

The reason I rail against it is that the system aggregate in enterprise has in it a vicious cycle. It's not passively complex. It's not static complexity.

Ron was talking about the generation of the project management paradigm, the huge Gantt chart. Those huge Gantt charts are indicative of static complexity, and static complexity is actually not the paradigm. What Sandy was saying that I really appreciated is this notion of iteration, which is really critical.

When you get these “objective KPIs” to align organization, the next thing that happens is that organizations gain the hell out of KPIs, especially if you tie them to job review, performance evaluation, and, God forbid, bonuses.

You're going to ask people who are going to spend 40 hours a week, drilling away at ways to gain the KPIs to advantage themselves and maximize their own personal game, and it's not to say actively perverse, but essentially "to hell with everyone else."

. . . KPIs are well and good, but as soon as you institutionalize them, be ready to change them, because you will have unexpected outcomes.

The nature of the beast is such that when you encounter this kind of scenario, it's not merely this notion of lack of information or confusion. This is active perversity on an organizational and individual level. The point I'd make is that KPIs are well and good, but as soon as you institutionalize them, be ready to change them, because you will have unexpected outcomes.

Gardner: Tony Baer, last word to you. An important aspect of what Michael Krigsman and Dion are doing is that this can be anonymitized. The ability to draw inference, feelings, and perceptions from people can be done in a way that they feel empowered, that they can share their feelings without it becoming a political football or a hot potato perhaps by being anonymous. But, what you get is the insight into what the thinking is, the feelings are, the perceptions across the portfolio of participants in a project.

Does that strike you as an important factor? I want to ask you also about this counselor or analyst’s features. Do we need to bring a purple dinosaur into each SOA activity -- "I love you, you love me, let's talk about our feelings?" How do we stop being silly, but still get the benefit of this sharing going on?

Baer: I agree with you that basically that trust is really important. And, when I say trust here, it's trust in feeling that I can give information without it being used against me. No project can function in an atmosphere where everybody is just presenting basically what management wants. That eventually becomes an emperor’s new clothes situation. So obviously, I think that’s really essential.

All become counselors

I am a little cynical about the idea of a counselor, per se. I'm very much a fan of internalizing, so we all become counselors. I really like Sandy’s ideas of distributed governance, where Jim was talking about making this data-driven. I see this becoming a self-learning governance, because you can govern from the top based on assumptions that you make at the outset of a project that are totally oblivious to the conditions on the ground.

Therefore, you have to set this up so that you need to have an atmosphere of trust, where we can contribute information without fingers being pointed, and therefore names being given.

At the same time, we can then use this information to adapt. As Miko was saying, be prepared to change those KPIs, if those KPIs are not relevant. We should not be measuring to last week’s objectives, if, all of a sudden, the world has changed. So the short answer is, I agree that the anonymization is essential. I am leery about the idea of a counselor, but I am very much a very believer in everybody taking responsibility in this, and we all become counselors.

Gardner: Very good. I am afraid we’ll have to leave it there. I encourage folks to check this out. It really opened my thinking about how to make these projects more successful. It's a new dimension that I think needs to be brought in increasingly across a variety of different activities, and that would be at a business level, technology level, or a combination.

There is a lot more information available at the Hinchcliffe & Co., as well as Asuret, and of course. You can also find a lot more at the ZDNet blog that Michael Krigsman has been doing for several years now, the Project Failures blog.

I want to thank everyone for joining. We’ve been here with Dion Hinchcliffe, founder and chief technology officer at Hinchcliffe & Co. We’ve also been joined by Michael Krigsman, president and CEO of Asuret.

Please also join me in thanking our panel, Joe McKendrick, a prolific blogger and IT analyst. Thank you, Joe.

McKendrick: Thanks, Dana. Glad to be here.

Gardner: Miko Matsumura, vice president and chief strategist at Software AG. Thanks, Miko.

Matsumura: Thank you very much.

Gardner: Ron Schmelzer, managing partner at ZapThink.

Schmelzer: Muchas gracias.

Gardner: Tony Baer, senior analyst at Ovum.

Baer: Great, as always, Dana.

Gardner: Sandy Rogers, independent industry analyst. Thanks, Sandy.

Rogers: Thank you.

Gardner: Jim Kobielus, senior analyst at Forrester Research.

Kobielus: Great. I will sign off in a deep dose of alliterative English. I think it was a deep dose of domain expertise from SOA specialists.

Gardner: And I also want to thank the sponsors for the BriefingsDirect Analyst Insights Edition podcast series, Active Endpoints and TIBCO Software.

This is Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to BriefingsDirect. Thanks, and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.

Edited transcript of BriefingDirect Analyst Insights Edition podcast, Vol. 47 on new tools for measuring and building trust in technology adoption. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

You may also be interested in:

• BriefingsDirect Analysts Discuss Business Commerce Clouds: Wave of the Future or Old Wine in a New Bottle?
• Linthicum's Latest Book: How SOA and Cloud Intersect for Enterprise Productivity Benefits
• Panel Discussion: Is Cloud Computing More or Less Secure than On-Premises IT?