Executive Interview: Workday’s Aneel Bhusri on Advancement of SaaS and Cloud Models for Improved ERP

Transcript of a sponsored BriefingsDirect podcast with Workday’s co-CEO on the future of delivering HR and ERP solutions as cloud services to large enterprises.

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

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 with a software-as-a-service (SaaS) provider upstart, Workday.

This human capital management (HCM), financial management, payroll, worker spend management, and workday benefits network provider is raising the bar on employee life-cycle productivity, by lowering IT support costs through the SaaS model. More than that, Workday is also demonstrating what I consider a roadmap to the future advantages in cloud computing.

We are here with Workday’s co-founder and co-CEO, Aneel Bhusri, who is responsible for the company’s overall strategy and day-to-day operations. Welcome to BriefingsDirect, Aneel.

Aneel Bhusri: Thank you.

Gardner: Workday has come an awfully long way in a fairly brief amount of time, since your launching in November of 2006 -- that's less than three years. Workday also attracted a significant additional round of venture capital support earlier this year. I believe it was $75 million, Level E.

Aneel, what explains this quick level of adoption on your user side, and then also this vigorous support from investors?

Bhusri: The adoption from the user side, I think, is very straightforward. SaaS is just a better way for these legacy systems around HR, payroll, and accounting. Our customers typically achieve benefits within a four- to six-month time period and they are typically saving 50 percent of their cost.

If you look around the world and you see the move toward cloud computing, it's for a reason. It's a better way than the legacy, on-premise technology.

As to the funding, I would hope that, number one, it's a big market opportunity that we are pursuing. We're not looking at a niche. We're looking to replace the full enterprise resource planning (ERP) platform over time, much like we did at PeopleSoft.

The pedigree of the team starts with my co-founder, Dave Duffield. He's an icon in the software industry. He's known for high integrity, innovation, and customer service. Many of us, like me, have been with him for 17 years now and we share that vision and that culture with him. We have set out to build the next great software company. I think people have recognized that.

Dave has mostly self-funded the company. We took this last round of funding as a validation of what we were doing. The best part of the validation is that the new investor, NEA, did reference calls with our customers. They said that those were the best reference calls to the customers that they have done in the last 10 years.

Gardner: You mentioned PeopleSoft, and, of course, that was acquired by Oracle. What was it about that PeopleSoft experience for you that helped shape the vision that you are now putting together for Workday?

Employees first

Bhusri: We're very similar to PeopleSoft in some areas, and in other areas, quite different. We have the same culture -- focused on employees first and customers second. We focus on integrity. We focus on innovation. We brought that same culture to Workday, and our customers are very happy.

We have a very loyal employee base. Fewer than five people have voluntarily left the company since we started back in 2005. People like working here. They like the other people that they are working with here. There are no politics. It's that kind of environment that we brought with us.

Much like PeopleSoft, we are taking advantage of a technology shift. PeopleSoft benefited from the shift from mainframe to client-server. When Workday started, people weren’t as focused on how big the shift was from client-server or on-premise computing to what is now called cloud computing or, back then, SaaS.

It now seems like it's even bigger than the shift from mainframe to client-server. This is a massive shift and you see it all across. That's the big difference. We are obviously leveraging a very different technology base. The thing that Dave and I both took away from PeopleSoft is that you have to stay on top of innovation, and that's what Workday is doing. We are innovating where the large ERP vendors have stopped.

Gardner: Some people would say that this notion of taking on and replacing ERP is a quixotic endeavor and that you are tilting against windmills of some kind. Why do you think ERP is vulnerable and that you can “replace" it?

Bhusri: When we first started the company, quite a few people thought we were crazy. Why would you take on these core systems? Why not take on these point systems?

If you look at the history of technology, every 10-15 years, there is a sea change and new application vendors emerge. The big winners are the ones that are the system of record -- the HR system, the accounting system, and the order management system-of-record. Those are the ones that become the PeopleSofts, the SAPs, and the Oracles.

In between, you have point solutions -- recruiting, talent management, and supply chain solutions -- that bolt on. Most times, you're not afforded the opportunity to be a system of record, because of your timing. But we were lucky enough that, when we started Workday, we were at the start of this change.

So, if you have your choice, you would much rather be the system-of-record vendor. Oracle has a $100 billion market cap, and SAP, a $40 billion market cap. Even PeopleSoft, as the third player, was a $10 billion market cap company, when we sold to Oracle. That's not the success you see from the niche vendors.

Dramatic change

It's that, along with the fact that ERP is now 15 years old and just needs to be rewritten. The world has changed so dramatically since the original ERPs were written.

Back then, companies were thinking about being global. Now, they are global. People were not even thinking about the Internet, and now the Internet exists. That was before Sarbanes-Oxley and before the emergence of the iPhone and BlackBerry. All these things pile together to say that it's time to go back and rewrite core ERP. It's no longer valid in today’s world.

Gardner: So, we see an inflection point in ERP, perhaps a detriment to incumbency. We see a shift in technology, more toward cloud types of activities, but we are also seeing a very difficult economic environment. Is there something about the economy that is providing you a catalyst or an accelerant to the adoption of a SaaS-based human resources portfolio?

Bhusri: Absolutely. These last nine months have been challenging for everyone. We, as a system-of-record vendor, saw fewer projects out there. At the same time, because of our new model and the cost benefits of the SaaS solutions, we were probably more relevant than we might have been without the economic downturn.

We had companies that were planning on implementing the traditional legacy systems, but could not afford it. They looked at different alternatives, came across Workday, found out that we are further along than they thought we were, and then decided that this is a much better path.

A great example is Sony Pictures Entertainment. They already own the licenses to the SAP HR system, and yet, after careful consideration, determined they didn't have the budget to implement it. They chose Workday. At the end of the first quarter, they will be live in five months, and they will get the benefit of about a 50 percent cost savings, if not more. They basically quoted it as one-half the time at one-third the cost.

A major upgrade is much like a new implementation and it's cost prohibitive.

Gardner: So, we've seen this fortuitous confluence of external forces along the trajectory of the evolution of technology. Can you tell us what these customers that you have -- I think it's up to 100 now in your first three years, which is pretty dramatic -- what they are doing with your services? Are they swapping one thing out? Are they using it to augment something? Are these people who didn’t do HR from a system-of-record perspective and are now doing that? All the above? What's the mix?

Bhusri: I'd say all of the above, but most are replacing a current legacy system that either is SAP, PeopleSoft, or Oracle. That's the predominant customer we're seeing.

They're replacing it for several reasons. Typically, they've decided that they were not going to take the major upgrade from one of those vendors. A major upgrade is much like a new implementation and it's cost prohibitive.

Usability is important

Second, they are looking at the systems and saying, "What do we get for that upgrade?" The world has changed. Talent is now more important, and usability is a lot more important.

They care about having systems that are accessible to their employees, that look more like eBay and Amazon, and that don't look like an ugly enterprise system. They're looking for systems that are flexible and keep up with their organizations. Workday happens to be a good solution for those systems.

They switch over and they get the benefit right away of going forward. Upgrades are our issue, not theirs, which is a huge, huge difference. That's the elephant in the room. Upgrades are really the bane of the existence of anybody running enterprise IT systems, and it's only getting worse with time.

Another piece is that they are now on a modern system with a user interface that looks like a consumer Internet system. As a result, people use the system. The most important measure of how good a system is whether people like using it, because that makes it more valuable.

Lastly, with our focus on continuing innovation, they are not stuck in time. Every customer gets upgraded every four months to the most current version of the system. So as we are innovating, they are all taking the advantage of that innovation, whether it's in usability, functionality, or a new business model. So, those are really the differences.

Gardner: That strikes me as potentially a game changer -- this idea that the cycle for adoption in a traditional license software model can be three to five years. It's very expensive, very complex, and disruptive. The incentives are against upgrading. But, you at Workday can get out in front of your competitors, with features, performance, and innovation, reacting to the external environments, and then bake that in almost seamlessly and invisibly to your customers.

We're able to leverage those same principles that they are and bring out capabilities very quickly, so a customer can identify something that's important to them.

You are at Workday version 8, already in three years. Am I right? Is this a game changer that the SaaS model can give you a huge advantage over anybody that you compete with?

Bhusri: Absolutely. I like to think about it as building at web speed, and that's how Google, Amazon, and eBay think about it. New features come out very quickly. There are no old versions of Amazon and eBay that they have to worry about supporting. It's one system for all users. We're able to leverage those same principles that they are and bring out capabilities very quickly, so a customer can identify something that's important to them.

We've gotten a lot of requests for an iPhone client. Within one update cycle, four months, we had an iPhone client built. We got a request for BlackBerry, and the next update cycle, four months later, there was a BlackBerry client built. In a traditional enterprise, with cycles of 12-18 months, by the time the release comes out, the world has changed.

So yes, it's SaaS, but it's more, because we build like the other consumer Internet companies and we look to them as our role model. The only enterprise company I look to as a role model is Salesforce, but they embrace many of the same views and technologies as we do.

Gardner: Let me pursue that a little bit. How do you see yourselves different -- either in character, culture, or the way you enter the market -- from Salesforce.com?

Application vendor

Bhusri: I think we are a lot like Salesforce. Dave and I have a very good relationship with Marc Benioff. They're focused on CRM, and we're focused on ERP. I think the big difference is that they are focused on becoming a platform vendor, and we are really very focused on staying as an application vendor.

We will not have a Force.com equivalent. We are really focused on building the best applications that we can, and maintaining a good partnership with Salesforce. We don't plan to be in the CRM world, and we have a very nice integration built to their systems.

They started out in the small and medium business (SMB) world and are moving into the larger enterprises. In some part, thanks to them, we were able to focus on the larger enterprises at the start and really did not focus on the SMB. So, that's a difference. But, really there are more similarities than differences to our approaches.

Gardner: I imagine -- given that you acquired Cape Clear Software and have significant integration capabilities -- that the data sets that exists within a Salesforce engagement with a customer, and your data sets, provide an opportunity to somehow mix and match here. This would allow business intelligence (BI) of some nature, or perhaps even some joining of these data sets?

Bhusri: Absolutely. As we roll out our financial products, we have prototyped some BI work that we have built on the Force.com platform. It takes CRM data from Salesforce, and accounting data and HR data from Workday, and presents it in a Force.com way. It's very slick, and, as we get into the market, we'll probably come up with more examples like that.

Our view is that the bigger bang for the buck, in terms of the cost savings and the real value for the technology, happens with larger companies. We started out serving companies in the 1,000-5,000 range, but our goal is to serve the largest companies.

The Cape Clear technology is really key to our success. Those of us who started Workday are all applications people. The last generation of applications didn't really care about integration, but today's world is very different.

We found out upfront, when we launched Workday with Cape Clear as a partner, that most of our early customers were focused not just on the application, but on the integration to the systems. So, we decided to bring the two companies together. Now, integration is part of everything we think about. Your example is one very good example, but there are a lot of other examples as well, and we don't think about it as an afterthought the way we used to.

Gardner: You mentioned that a significant portion of the adoption for Workday comes from the swapping out of legacy systems. This strikes me as something that would be from very large organizations, Global 2000 enterprises. That, I believe, is your focus. Why, as a SaaS provider, have you focused on large enterprise and not the expected SMBs?

Bhusri: Our view is that the bigger bang for the buck, in terms of the cost savings and the real value for the technology, happens with larger companies. We started out serving companies in the 1,000-5,000 range, but our goal is to serve the largest companies.

As the system has gotten more robust, we've really focused on the Fortune 1000 companies, our biggest being Flextronics. Those large, complex organizations with global requirements have a great opportunity for cost savings. That's number one.

Large-enterprise focused

Number two, with our PeopleSoft backgrounds we are large-enterprise focused. It's what we know. It's what we know how to build. It's what we know how to market. It's what we know how to sell. SMB is not in our DNA, and we believe that there is a big enough market in the large enterprises. That was the natural place to go.

Gardner: What are the economics of this? Some debate we have heard in the past around SaaS is whether it's a cost saver or a long-term wash? How do you view it? If you are going into these large organizations, I assume that you have got a sense of the economic metrics and what the return on investment (ROI) might be?

Bhusri: With the downturn in the economy, we have very detailed analysis, because every selection came down to the ROI case in the selection of a vendor. The data we have now is not theoretical. It's now based on 60 of our 90 customers, of our 99 customers. Being in production, we have been able to go back and monitor it.

The good news about our cost is that it's all-in-one subscription cost, so we know exactly what the costs were for running the Workday system.

The trickier part is that the customers typically underestimate the cost of running legacy. They don't think about the mainframe, the hardware upgrades, the database administrators that they need, or the networks that they have dedicated to their on-premise systems. A lot of outside costs don't really get calculated in.

When you add it altogether, really do it on an apples-to-apples basis, and look at what we have taken over for the customers, it averages out consistently to about a 50 percent cost saving over a five-year period.

When you add it altogether, really do it on an apples-to-apples basis, and look at what we have taken over for the customers, it averages out consistently to about a 50 percent cost saving over a five-year period. There are cases where it's less than that and there are cases where it's more that that, but it averages around 50 percent.

The most important assumption in that five period is that we don't count on a major upgrade of the legacy system. I personally think that's very conservative, because if you are running PeopleSoft, SAP, or Oracle, you should be upgrading at least once every five years. We are falling really far behind.

Gardner: If there is a certain set of applications that you can offload to a SaaS provider, that opens up quite a bit of capacity in your data center, which perhaps forestalls the need to replace a data center, which could cost $40 million or $50 million.

New breed of CIOs

Bhusri: Absolutely. I think the new breed of CIOs, and it's not based on age or experience, thinks differently than the last generation of CIOs did. They think about it as a business issue, not as a technology issue. If you can get your administrative applications, your non-mission critical applications -- CRM, HR, payroll, and accounting -- delivered from a vendor, and you can manage them to service-level agreements (SLAs), why not focus your resources on the core enterprise apps you have?

If you're a Wall Street firm, those are trading applications. If you're an insurance company, that's claims processing. If you're a retail company, it's merchandise management. Leave the rest to vendors who can deliver those levels of service and focus on your core business.

More and more CIOs are getting that. It does free up data-center space. It also frees up human resources and IT to focus in on what's core to their business. HR and accounting don't have to be specialized in running that system. They have to know HR and accounting, but they don't have to be specialized in running those systems.

Gardner: I suppose we can put ERP in that same category. Tell me a little bit about where you are going next. We've seen you come up with HR products and payroll products. You have obviously declared the ERP category, which is large and can be specialized from vertical to vertical. What should we look to next in terms of application sets from Workday?

Bhusri: Our big focus was HR and I think it will continue to be, but, right now, HR has, we believe has reached parity with the legacy systems. In 2009 there has been a big push on payroll, getting those to parity with the legacy systems, because many of the large companies run HR and payroll together. You can't replace just HR, if you leave them with the payroll headache.

We'll expand out of core accounting into procurement and order management and really be the full ERP suite for the services economy.

Going forward, next year, our view is that we want to be an ERP replacement suite, but not for manufacturers. We will sell our HR and payroll accounting system to manufacturers, but we are not looking to manage the shop floor manufacturing, the way an SAP might. We'll expand out of core accounting into procurement and order management and really be the full ERP suite for the services economy.

We've started many of those applications. We've started the procurement applications. We've got this application called Worker Spend, as well. The next big push for us will be in the order management, revenue management, and revenue generation side of the business. The best way to think about it is that we will effectively replace the full footprint we had at PeopleSoft, which was again ERP for the services industries.

Gardner: I want to close out with a little bit of thought leadership or vision direction around the cloud-computing opportunity. I've got a certain theory that Moore's Law carried IT quite a way in the past. For decades, productivity could be almost expected as a given, with this increase in the density of what silicon could produce. I think we are now at a new opportunity level, which is business process innovation.

Do you think that if we refine it, look for the ecosystem partnerships, go for the best opportunity, regardless of the sourcing location or organization, we can see a new level, a different law, perhaps some sort of a cloud law?

Fear of the cloud

Bhusri: I believe so. The only things that will get in the way of that are really two things. One is people's risk aversion. I think that right now people are scared of the cloud, what it means to open up their world into the cloud, and what does social networking do to their businesses.

I actually think that all these things are good things -- sharing of information, sharing of relationships, and being able to source in a way that's very different than the traditional world. So one is the risk aversion.

The second piece, which is a big unknown, is what will the governments do, as these clouds transcend national boundaries. Right now, all the governments are way behind in figuring out how to deal with these.

But, if the governments can stay away and risk aversion reduces over time, cloud computing is going to transform the way people communicate and the way people do business. These business processes will be meta-business processes that span multiple organizations, and they are organic, as opposed to hard-coded the way they are today.

Partners will become partners and fall apart as partners, somewhat organically, depending on the specific project. That's a pretty exciting world that we are headed into.

Partners will become partners and fall apart as partners, somewhat organically, depending on the specific project. That's a pretty exciting world that we are headed into.

Gardner: Do you think that the days are over for 46-percent profit margins from software vendors, and the whole idea of large enterprise devoting 4-5 percent of revenue to IT spend? Are those days over?

Bhusri: I think so, particularly in the latter category of what percent gets devoted to IT. Even some of the companies that have based their businesses on IT are looking at 2-3 percent. So, it's half. That's pretty universal. That's going to come out from somewhere. I think it will impact the margins.

One of the reasons why the margins are so high for those companies is that they are at the tail end of the technology life cycle. They are not really innovating. They are collecting maintenance payments. We all know that maintenance is very, very profitable. Well, when you start in a new technology, it's mostly investing. Usually, when the profitability rates get that high, it means that there is a new technology around the corner that will start cutting into those profitability rates.

Gardner: Well, I certainly look forward to a cloud economy. I'm not sure it will live up to Moore's Law, but perhaps there is something there that's very significant.

We've been talking about Workday, a fiscal management, payroll, and human capital management SaaS provider. Joining us has been Aneel Bhusri, co-founder and c0-CEO. Thanks so much for joining us.

Bhusri: Thanks, Dana, my pleasure.

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: Workday.

Transcript of a sponsored BriefingsDirect podcast with Workday’s co-CEO on the future of delivering HR and ERP solutions as cloud services to large enterprises. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

IT Architects Seek to Bridge Gap Between Cloud Vision and Reality

Transcript of a sponsored BriefingsDirect podcast discussion on properly developing a strategy for cloud computing adoption.

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

Free Offer: Get a complimentary copy of the new book Cloud Computing For Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.

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 properly developing a roadmap to cloud computing adoption in the enterprise. The popularity of the concepts around cloud computing have caught many IT departments off-guard.

While business and financial leaders have become enamored of the expected economic and agility payoffs from cloud models, IT planners often lack structured plans or even a rudimentary roadmap of how to attain cloud benefits from their current IT environment.

New market data gathered from recent HP workshops on early cloud adoption and data center transformation shows a wide and deep gulf between the desire to leverage cloud method and the ability to dependably deliver or consume cloud-based services.

So, how do those tasked with a cloud strategy proceed? How do they exercise caution and risk reduction, while also showing swift progress toward an "Everything as a Service" world? How do they pick and choose among a burgeoning variety of sourcing options for IT and business services and accurately identify the ones that make the most sense, and which adhere to existing performance, governance and security guidelines?

It's an awful lot to digest. As one recent workshop attendee said, “We're interested in knowing how to build, structure, and document a cloud services portfolio with actual service definitions and specifications.”

Well, here to help us better understand how to begin such a responsible roadmap for a cloud computing adoption we're joined by three experts from HP. Please welcome with me, Ewald Comhaire, global practice manager of Data Center Transformation at HP Technology Services. Welcome, Ewald.

Ewald Comhaire: Hi, Dana.

Gardner: We're also joined by Ken Hamilton, worldwide director for Cloud Computing Portfolio in the HP Technology Services Division. Welcome, Ken.

Ken Hamilton: Thanks. It's great to be here.

Jagger: And, we're also joined by Ian Jagger, worldwide marketing manager for Data Center Services at HP. Welcome, Ian.

Ian Jagger: Hey, Dana. Equally happy to be here.

Gardner: Cloud is an emerging and, frankly, a huge phenomenon driven, I think, by economics and the need for business transformation, as well as new IT service delivery capabilities. I wonder what implications this has for IT leaders. They're in the trenches, so to speak, and they are trying to make cloud happen. Ewald, how are these folks reacting right now?

A new benchmark

Comhaire: Independent of how we define cloud -- and there are obviously lots of definitions out there -- and also independent of what value cloud can bring or what type of cloud services we are discussing, it's very clear that the cloud service providers are basically setting a new benchmark for how IT specific services are delivered to the business.

Whether it's from a scalability, a pay-per-use model, or a flexibility and speed element or whether it's the fact that it can be accessed and delivered anywhere on the network, it clearly creates some kind of pressure on many IT organizations. The pressure really comes from three different angles.

The first one is, whether IT organizations should allow their businesses to consume directly those cloud services without any control by IT. Or, should IT basically build up some, what we call, service brokering capabilities, where they can select the cloud services that are of value to the company. Then, maybe they wrap some additional value around them and then offer those through the business, with IT being basically the broker of these capabilities.

The second pressure is, if you don't want it to be outsourced, should you compete and compare yourself to a cloud service provider and transform your own internal IT operations to function more like an internal type of cloud with the same benchmarks on flexibility, scalability and what have you.

Third, of course, is that you will not have everything in the cloud, and some companies may also

First of all, in the cloud, everything is about the service first, and then the technology will follow the service. That's something that companies will have to think about is.

think about becoming a cloud service provider themselves. This is the third element, if your company requests you to play a role in becoming a cloud service provider. How, as an IT organization, do you support that request coming from the business?

So, all in all, there are quite a few questions that the businesses have about their IT organization, which then lead to our recommendation that the company should think about building out the cloud strategy.

Gardner: I'm curious, Ewald. Is this something new in terms of how they approach the problem or are there some precedents that they can go? Perhaps there are procurement precedents and how they secured partners or vendors in the past, outsourced in the past, or if they've done any work with software as a service (SaaS). Where do they start in terms of looking to the past in order to leapfrog into the future?

Comhaire: There are some things that are unique about the cloud. First of all, in the cloud, everything is about the service first, and then the technology will follow the service. That's something that companies will have to think about.

First, think in terms of the services they want to deliver and then fill in those services with the right technologies that achieve the goals of the service. Some companies may already have quite some expertise there. For example, they may have started to build an internal shared services environment, which may already have that service-oriented thinking behind it, but architecturally their services may not have reached the attribute that a typical cloud service has.

Working on the architecture

These companies will have tremendous benefits on the thinking model, the organizing for a service centric delivery model, but they may need to just work a little bit on the architecture. For example, how can they address scalability and the way that supply and demand are aligned to each other, or maybe how they charge back for some of these services in a more pay-as-you-go way versus an allocation based way.

These companies will already have a big head start. Of course, if you're working on an internal cloud, have things like virtualization in place, have consolidated your environment, as well as putting more service management processes in place around ITIL and service management, this will benefit the company greatly. We'll want to have the cloud strategy rolling out in the near future.

Gardner: Now, I'm aware that HP is doing quite a bit of work around cloud. I wonder what you are finding in the field, as you talk to these customers. Ian, what are some of the top reasons that you are hearing from these folks as they're trying to educate themselves, and grapple with this transition? What are the top reasons that you are seeking to do this in the first place?

Jagger: That's an interesting question, because I think the pressure is coming from two sides. One is from the business side in terms of what cloud means for the business, how a business can become more competitive and take a leading gain within the marketplace in which they operate. From the IT side, there is a required reaction of being proactive about looking at what cloud is all about and how cloud can bring advantage ultimately through the business.

So, there are two thoughts. One is that the business wants to gain a competitive advantage, and two, it is up to IT to do something about that. As Ewald was just saying, it could be that the business is already reaching out to services that are within the cloud and accessing those services. There is an onus on IT for them to keep their own shop in order and become the provider themselves of those services as a service.

Gardner: And, if they're looking for this increased agility, I suppose that also would cut out the need for a lot of upfront capital expenditures. It seems that in a down economy you'd want to be able to be agile, but without having to go through a long budget process and jump through a variety of hoops in order to get the funding. I suppose the pay-as-you-go model makes some sense, now more than ever.

Jagger: That's right, and it certainly does cut out some hurdles. If there are critical applications that you seek for your business, and they're available through the cloud, either from a service provider or through the shared services model that Ewald talked about, that's going to be far more efficient and cost-effective, subject to ... terms of the pay-per-use and security. But, once security is addressed, there are definite cost and efficiency advantages.

Gardner: Ken, we've heard for a number of years about the need for agility, something that's not necessarily new and I am sure won't go away. We'll be hearing about the need for agility 10 or 20 years from now. But, are there any specific business drivers for this interest in cloud, any business outcomes that people most frequently expect to happen as they move toward this model?

Growing interest

Hamilton: As we pointed out, we're seeing a growing interest in cloud specifically around cost savings. Certainly, in this economy, cost savings and switching from a capital-based model to an operational model, with the flexibility that implies, is something that a number of companies are interested in.

But, I'd also like to underscore that, as we've discussed, the definition of cloud and the variety of different, and sometimes confusing possibilities around cloud, are things that customers want to get control of. They want to be able to understand what the full range of benefits might be. The major ones we see right now are underscored by cost savings and financial flexibility in going from a capital-based model to an operational model.

By the same token, we're finding that they're also interested in exploring far-reaching benefits. As Ewald pointed out, some companies who have not traditionally been in the “technology business,” may find that cloud offers them the opportunity to be able to change their business model.

We're dealing with a couple of telecommunications providers, and even some financial institutions in Asia Pacific Japan (APJ), who are looking cloud as an opportunity to be able to expand their market and to be able to take on new capabilities, in addition to some of the economies of scale that come out of this.

In addition to that, we touched on faster time to market and agility. In a typical internal

So, cost savings as well as agility and new business capabilities really are the three main types of benefits that we are seeing customers go after.

environment it may take weeks or months to deploy a server populated in a particular fashion. In that same internal cloud environment that time to market can be as little as hours or minutes, along with some of the increased functionality.

So, cost savings as well as agility and new business capabilities really are the three main types of benefits that we are seeing customers go after.

Gardner: Ken, doesn't this in some ways fundamentally shift the role of IT? It seems, based on what you just said, that IT's role is now about betting on those who are supplying services, perhaps crafting a service-level agreement (SLA) or even getting at the contractual negotiations and then monitoring the quality of those services.

Is that a different role for IT? In the past, they would have simply defined requirements and then delivered the services themselves.

Hamilton: I wouldn't say it's a different role, but rather a greatly enhanced role. IT does procure services today and does a fairly decent job of it. Because of the service orientation, this puts a greater emphasis on understanding not just the technological underpinnings, but the contractual service level elements and the virtual elements that go with this.

A number of implications

As we know, virtualization is a big part of this, but when virtualization comes into play, there are a number of different implications for the service structure, availability, security, risk, and those types of elements. So, there is a greater emphasis today in terms of laying those out, defining them, and procuring the right structure to be able to meet their specific business needs.

Gardner: I suppose their concern, then, is defining the requirements and then measuring the outcome, rather than being concerned what that middle phase would be -- how you actually do it. Is that fair?

Hamilton: Right. If there is a big shift, it's moving from the orientation of a physical infrastructure, dealing with the products, and then delivering that as their service to a grouping of capabilities with service levels, particularly involving external service providers in that level of reliability or acting as an external service provider. So, there is a greater level of expectation on the part of customers for that level of service delivery.

Gardner: Going back to the market data that we've gathered through these HP workshops on cloud adoption and data-center transformation, Ewald, as folks now start to proceed in this direction toward cloud model, recognizing some shifts, looking for those agility and monetary benefits, what's holding them back? What do they say are their top inhibitors from pursuing that?

Comhaire: Dana, that's a very interesting question. We often talk about all the benefits, but obviously, specifically for our enterprise customers, there's also an interesting list of inhibitors. In every workshop that we do, we ask our participants to rank what they believe are the biggest inhibitors, either for themselves to consume cloud services or, if they want to become a provider, what do they believe will be inhibiting their potential customers to acquire or consume the services that they are looking for? Consistently, we see five key themes coming as major inhibitors.

A lot of companies have value chains that they've built, but what if some of the parts of that value chain are in the cloud? Have I lost too much control? Am I too much dependent?

The first one is about the loss of control. That means I am now totally dependent on my cloud-service provider in my value chain. A lot of companies have value chains that they've built, but what if some of the parts of that value chain are in the cloud? Have I lost too much control? Am I too much dependent?

There are some interesting stories that are absolutely real. A satellite service provider, for one of its key component in bringing the television signals to your home, was relying on a cloud service provider that was taken over by one of their competitors to that satellite company.

As a result, suddenly there were interruptions in the service quality and, of course, this leads into the reality that there could be a loss of control if you have parts of your value chain out in the cloud. That's a real concern, not a perceived one.

Also, there is lack of trust in your cloud service provider. That could have to do with the question of whether they'll still be in business five years from now, and will I have to take back control, if they go out of business. We know that this existed in the dot-com world and cost the companies a lot of money by bringing it back in-house when the provider went out of business.

It could also have to do with the things like price-hikes. What guarantees for me, for example, that the price of a CPU per hour wouldn't double, once the provider has achieved a big enough critical mass. They can decide to double the cost at any moment in time.

Security and vulnerability

Another area that's called out frequently is the whole security and vulnerability case. Some of that is perceived. If you architect it well, best-practice cloud-service providers can do a great job of actually being more secure than a traditional enterprise dedicated environment.

But, still, there are some things that are more difficult to control. For example, you become more vulnerable to attacks, when you are on the Internet. A well-known service provider becomes a natural source of all kind of attacks. Of course, that's more difficult to prevent architecturally. It's something you will have to deal with as a cloud service provider, and something that consumers will have to take into account.

There are also difficulties around identity management and all of the things to integrate security between the consumer and the provider that are an additional complexity there.

Confidentiality is the fourth reason and mostly concerning the data, because, more and more, the data goes with the service. What guarantees do we have, for example, that an employee at a service provider can't take that data and sell it to a government or some other third party.

So, this whole reliability concern and disaster recovery is obviously a key element, along with one that comes out more and more in recent workshops: How do I integrate with the cloud?

Also, data has to go over the network. There is always a risk of interception and there is always a risk, if you have a multi-tenant environment, that somehow, through an operation error, some data that should be confidential is exposed to another party. That is definitely a concern for a company.

The final one is reliability -- is the service going to be up enough of the time? Will it be down at moments that are not convenient? I go back to the example of the satellite company. What if the downtime is only five minutes but it's always at 8 p.m., the prime time of satellite television? It may only be five minutes, but it can take you an hour to recover, and it's coming at the most inconvenient moment.

So, this whole reliability concern and disaster recovery is obviously a key element, along with one that comes out more and more in recent workshops: How do I integrate with the cloud?

That is, if I need to make a little change in the business process, with an application in the cloud, can the cloud-service provider make that change? How can I process integration in such a distributed world? That gets a little bit more difficult than in a more traditional enterprise architecture.

Gardner: I hope that a lot of the cloud providers are listening, because it seems like they have quite a workload to overcome some of these issues around security and control. I was a little bit surprised not to hear that issues about standards and neutrality weren't in the top five or six. Do you perceive them as being a little bit lower or do they perhaps fall into these areas of security and confidentiality?

Standards and integration

Comhaire: That's a great question, Dana. They definitely fall in the category of integration, because if the cloud service provider has done everything in a unique way, it's still of great value, a great quality of service, and maybe with a great cost, but it's difficult to integrate the cloud service due to its not following certain standards or being difficult to integrate with the standards that already at the enterprise inside of their data center, then obviously you get this integration difficulty. So, standards and integration difficultly are the same issue expressed in different terms.

Gardner: I wonder if either Ken or Ian has any further points that they've observed in the field about inhibitors. What's holding customers back as they pursue cloud adoption?

Hamilton: I'd just underscore the concerns with security. Particularly in a multi-tenant environment, that seems to be the number one issue that the customers are concerned with. So, first is security, and number two would be reliability. There have been some large failures of some top-named cloud providers. I think they're getting better, but still not quite ready for prime time in some cases.

Gardner: Ian, any thoughts?

Jagger: I'd probably just add to that, not just from the IT side in terms of security, but also from the business side in terms of trade secrets. If you're a provider of cloud services, you know you have that application on there and you have got it out through cloud, which is the great business model you've used to get to market itself. But, how secure are my trade secrets with doing that, and also with respect to addressing to national privacy laws as well. There are some issues that need to be taken into account.

Gardner: Ken, let's go back to you. As customers need to get better informed and to lay out their roadmap, what options do they have? Perhaps you could tell us what would you try to offer them as a way to get started?

But, how secure are my trade secrets with doing that, and also with respect to addressing to national privacy laws as well. There are some issues that need to be taken into account.

Hamilton: Well, the first, and the most important thing, is to make sure that the executive decision makers have a common understanding of what they might want to achieve with cloud. To that end, we've developed a Cloud Discovery Workshop, which is really a way of being able to frame the cloud decision points and to bring the executive decision makers together.

They can have a highly interactive discussion around what key business objectives they might have and what risks and opportunities there might be, many of which we've covered already. It's also to make sure that the organization is crystallized around their specific areas of opportunity and benefit, as well as the specific risks and investments that might be required to focus on this customized view that they have.

This Cloud Discovery Workshop does a great job of engaging the executive team in a very focused amount of time, as little as an afternoon, to be able to walk through the key steps around defining a common definition for their view of cloud. It's not just our view or some other vendor's view, but their definition of cloud and the benefits that they might be able to accrue.

They, specifically drill that down into particular areas with a return on investment (ROI) focus, the infrastructure capabilities that might be required, as well as the service management operational and some of the more esoteric capabilities that go hand in hand, addressing security, privacy, and other areas of risk. It's just making sure that they've got a very clear way of being able to document that, and then move forward into more detailed design, if that's the direction they want to move in.

Gardner: Ewald, you mentioned earlier that those shops that have adopted service performance and IT shared services activities have a bit of a head start, but for them or others? What sort of roadmap process do you offer or recommend?

A better view

Comhaire: From the workshop customers basically get a better view of the strategy they want to go for. We have an initial discussion on the portfolio and we talk also a little bit about the desired state. In the roadmap service, we actually take that to the next level. So we really start off with that desired state.

We have defined the capability model with five levels of capability. We don't want to call it the maturity model, because for every company, the highest maturity isn't necessarily their desired state or their end state. So, it's unfair to name it "maturity." It's more a capability or an implementation model for the cloud. We have five levels of maturity and then six domains of capabilities.

The first thing we determine is an appropriate next state to put as an objective. If you want to become a cloud-service provider, but you haven't done the initial service enabling in your company, you have to go through this intermediate route. You need to say, "First, I will start to build something like an internal shared service that starts bringing technology together and delivering it as a service internally, before I step into the outside market."

So, you first build credibility within your own business, before you actually build credibility in the market. That could be a very logical step on the roadmap. That's Module 1 -- helping customers determine the next desired state on the roadmap and then the end state.

In the case of the cloud, the capacity manager will need to make decisions to acquire new assets to grow the business.

Module 2 is really about, "We know where you want to be now. Let's get more in detail about what projects we need to execute to get to there? What are the gaps? What resources are needed and what skills of resources do you need?"

In the cloud, you may have new roles, like a service delivery manager. The role of a capacity manager is totally different in the cloud than in the non-cloud. In the case of the cloud, the capacity manager will need to make decisions to acquire new assets to grow the business. They can't go to a finance manger. The process would take way too long and the scalability would not be there corresponding to a cloud model.

So, the roles are different. We look at how many people you need, in what roles, with what descriptions and what capabilities. We also look at the timing of what to do when, what the dependencies are of other parts of the organizations, and how to phase that in over a timeline. This is typically what Module 2 is.

Module 3 of the roadmap is then, "We now know where we want to be. We have a good idea of the gaps, the projects that need to be done, the resources, and their skills. How do we sell it to the company and how do we present our conclusion to an executive board or to the executives in the company?"

It's how do we build a business case and how we present that business case financially, value wise, and strategy wise through the corporation. That's really the three components of our roadmap service that then can lead into a cloud design and an implementation activity later on.

Gardner: I imagine of any transformative activity that this is a multi-year process. On that roadmap, do you have any timeline that gives us a rough sense of how quickly these organizations can get to the cloud, or should they not try to rush things?

Keep it simple

Comhaire: One core advice we always give is, "Keep it simple." Rather than bring out a whole portfolio of cloud services, start with one. And, that one service may not have all the functionality that you're dreaming of, but become good at doing a more simplified things faster than trying to overdo it and then end up with a five- or six-year's project, when the whole market will be changed when you can roll out. A lot of the best practice in building the roadmap is to simplify it, so it does not become this four- or five-year project that takes way too long to execute.

Gardner: Well we are just about out of time. I hope we could go around the group and get your impressions on how to get started or any specific areas that people could go to for further information or deeper background. Let's start with you, Ian. Where do people get started, and how should they proceed?

Jagger: I think they should talk to somebody like Ewald. That would be a great start.

But I would probably just like to add, Dana, that what we talked about here is simplifying what cloud is about for the customer, ignoring to an extent how the industry itself is defining cloud definitions. We're looking at this in three ways: do you want to be a service provider, do you want to source cloud, or do you want to build your own shared infrastructure on a private cloud.

And, we've just been talking about roadmap. You actually have the options of being any or all of the above. You can do all three of them. Your business model could be as a cloud service provider. Your sourcing model could be from an outsourcing perspective. What you're not outsourcing, you may actually prefer to build as a shared services internal model.

Keep it simple. Make sure that you've got a very good team understanding of what it is that you want to get done, and leverage experts.

You need to determine what your priorities are. I'm not being facetious when I say talk to Ewald. Ewald's team of guys, are absolutely the correct start point. But your local HP firm sales representative would also be an ideal start.

Gardner: Alright. Ken Hamilton, your ideas about first steps.

Hamilton: I would really underscore what Ian has just said. Keep it simple. Make sure that you've got a very good team understanding of what it is that you want to get done, and leverage experts. We have Ewald and a number of highly qualified people in each of our regions. We just really want to keep it simple, understand what it is that you're trying to get done and leverage the expertise of people who have done it in the past.

Gardner: Quickly back to you, Ewald. I keep hearing the word cloud computing, but if we were to interchange services-oriented architecture (SOA), it would probably just as accurate. Is there a commonalty now between the two?

Comhaire: There have many things in common. I would still argue that there are also some differences. A cloud's architecture will be using an SOA as its underlying fundamental, but the composability of an SOA is not just in how you design the application.

It also has to do with how the services in your cloud can be used together to achieve a bigger integration. That's not just at the level of the application, but it's also the IT services themselves. Are they composable and can they be combined to achieve a bigger thing than just the one service and its value as a standalone item?

Gardner: Thanks so much. We've been discussing some of the ways in which IT organizations and enterprises can move towards cloud and reduce risk, but perhaps accelerate attaining the business benefits of an "Everything as a Service" world. Here to help us with this, we've been joined by Ewald Comhaire, global practice manager, Data Center Transformation at HP Technology Services. Thanks so much, Ewald.

Comhaire: Thanks, Dana.

Gardner: We've also been joined by Ken Hamilton, worldwide director for Cloud Computing Portfolio within HP Technology Services. Thanks to you too, Ken.

Hamilton: Thank you, Dana.

Gardner: And Ian Jagger, worldwide marketing manager for Data Center Services at HP. Thank you, Ian.

Jagger: My pleasure, 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.

Free Offer: Get a complimentary copy of the new book Cloud Computing For Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.

Transcript of a sponsored BriefingsDirect podcast discussion on properly developing a strategy for cloud computing adoption. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

Long-Overdue Network Transformation Must Support Successful Data Center Modernization

Transcript of a BriefingsDirect Podcast examining how data-center transformation requires a new and convergent look at enterprise network architecture.

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

Special Offer: Gain insight into best practices for transforming your data center by downloading three new data center transformation whitepapers from HP at www.hp.com/go/dctpodcastwhitepapers.

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 reevaluating network architectures in light of newer and evolving demands. Most enterprise networks are the result of a patchwork effect of bringing in equipment as needed over the years to fight the fire of the day, with little emphasis on strategy and the anticipation of future requirements.

Nowadays, we see that network requirements have, and are, shifting, as IT departments adopt improvements such as virtualization, software as a service (SaaS), cloud computing, and service-oriented architecture (SOA).

The network loads and demands continue to shift under the weight of Web-facing applications and services, security and regulatory compliance, governance, ever-greater data sets, and global area service distribution and related performance management.

It doesn't make sense to embark upon a data-center transformation journey without a strong emphasis on network transformation as well. Indeed, the two ought to be brought together, converging to an increasing degree over time.

Here to help explain the evolving role of network transformation and to rationalize the strategic approach to planning and specifying present and future enterprise networks, is Lin Nease, director of Emerging Technologies, HP ProCurve. Welcome to the show, Lin.

Lin Nease: Thank you.

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

John Bennett: Hi, Dana.

Gardner: And, Mike Thessen, practice principal, Network Infrastructure Solutions Practice in the HP Network Solutions Group. Welcome to the show, Mike.

Mike Thessen: Thank you. Hello, everyone.

Gardner: John Bennett, let's start with you. Tell me a little bit about the typical enterprise network as it’s evolved, and how does that affect data-center transformation? [Related podcast: See how energy conservation factors into data center transformation.]

Helping customers

Bennett: Let's start by reminding people what data-center transformation is about. Data-center transformation is really about helping customers build out a next-generation data center, an adaptive infrastructure, that is designed to not only meet the current business needs, but to lay the foundation for the plans and strategies of the organization going forward.

In many cases, the IT infrastructure, including the facilities, the servers, the network, and storage environments can actually be a hindrance to investing more in business services and having the agility and flexibility that people want to have, and will need to have, in increasingly competitive environments.

When we talk about that, very typically we talk a lot about facilities, servers, and storage. For many people, the networking environment is ubiquitous. It's there. But, what we discover, when we lift the covers, is that you have an environment that may be taking lots of resources to manage and keep up-to-date.

You may have an environment that is not capable of moving network connections as quickly as servers, applications, and storage devices need and you want them to in order to meet your agility objectives.

We also find an environment that can be a cabling nightmare, because it has grown in a kind of an organic way over time. So, in looking at data center strategy and looking at data-center transformation, we have to make sure that the whole data-center architecture, including the network infrastructure both inside the data center and the services it provides to the organization, are really aligned to meet those goals and objectives.

It becomes increasingly important to have, as we continue to experience incredible explosions in storage and data volumes, with the new types of information, and with the historical information that's maintained.

The networking infrastructure becomes key, as an integration fabric, not just between users in business services, but also between the infrastructure devices in the data center itself.

That's why we need to look at network transformation to make sure that the networking environment itself is aligned to the strategies of the data center, that the data center infrastructure is architected to support those goals, and that you transform what you have and what you have grown historically over decades into what hopefully will be a "lean, mean, fighting machine."

Gardner: Lin Nease, from the perspective of an architect, is there a lag, or perhaps a disconnect, between the trajectory and evolution of networks and where the entire data center has been moving toward?

Multiple constituencies

Nease: Absolutely. The network has basically evolved as a result of the emergence of the Internet and all forms of communications that share the network as a system. The server side of the network, where applications are hosted, is only one dimension that tugs at the network design in terms of requirements.

You find that the needs of any particular corner of the enterprise network can easily be lost on the network, because the network, as a whole, is designed for multiple constituencies, and those constituencies have created a lot of situations and requirements that are in themselves special cases.

In the data center, in particular, we've seen the emergence of a formalized virtualization layer now coming about and many, many server connections that are no longer physical. The history of networking says that I can take advantage of the fact that I have this concept of a link or a port that is one-to-one with a particular service.

That is no longer the case. What we’re seeing with virtualization is challenging the current design of the network. That is one of the requirements that are tugging at a change or provoking a change in overall enterprise network design.

Gardner: Mike Thessen, from a systems integrator problem set, have there been different constituencies, perhaps even entirely different agendas, at work in how networks are put together and then how the data center requirements are coming around?

Thessen: Sure. From the integrator perspective, we get involved with clients' real problems and real requirements. People listen to the press and they are trying to do the right thing. What we are finding is that, many times, they get distracted by that and lose sight of the fact that what they're really trying to do is provide access to applications within their data center to their user base.

We try to bring them back around, when we work with them on a consulting basis, to not so much focus on products, but on what they are trying to achieve overall at a very high level -- just to get things started.

Gardner: Is there a new philosophy perhaps that needs to be brought to the table, Mike, around planning for network, data center, and storage requirements in tandem? This seems to have been something that happened on a fairly linear basis in the past. How do we get that to be simultaneous, or is that the right way to go?

Thessen: In my mind, you are really talking about collaboration. Data-center networking certainly cannot happen in a vacuum. In years past, you were effectively just providing local area network (LAN) and wide area network (WAN) connectivity. Servers were on the network, and they got facilities from the network to transport their data over to the users.

Now, everything is becoming converged over this network -- "everything" being data storage, and telephony. So, it's requiring more towers inside of corporate IT to come together to truly understand how this system is going to work together.

Gardner: Lin Nease, is this about services orientation? Do some of the same methods and best practices and architectural approaches from the application side come to bear on the network features and functions as well?

The only way out

Nease: Absolutely. In fact, that's the only way out. With the new complexity that has emerged, and the fact that traditional designs can no longer rely on physical barriers to implement policies, we have reached a point, where we need an architecture for the network that builds in explicit concepts of policy decisions and policy enforcement. They're not always in the same place, and it's not always intuitive where a policy should be enforced or decided upon.

As a result of that, the only way out is to regard the network itself as a service that provides connectivity between stations -- call them logical servers, call them users, or call them applications. In fact, that very layering alone has forced us to think through the concept of offering the network as a service.

So, service orientation is crucial and it will allow those who build infrastructure to no longer be forced into an ad-hoc situation, where they build infrastructure in an extremely fluid manner with respect to how applications are being designed, but rather to a much more formal presentation of what they are doing as a server. That presentation becomes the designed target for both sides, and, as I said, that's probably the only way out with the complexity that's emerged.

Just to give you an example, look at a virtual server today and some of the new technologies that are being proposed like Single Root I/O virtualization combined with virtual switching, combined with edge, blades, switching, and standalone switches. You could have seven or eight queues that separate an application from just the core of the network. That's far more than in the past. That complexity is going to cause applications to break. So, this mentality is probably the only way out.

Gardner: I'd like to drill down, if we could, on virtualization. There are several different layers and levels of this course. We're starting to even hear more about desktop virtualization, PC-over-IP, and different approaches to bring the essence of an operating system environment to the user, but without them really having the actual compute power locally.

Let's go to back to John Bennett. John, tell us a little bit about the different dimensions of virtualization, and how that has an impact on this complexity issue in the network?

Desktop virtualization is seen as a major opportunity to not only provide for better control of desktop devices, but also better security and better protection of end-user data.

Bennett: Virtualization is a major theme. Ann Livermore in her keynote at VMworld challenged people to think about moving from virtualizing servers to virtualizing their infrastructure, and even go beyond that. Server virtualization has just been the starting point for people moving to a shared infrastructure.

In parallel with that, we see an increasing drive and demand for virtualizing storage to have it both be more efficiently and effectively used inside the data center environment, but also to service and support the virtualized business services running in virtualized servers. That, in turn, carries into the networking fabric of making sure that you can manage the network connections on the fly, as Lin talked about.

Then, it reaches outside of the data center. Desktop virtualization is seen as a major opportunity to not only provide for better control of desktop devices, but also better security and better protection of end-user data. Now, you are taking an environment that used to run locally in an office with just data connections back to the data center to now you have an environment which depends upon the data center for all of the services that are being provisioned on a virtualized desktop. So, you have that complexity taking place as well.

Virtualization is not only becoming pervasive, but clearly the networking fabric itself is going to be key to delivering high quality business services in that environment.

Gardner: Back to Mike Thessen. Tell me a bit about this from the integration perspective. How do these virtualization complexities need to be considered as folks move towards a network transformation of some sort?

Understanding requirements

Thessen: Virtualization, from the network perspective, really centers on several aspects. First, from the system and application perspective, we have to understand the requirements of how blade server interconnectivity is going to be achieved, how things like dynamic movement of hypervisors will be managed, and basically how much Layer 2 adjacency is required in the network.

While Layer 2 is expanding in the data center, it really needs to be contained such that it's limited to what is required within a pod, cell, module, or whatever the term is that a client may use to define a span of the data center.

We don't want to allow Layer 2 domains to expand across the entire data center or be unlimited between data centers. We want to contain this Layer 2 environment. While it's getting bigger we don't want to have the attitude that we'll just allow it to go everywhere. There will still be issues with that large span of Layer 2 Ethernet connectivity, and from a manageability perspective it gets very complex.

Second, there is a trend to utilize network device virtualization to eliminate the need for things like spanning tree, the redundant default gateway mechanisms, and so forth. Those are different ways to use technology to expand the Layer 2 domains, but limit the risk associated with that.

Third, this tends to utilize device and routing control-plane virtualization for logical separation of external-facing applications, especially in things like financial industries, and so forth.

We really promote having our clients spend the extra money to have that lab always available to test things in.

The test and development and QA environments are extremely important, especially as things become more virtualized. Things really have to be tested. We really promote having our clients spend the extra money to have that lab always available to test things in. Then, naturally, how do we do that more cheaply and less expensively?

You can use certain virtualization techniques in the networking hardware to separate those environments in a logical manner, as opposed to having to buy completely separate networks to do your testing.

The fourth thing is that networks need to be prepared for the convergence of the communication paths for data and storage connectivity inside the data center. That's the whole conversion -- enhance, Ethernet, Fiber Channel over Ethernet. That's the newest leg of the virtualization aspect of the data center.

Gardner: Of course, nowadays, the IT and other departments, and telecom folks are all under pressure to cut cost. So, if we are going to transform networks, not only do we have to look at complexity and bringing up the support of additional requirements, but folks are looking for efficiencies as well.

Lin Nease, what about network transformation? It can allow our requirements to be met, but perhaps, at the same time, find efficiencies, higher utilization, and cut overall cost.

Accounting for use cases

Nease: It's important to account for all the use cases that are critical to the enterprise, and it's possible to design networks that have what I will call a most common denominator. What we've found with HP's own huge data center consolidation was that ruthless standardization was the key to cutting cost.

The way I cut cost is I don't have an artificial metric like server utilization, CPU utilization or network utilization. I have a simple metric of budget. And from budget, comes all other mechanisms for optimization.

A most common denominator network is another way of saying, "I can build a substrate of the data center network at least for this point in time, call it a pod, call it a cell, call it a unit of modularity. I can put it in place and it will solve every use case I care about -- everything from the high balance, low latency requirements of middleware clustering or database clustering all the way down to the mundane."

I can cross server tiers for example with relatively low bandwidth requirements. But I can do that all from a very high performance substrate. If I have one design, I have only one thing I need to manage. Operationally, it solves multiple problems at once. But, rather than being purpose built for each application, now the network is built once as a standard. As a result of the fact that it solves all the problems, I can change the nature of what my change review-boards look like, for example.

If I want to go in and put in new servers, I don't have to worry about including someone from a particular department in the decision, because I know the network works for all the use cases I care about.

The key for networking in particular is, number one, to enable higher utilization of servers. . . .Then, secondly, to make sure that the thermal design of the data center is optimized.

Gardner: Lin, as we try to get that overall perspective of a solution approach, do we also find ourselves able to cut energy use? That seems to be an important part of a lot of transformation initiatives as well.

Nease: Oddly enough, on one side of the coin, I just talked about ruthless standardization. The simplest way to drive down the cost of my process is to overkill. On the other hand, now we have the concept that overkill is bad, because it consumes a lot of energy. Well, here's our way out. Here's the degree of freedom we have.

Thermal management is probably the biggest hitter in terms of energy savings and consumption, going forward. The key for networking in particular is, number one, to enable higher utilization of servers. That's the most direct way of saving on energy. Then, secondly, to make sure that the thermal design of the data center is optimized.

It's quite possible to have a completely independent architectural approach to logical topology, versus the approach to physics. In this case, when I say, physics, I mean how I support the hot aisle, cold aisle, the ventilation, and the energy pressure drops.

If I can service a cooling aspect of the data center, it turns out that air conditioning and cooling account for more than half the energy consumption in a typical data center. So, by optimizing on the thermal front, I can still have a very simple network and I can separate the concern by topology architecture.

Gardner: We hear the term "convergence" batted around a lot, and just from our call today, I can tell that convergence really has multiple aspects and perhaps even multiple levels of convergence.

Back to you, John Bennett. In talking about our network transformation philosophy, are we converging storage and data with applications. Is it data center and network? Is it on-premises and off-premises or cloud? How can we set a taxonomy or get a handle on what we mean by convergence nowadays?

Better integration

Bennett: Fundamentally, convergence is about better integration across the technology stacks that help deliver business services. We're saying that we don't need separate, dedicated connections between servers for high availability from the connections that we use to the storage devices to have both a high-volume traffic and high-frequency traffic accesses to data for the business services or that we have for the network devices and the connections between them for the topology of the networking environment.

Rather, we are saying that today we can have one environment capable of supporting all of these needs, architected properly for particular customer's needs, and we bring into the environment separate communications infrastructures for voice.

So, we're really establishing, in effect, a common nervous system. Think about the data center and the organization as the human body. We're really building up the nervous system, connecting everything in the body effectively, both for high-volume needs and for high-frequency access needs.

Gardner: Mike Thessen, we've heard here about the need for convergence and managing complexity. We're hearing about a lot more services coming into play. It now sounds as if we are taking what people refer to as a utility or grid approach for data and applications and we are applying that now to networks. Is that how we should be thinking about this, instead of getting bogged down in convergence? Is this really more of a cloud or fabric approach that includes network services?

Thessen: As someone said, a few minutes ago, at some level of the network the primary aspect needs to be utility. When you're talking about clouds, clouds can be not what people think about clouds from Amazon or wherever, but even clouds inside a client's own IT environment. So, it's possible to do something like replace the way they typically would do external client access to their data. These things come to mind especially in the financial industry.

Without understanding who is talking to whom, how applications communicate, and how applications get access to other IT services, such as directory services and so forth, it's really difficult to secure them appropriately.

The most important thing is really still the brutal standardization, as Lin said -- network modularity, logical separation, utilizing those virtualization techniques that I talked about a few minutes ago, and very well-defined communications flows for those applications. When things may not go right, when things break, or when there are performance issues, there is documentation there that defines who is talking to what.

Additionally, you need those communication flows especially in these SaaS or cloud-computing, or convergence environments to truly secure those environments appropriately. Without understanding who is talking to whom, how applications communicate, and how applications get access to other IT services, such as directory services and so forth, it's really difficult to secure them appropriately.

We haven't talked about WAN very much. We've been focused on the data center. But, data centers are more or less useless, without people being able to access them through some sort of wide-area facility.

We focus a lot on determining how these new applications are going to communicate over the WAN by doing dependency mapping of the applications and by doing transaction profiling of the applications from the network perspective. We identify, not only how much bandwidth required by transaction and how many users they're going to be hitting at any given point in time, but also how latency is going to affect the end-user experience.

If you move everything into the cloud, which implies virtual centralization, the users are now more separated from that. So, you really have to pay close attention to how latency is going to affect these new environments.

Gardner: It certainly seems to be an awful lot to chew, to bite off, and factor when we move towards network transformation. I wonder what some of the common mistakes are that people make as they approach a certain path, a crawl-walk-run, or a methodological, or an architectural overview. What might they do that perhaps prevents them from getting to where they want to be? Let's start with you Lin. What are some common mistakes people get into as they start to move towards network transformation?

The most common mistake

Nease: This one is near and dear to my heart, being an evangelist for the networking business. Too often people are compelled by a technology approach to rethink how they are doing networking. IT professionals will hear the overtures of various vendors saying, "This is the next greatest technology. It will maybe enable you to do all sorts of new things." Then, people waste a lot of time focusing on the technology enablement, without actually starting with what the heck they're trying to enable in the first place.

Unfortunately, I think this is the most common mistake by far. I'll give you an example of how the inevitability of some technology trend will probably lead people far less down a path of great optimization that what they are thinking, and this is in convergence of storage traffic with data traffic.

There is a big difference between storage traffic and voice traffic. Voice traffic is limited by the perceptions of human beings. It will never require more bandwidth for a phone call, and probably less than it does today, as technology evolves. It's very easy to incorporate that into a common plumbing.

Storage, on the other hand, is directly tied to server performance. Storage is going to continuously grow in terms of requirements. There is so much focus on replacing the technologies that we don't like that we forget about what we're trying to enable from an application perspective.

How do I have applications that are deployed on infrastructure that follow the potential energy of business requirement changes, rather than first focusing on how the plumbing works? That's the biggest mistake people make. What they'll find is that they'll look at a lot of these technologies. Two years from now, you'll see networks that look quite a bit like they do today, because the focus has not been on enabling what it is that people are trying to actually accomplish in their business.

Gardner: Mike Thessen, the same question. Are there some common mistakes, from your vantage point, as a systems integrator, that folks fall prey to as they move into network transformation mode?

We prefer to get in earlier, and really strategize with the client -- what are we trying to do and what are we trying to come from and get to.

Thessen: Lin focused on picking a technology. If you take that a step farther, lots of times our clients are hell-bent on picking a specific product or a specific vendor, prior to actually defining the requirements.

I have a couple of sayings that a bill of materials is not a design and it takes a lot of effort to get a PowerPoint presentation into something that you can actually implement. We often see clients coming to us and they've already got a bill of materials. Then, they want you to back into an architecture and a design an implementation strategy.

As I said earlier, we take a different approach. We prefer to get in earlier, and really strategize with the client -- what are we trying to do and what are we trying to come from and get to.

Testing is required

I mentioned this earlier. Sufficient testing of this new technology in a dedicated lab environment is absolutely required, whether you are talking about how the applications are going to work, or just making sure that you can get the network components working together properly with all the new features and functions that you might want to implement. It's absolutely key, especially for the data center environments, to have that test.

Sometimes, we also see that the need for one gigabyte, or lower, speed transports are being forgotten about. Everybody is all wrapped up around 10 gig, 10 gig, 10 gig -- they've got to have it everywhere.

We typically recommend a mix of 1 gig and 10 gig, based on the requirements for the existing servers. Ten gig coming from blade is absolutely right on target, but do we really need 10 gig for every server on the network? Probably not, at this time.

What we need to look at is what is the real performance of these services and when the next technology refresh cycle for these servers is going to occur. Possibly, if we do our modularity and standardization process right, we can rev servers and network gears simultaneously within those modules, and really keep our cost down, as opposed to piling ten gig on everything right now.

A lot of times, our clients also forget about the fact that a lot of the management interfaces on some equipment don't even support one gig yet. So, there is this mix of the technologies and products that need to come together and they really need to be thought through, before you go out and buy the bill of materials prior to having all your requirements in check.

The law of large numbers said that they didn't actually have to build an extremely complex network to get big gains, and there is a lot more behind that than you might think.

Gardner: Lin Nease, how about some examples of where folks in the field have embarked on a network transformation, and taken into consideration some of these issues that we have been discussing today? What have they found? What are some of the paybacks? Any examples of success or perhaps things to avoid?

Nease: I'll start with the biggest success, and it's very close to home -- Hewlett-Packard's own data center consolidation -- 85 data centers down to six. The thinking on the network, which was very consistent thinking overall, was simplicity. If you were desperate and you had to actually have a low budget, what types of actions would you take? If you don't take those actions, you should justify the benefits of doing something different than what you would do well, if you are desperate.

It wasn't desperation, but rather sheer cost savings, incredible cost savings, that HP got out of IT. They actually deployed 5,000 of our ProCurve devices, for example, in a network that was deliberately kept extraordinarily simple. As we talked about earlier, we ruthlessly standardized the whole VLAN topology. The approach to layering was kept very, very simple.

The law of large numbers said that they didn't actually have to build an extremely complex network to get big gains, and there is a lot more behind that than you might think. In the process of doing that in the network, HP saved well over $90 million in the deployment of just six data centers on network gear alone.

Gardner: Mike Thessen, do any examples come to mind in terms of how this should be done in the field?

Right on track

Thessen: We're working in all kinds of environments all the time, from financials, to manufacturing, to retail. The things we are covering here today are all right on track with what our clients are asking for: "How do we implement virtualization? I want to consolidate my voice and my data infrastructures. I want to be prepared for any level of convergence within the data center from a storage and data perspective, but I want to do it in the right way."

We had several instances where we put in some of the converged infrastructures just from a future-proofing perspective, because the client's timeline was right. In other cases, we talked the client out of going down that path and doing what I typically call more of a discrete network non-converged, if you will, data, and fiber channel over Ethernet topology, just because they were standardizing more on blades.

They had already more or less achieved a lot of their cabling reductions, because of the mechanisms they were using within the blades environments. So, they were able to leverage existing cabling infrastructures and didn't have to add anymore. Still, they took advantage of a lot of the cost-reduction features simply by implementing a different computing platform as opposed to going down to the full converged type data center network and storage environment.

Basically, do the analysis to architect and build it out yourself. Then, make use of current generation tools and capabilities, as you do that.

It all depends on what the requirements of the client are. As an integrator, that's our first step -- what are the requirements -- and then matching technology and products to it.

Gardner: John Bennett, we are working towards network transformation. We're certainly seeing a lot of data-center transformation, bringing the two together in a cohesive, organized, perhaps harmonious way -- maybe that's wishful thinking. How do you get started on that? How do you bring these things together, and what are some of the initial steps you expect to see from people to do this successfully?

Bennett: Harmonious is actually something you can expect, and Lin has made note of the HP example here several times. That's definitely a nice outcome to have, and a possible outcome to have.

How do you get started? If you have the capabilities in-house to really do your own networking, architectures, and business process analysis, then take a step back and revisit what you've done in the past. Take a hard look at your networking environment and look at where you need to have the business in the organization running in three to five years. Basically, do the analysis to architect and build it out yourself. Then, make use of current generation tools and capabilities, as you do that.

Clearly, if you are virtualizing your infrastructure and moving in those directions if you want to automate a great deal of the data center environment in the business services you are running, you need to have a clean networking infrastructure as much as you have a clean storage and server environment. The ruthless standardization is foundational for doing that.

If you don't have that experience, if I were a customer, I'd be calling for help, because networking is one of the areas that is most challenging for me personally. Take advantage of a system integrator like HP and their capabilities.

Mapping your strategy

We have people who can come in and not tell you what to do, but work with you to map your business strategy to your IT and your data center strategies, and then look at what you should do over time, in order to change from what you have been to what you can be.

So, if you are self-capable, take a strategic look at it. If you want to take advantage of the experience -- and we have been doing networking since it was created -- take advantage of the experts, someone like HP, and really take that fresh look, and then the implementation and plans after that all follow, but focus on the strategy and the architecture first.

Gardner: Mike Thessen, any rules of thumb that you fall back to, when folks come to you and ask how to get started? What are the first things we need to start doing or thinking about?

Thessen: What we focus on is really developing a good strategy first. Then, we define the requirements that go along with business strategy, perform analysis work against the current situation and the future state requirements, and then develop the solutions specific for the client's particular situation, utilizing perhaps a mix of products and technologies.

Don't look at the data-center network the same way you look at the enterprise network. It is different.

One thing to note here is that HP makes networking product. We make great blade products. We have more or less everything a client would need, if it fits their solution. From our perspective in the Network Solutions Group, we know that HP solutions aren't going to fit in every case. So, we are still one of the largest Cisco worldwide gold partners. We have a vast array of other partnerships in the network space to bring together the right solution for our clients.

Gardner: The last word today goes to you, Lin Nease. Tell me a bit about what your opening salvo is when folks come to you and say, "Wow, an awful lot to think about. How do we put this into a chunk that we can get started on?"

Nease: The advice to the network architect is to look at the portfolio of applications that you are trying to enable. Don't look at the data-center network the same way you look at the enterprise network. It is different. It is specialized. Consider strongly those unique special cases that you handle today as exceptions. Think of how you would handle them more as a mainstream provider.

Be honest with which applications are going in what ways and what demands will be on the network in the future. Also, look to simplify. Always assume that your first step as an architect is to figure out how to simplify what you are trying to accomplish in your data center network design.

Gardner: Very good. I want to thank you all for joining us. We have been on a sponsored podcast discussion today on transforming network architectures in anticipation of evolving demand.

I want to thank our panel. We've been joined by Lin Nease, director of Emerging Technologies, HP ProCurve. Thank you, sir.

Nease: Thank you very much.

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

Bennett: Thank you, Dana.

Gardner: And, Mike Thessen, practice principal, Network Infrastructure Solutions, practice in the HP Network Solutions Group. Great to have you with us, Mike.

Thessen: Thank you, everyone.

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.

Special Offer: Gain insight into best practices for transforming your data center by downloading three new data center transformation whitepapers from HP at www.hp.com/go/dctpodcastwhitepapers.

Transcript of a BriefingsDirect Podcast examining how data-center transformation requires a new and convergent look at enterprise network architecture. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.