Case Study: How Fairchild Semiconductor Has Leveraged the Workday Integration Cloud

Edited transcript of a BriefingsDirect podcast on new forms of cloud-based integration and its use in enterprise business processes.

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 discussion on how new forms of cloud-based integration are helping a major high-tech company build new relationships among and between extended enterprise business processes.

We'll examine how Fairchild Semiconductor has been an early adopter of integration platform as a service (iPaaS). The venerable Silicon Valley company has been using graphical tools to build integrations among and between far-flung applications and services but with those integration platforms housed in a newly unveiled Workday Integration Cloud. [Disclosure: Workday is a sponsor of BriefingsDirect podcasts.]

We’ll learn here from the chief technology officer at Workday on what the integration cloud approach can do and how it points to a future in which broad integration capabilities are increasingly built into software-as-a-service (SaaS) applications.

This cloud-based integration model will prove far less vulnerable to the complexity, fragility and cost that plagues traditional on-premises middleware integration methods. It should also spur the evolution of services ecosystems among multiple business service providers and application providers.

So here to dig into what makes integration as a service (IaaS) tick and what it means for the future is Paul Lones, Senior Vice President for Information Technology at Fairchild Semiconductor. Welcome, Paul.

Paul Lones: Thank you.

Gardner: We’re also here with Stan Swete, the Chief Technology Officer at Workday. Welcome back, Stan.

Stan Swete: Thanks, Dana.

Gardner: Let me start with you, Paul. What's the problem now with integration? Why is this different than a few years ago? Why is it that we need to adopt a different take on integration?

Lones: For companies like Fairchild that are really trying to take advantage of some of the new capabilities that SaaS providers are offering and put together a broader group of applications, integrations are a new challenge, a broader challenge than they have been traditionally.

Gardner: And what is it about what Workday is doing as an application provider that makes this interesting -- the human resource management, the human resource (HR), equation. We’ve seen integrations in some other service orientations, such as in the supply chain side of things. Why was this a challenge?

Custom integration

Lones: Traditionally, in the HR arena, there has been no such thing as a standard integration. Every benefit provider, every payroll service provider that you want to work with requires a custom integration. That’s always been true, and having the set of tools that we now have at our disposal makes that a lot easier.

Gardner: So, in a sense, the HR ecosystem challenge is a really good place to try to perfect or advance iPaaS. Do you agree with that?

Lones: Absolutely.

Gardner: Stan, let's go to you. What needed to change and when you looked at this issue of your ecosystem and how it tied things together, what sort of requirements did you have for integration that now you can pass along to your customers?

Swete: We still look at it as having the same requirements for enterprise integration. Especially for hub systems like human capital management, there are ton of other systems that you have to integrate with. So the requirements are daunting and are still there. It's been the same for a while at enterprise software.

What we see as being a cloud vendor, a SaaS vendor, is just new opportunities to leverage the SaaS model to do integration a little bit differently, have the application vendor take on more of the ownership of the integration issue and use the fact that we've got all of our customers running on a single version of the product to tie some integration logic to that and bring more control and stability to that integration for our customers and our partners.

Gardner: Why is it, Stan, that the traditional systems, platforms, and middleware that are in place are not up to this task? Why not just turn the switch on your on-premises integrations and start tying together these cloud and SaaS based services?

Swete: There's just a split today between the technologies and the platforms that are used to execute integration and convey data and then the application’s endpoints that are involved with and tied up in the logic of that integration.

It's not that no one is up to it, but it's just that that gap splits responsibilities where maybe they don’t have to be split. What we’re trying to do is marry it, use what we know about our applications to create integration logic, and then embed technology that hasn’t been embedded with applications before to help with the delivery of that.

That hasn't replaced every single kind of middleware technology that you need. You still need a middleware technology behind your firewall. You still need specialized middleware technology in the cloud to do things that it does best. But, for the application-centric part of integration, application vendors can do more.

Gardner: Paul, at Fairchild, you've adopted a number of SaaS system approaches or services approaches. One of them is Workday. You have mentioned a few others to me earlier. When you look at your ability to absorb and adopt and exploit more SaaS, how does integration fit into that? Is this something that needs to be solved in order for you to proceed?

Critical enabler

Lones: It's a critical enabler to take advantage of some of the capabilities that we see are available to us and can help us in our business. We look for two things. One, we want to find a supplier that thinks of this in a more holistic ecosystem-like way, and that has a series of application-level partners, that we can add to our overall architecture and overall application capability.

In addition to that, we look for good integration tools, because even beyond those partnerships, we still have to do a lot of integration work.

Gardner: And how long has Fairchild been using Workday for their human capital management activities?

Lones: We've just recently gone live with Workday and several of their partners and have completely transformed our human capital management landscape with Fairchild.

Gardner: When you started to do this, I would think that that involved a number of integration points. Perhaps you could share how that works and then we would like to hear more from Workday about why their Workday Integration Cloud announcement has come to up to the bat to start swinging at this problem.

Lones: Sure. For the Workday partners who I was talking about earlier, those integrations are handled between Workday and their partner, which reduced our integration burden. We don't have to maintain those, as both of those applications continue to improve. In addition to that, we've built 28 application integrations ourselves, largely to benefit service providers and payroll service providers around the world.

Gardner: And you were using your tools or leveraging some of the investments you have made? How did you build those integrations?

Lones: We were fortunate enough that we were able to get some early access to the toolset that Workday is now making available to their broader customer and partner base.

I had a small team of IT staff that was completely unfamiliar with Workday when they first started, and we put them to work on these integrations. We were able to complete these 28 integrations in less than 120 days, which I think was pretty good performance.

Gardner: Just for comparison sake, how long would that perhaps taken in a traditional enterprise application integration (EAI) environment?

Lones: I wouldn't want to necessarily put a date on that. We do know that from an overall project implementation perspective that an on-premises application typically will take 2-3 times as long to execute, and I'd expect that the integration piece would have a similar scaling.

Gardner: Alright. Well, let's dig in a little bit more with the announcement recently that Workday made -- something called the Workday Integration Cloud. Stan, give us the top-down understanding of what this is about.

Important components

Swete: The Workday Integration Cloud is an extension of Workday's cloud that we use to host and process our on-demand applications and it has several really important components. One is a platform component. The tools that Paul mentioned that they used to build integrations, up until today, have been there for Workday developers. The announcement makes these tools fully available to Workday customers and to Workday partners.

In addition to the tools, there is a rich enterprise service bus (ESB) execution environment that runs the results of these developmental tools. We offer not only the tools to build integration systems but the execution environment for the integration systems. And then we've a set of scheduling and monitoring tools that our customers can use to directly schedule and monitor the execution of their integrations.

So those three things taken together form the platform, that's part of the integration cloud. The resulting integration systems we also consider a part of the cloud. Workday for some time has been building what we call Packaged Integrations and Connectors. We have a library of those that we can make available to our customers.

Fairchild has used some of these. These integrations are built with our tooling by us and for our customers. Packaged integrations really just look like another Workday product, but they handle both ends of the integration challenge.

We also have connectors that handle our end of it but build logic out. The main example is a payroll interface product that lets our customers, gives our customers a starting point for hooking up Workday human capital management to the variety of international payrolls many of our larger customers have.

This is very solid ESB technology, well thought of by the engineering talent that we now own.

Packaged integrations from Workday is another component of the Integration Cloud and the final one is just the body of integrations that our customers and partners create.

These are the intellectual property of our customers and our partners. Workday does facilitate sharing of those definitions if the customer and partners are interested, but there is that growing body of application as well. Those things taken together are the Workday Integration Cloud.

Gardner: And just to be clear, this is designed for your customers. This isn't just a general purpose integration service that you are opening up writ large. This is about your ecosystem and your customers, is that right?

Swete: The beauty of it is that it's based on middleware from a company formerly called Cape Clear that Workday acquired three years ago. I think that's very important to mention that. So it's not like we, an apps vendor, just did our take on an ESB. This is very solid ESB technology, well thought of by the engineering talent that we now own.

Built-in integration

We're taking this technology and integrating it into our applications, building integration into our applications as the way we refer to it, and then making the combined product available to both our customers and our partners. The partners are the equally important point. Systems integration partners from Workday can get access to these tools and this platform.

Gardner: And how about the pricing. Is this something that you would just check a box off and get a different bill for? How does this relate to the existing suite of application services you providing?

Swete: The Workday Integration Cloud platform is being made available at no additional cost to Workday customers and Workday partners. We make our money selling our application services.

Gardner: I'm intrigued by this notion of making integration part of the application. I think the history of this, Paul, has been that over the years, new applications and platforms, and even models of computing would come along. You would get great productivity from the application, you would buy and install and master the platform, and then you would be faced with an integration problem.

This is happened over and over again. We've seen it with mainframes to client-server and then into multi-tier and distributing computing and then ultimately with web and now cloud computing.

Companies like ours and many companies working on this are moving from a monolithic internal application orientation to one that's more of a hybrid model.

Given that integration has been a bolt-on, something that's been delivered after they shift in an application model, why now change? Why is integration and the application coming together now?

Lones: Part of it is that our approach to overall enterprise architecture is changing. Companies like ours and many companies working on this are moving from a monolithic internal application orientation to one that's more of a hybrid model, where we want to really take advantage of the new capabilities and the quicker pace of development and deployment of improvements that SaaS providers offer.

Therefore, integrations naturally become a critical part of that, because the number of applications that we use in our business increases somewhat with this sort of approach.

Gardner: Same question to you, Stan. Why this need to bring an application and its integration features together?

Swete: The challenge here is that the requirements in the large problem of integration haven't changed, and there have been a lot of tools developed to address the issue. Some results have been achieved, but I don't think anyone is satisfied with how maintainable enterprise integration is. And, we happened to think the answer is to build more robust integration where the integration definitions themselves are more informed by what exists and what's changing in the application.

Hub system

That's the opportunity that we were seeing. We came on to it by just being the provider of an application that is going to be the hub system and be hooked up to a lot of different systems.

We knew that integration was going to be front and center for us as a brand new SaaS vendor six years ago. One of the differences we wanted to make was to do more about the problem. So, we started with an investment of technology.

Where that has led us is really tying what can get done with integration technology to what applications know about, everything from their security model to, in our case, we leverage a lot the fact that we know about people and how they are organized. So, we're able to have integration definitions that can get routed around for the appropriate approvals before certain steps happen.

That’s unique, but it's breaking down the separation between integration that would be built by one side of the company and tying it back to who it's really serving, the other side of the company.

For payroll integration, the payroll admin can be hooked into the fact that a major feed of HR data is going out to a payroll system and they can get a check on that before it happens. That’s something we’ve built in and we’ll continue to look for those opportunities. I still think it's actually early days for what our integration tools can leverage inside the application.

You still have to have experts on integration middleware and we have that, but the real benefit we think comes from blurring the distinction and marrying these things together.

Gardner: So, the system of record for HR and the governance and policies about employees and their roles in the organization can now be applied pretty seamlessly to who gets to do integrations and/or how integrations as part of a business process would work. Am I reading that right?

Swete: Yeah, how they get executed, how they get approved is all built in to the same sort of system that you use to schedule a report or any other thing you’d do in your application. For us, it's just an extension of the application, rather than a hard line and then some integration technology that no one on the app side understands.

There still are differences. You still have to have experts on integration middleware and we have that, but the real benefit we think comes from blurring the distinction and marrying these things together.

Gardner: So you mentioned some tools and Paul mentioned very compelling timeframe for creating 28 integrations. Who are the people who use these tools typically and are they same old software engineers that were building EAI connections, or is this a wider group of people? Who can take advantage of this tool capability?

Swete: We’ve taken the approach of splitting the development tools into a framework that is more geared for developing simple integrations, as we call them. This is one-way data in or one-way data out of Workday to third-party systems, and we have a tool called the Enterprise Interface Builder (EIB) that is a non-programmer could use. You still need to know that you are sending something to a secure FTP location, but you don’t have to be a developer.

Sets of choices

We give you a graphical user interface, we give you a selected set of choices for how you can source data, a selected set of choices for how you can transform it, and a select set of choices for how you can deliver it. You can save that, and then you have a definition that you can then schedule on a recurring basis. That’s built for non-developers.

The other tool that we have has a completely different personality. It's what we call Workday Studio. This is the developer tool that we have used to build our integrations, and it is now available for our customers. But, on this one, you want to be a developer. You're not doing programming, but you are working in an Eclipse-based framework with detailed control over integration components and orchestration of how data flows. So, this is a technical development tool.

The thing it creates is the same thing that the EIB creates, an integration system that can then be executed in Workday, but the creation of it is much more technical.

Lones: Along those lines, this is really a marriage between having a strong, skilled team of developers with a great tool set. So, it's not a substitute for having well-skilled staff in the IT organization.

Gardner: What about the idea here that integration can be better and newly leveraged because we’ve solved with a SaaS provider’s multitenancy architecture some of these thorny and complex issues about version heterogeneity within the organization?

A lot of times companies might want to update an application, but fear breaking or disrupting integrations. That integration in the traditional sense can become an impediment to the advancement of features and functions in applications.

A lot of times companies might want to update an application, but fear breaking or disrupting integrations. That integration in the traditional sense can become an impediment to the advancement of features and functions in applications.

Paul, did it occur to you that the multitenancy, the fact that everyone is on the same version of this app and that all the integrations follow through by virtue of the responsibility of the vendor, not the user, that that’s sort of added bonus. How have you recognized that and what does it mean to you?

Lones: It's an important part of thinking about the use of SaaS applications in a company like Fairchild. To the extent that it's easy to maintain those integrations through the improvement cycle, we are going to be much more willing to follow a SaaS model, because upgrades come every three or four months, depending on who the supplier is.

We like that model. We'd much rather have a small incremental improvement every three or four months than have this huge disruptive step function upgrade. Really, it typically is more like a reinstallation that occurs for large monolithic installed applications every two or three years. You need to have your integrations keep up, and that's an important consideration.

Gardner: So it's interesting, Stan. You have a user like Fairchild, using these tools, building these integrations, moving more towards a multiparty ecosystem process-oriented benefit, but the responsibility on those integrations is with you.

It seems as if you're really giving an awful lot here. How can you do that with a strong sense of confidence? Isn't there a risk that if these integrations start breaking that you are in the catbird seat?

Levels of the game

Swete: Yeah, well, there are levels of the game for how you can leverage the support you get out of the core application that we keep moving forward. One level of the game is for us that's very important in the integrations we build and sell are ones that can just share the application definitions. So, we support those across all the updates and verify that the logic of those is going to work.

For the integrations tools, we can put smarts into the tools that share how the applications are constructed in that. It gives our customers a leg-up that they can start with these components. Then they can create integrations that are a little bit more impervious to being broken by changes in the applications, because they're sharing metadata back into the applications.

Lots of integrations are built on our application programming interface (API) and so we've got to be rigorous about versioning the API and having a contract to support back versions that gives us a certain amount of insurance. It's not like that with some of these opened in the tools that there couldn't be logic and coding errors that are put in and those are the ones that we would have to encounter together with our customers and we're not going to debug every single one of those.

So, for different levels of the game, more packaged, complete support, on up to the more open-ended integrations, you do what you can to try to make it so the integrations are a little bit more robust than what would have been built with a separate tool set.

Gardner: Paul, it sounds less like a buyer-seller relationship than a partnership. Do you view it that way?

Our experience to date is that companies like ours have more of a voice in the feature improvements of the application.

Lones: We do. Our experience to date, working with providers like Workday and some of the other SaaS providers that we are fortunate enough to do business with, is that companies like ours have more of a voice in the feature improvements of the application.

There tends to be, and certainly it's the case with Workday, a much more active community of clients, users, that are sharing information about everything from somewhat technical to very business process-oriented experiences that all of us have had. That's a very different experience.

In some ways, it's sort of ironic to me that we view it quite a bit more as a partnership. A lot of people perhaps think that it's a SaaS application and, if things don't work out, then when your contract is up, you just go find another SaaS provider.

It is true that there might be a little bit more flexibility, but what we’re finding so far in our experience, and it is early, is that the receptivity and the sense of making improvements together, I think it will actually stick longer than maybe some of the traditional software applications.

Gardner: And just to help our listeners understand the extent of your project with Workday, how many employees were involved? Tell us a little bit about your organization, Fairchild Semiconductor, and your global footprint.

Global base

Lones: Fairchild Semiconductor has roughly 10,000 employees worldwide. We're a semiconductor manufacturing company. We have manufacturing facilities in the United States and throughout Asia. Our customer base is global, our employee base is global. Over 70 percent of our business is in Asia and 70 percent of our employees are in Asia. Having the capability to provide a core HR platform like this to that broad a set of colleagues around the world is really exciting for us, and to be able to support our internal customers and the HR group.

Gardner: And have you brought all of those 10,000 employees up on Workday or has it been a staggered rollout? How has that worked?

Lones: We’re at the very end of our go-live process and we introduced this to our colleagues around the world on April 4.

Gardner: One thing that’s interesting is the degree of integration complexity when you’re dealing with multiple markets. So if you’ve brought all of these employees around the world up on this system -- different payroll, different benefits, different government, different cultures -- how is that issue something you can tackle, given that Workday’s integration was a service to you?

Now, we’re looking forward to doing some additional integrations with some of our local payroll systems.

Lones: Well, we had a lot of payroll integrations. I don’t think we would have gotten those all done in the time frame we did without having that capability that Stan mentioned. In fact, with our legacy system, we actually stopped doing payroll integrations, because they were too hard.

Now, we’re looking forward to doing some additional integrations with some of our local payroll systems to improve that connectivity between our system of record for HR and the payroll service providers that we didn’t build integrations to in the past.

Traditionally, we built integrations only for our large-sized locations. There are smaller-sized locations where we have sales offices, and the like and we typically didn’t build those integrations. We’re going to go back and look at doing that now.

Gardner: Well great. Stan, let's take a look to the future. Where can this go? It seems if this is a proving ground given the number of different integration points, a global organization like Fairchild. I know you’re pointing this at your ecosystem and your customers, but if IaaS works here, couldn’t it potentially work anywhere?

Swete: It could work anywhere but we’ve got a lot to do here. I think that when we look toward the future, there are just several different dimensions where we have to build this up. One is something that Paul has been mentioning -- just the value of the ecosystem and I think we've got a good start, but there is a lot of building we can do there.

That is, we can use the fact that this platform is out there and available and proven to attract more and more partners to it both development partners as well as application partners who can be the other endpoint in integrations that we can support.

So, building out packaged integrations for us to enhance the ecosystem is one aspect. Deepening what the tools are doing is going to be a never-ending task. We’re just starting to have ideas about how to share application’s functionality, and embed that inside the tools to make them more powerful integration tools. I very much look forward to continuing to enhance our toolset and that will benefit the integrations our customers and partners build.

The final aspect is the one you hit on, community. We have to encourage people to want to share these integrations. We didn’t need to do more to automatically support that because our partners are going to be generating these things, as our customers, and in the SaaS community, there is just this great notion about sharing the things you do. So, we see supporting that and we can ultimately see that even leading to selling some of the things you do. All of those are potential features for this space.

Gardner: It seems to me a very extensible model.

Swete: Well, let's hope so. We think we’re just starting.

Gardner: Well great. You’ve been listening to a sponsored BriefingsDirect podcast discussion on how new forms of cloud-based integration are helping Fairchild Semiconductor build new relationships among and between extended enterprise business processes. They're doing that using the Workday Integration Cloud.

I’d like to thank our guests, Paul Lones, Senior Vice President for Information Technology at Fairchild Semiconductor. Thanks, Paul.

Lones: Thank you.

Gardner: And Stan Swete, Chief Technology Officer at Workday. Thanks, Stan.

Swete: Thank you, Dana.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. 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.

Edited transcript of a BriefingsDirect podcast on new forms of cloud-based integration and its use in enterprise business processes. Copyright Interarbor Solutions, LLC, 2005-2011. All rights reserved.

You may also be interested in:

• Delivering Data Analytics Through Workday SaaS ERP Applications Empowers Business Managers at Actual Decision Points
• Workday Integration Cloud debut raises bar on integration as service, deeply ingrains integration as apps function
  
• Executive Interview: Workday's Aneel Bhusri on Advancement of SaaS and Cloud Models for Improved ERP
• Architecture is Destiny: Why the Revolution in Business Interactions Can't Work on Conventional Databases
• HCM SaaS Provider Workday's Advanced Architecture Brings New Business Agility Benefits to Enterprises

Master IT Support Providers Chris and Greg Tinker's Take on How Integrated Technical Support is the Future

Transcript of a podcast discussion on new methods for rapid-response IT support on mission critical applications and systems.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. View the blog.

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you're listening to BriefingsDirect.

Today, we present a podcast discussion on why IT customer support is so important and why industry changes are forcing an integration and empowerment effect for how helpdesks respond and perform.

We're here with two lauded IT Master Technologists from HP to learn more about what makes good customer support tick. Part of the solution comes from providing a more centralized, efficient, and powerful means of getting all the systems involved working, and all the knowledge necessary to come together to quickly get people back in action and keep them there. But, it also involves getting disparate parties and vendors across an IT ecosystem to work together in new ways. [Disclosure: HP is a sponsor of BriefingsDirect podcasts.]

These two technologists, who happen to be identical twins, were chosen via a sweepstakes hosted by HP to identify favorite customer support personnel. We will learn why they gained such recognition and uncover their recommendations for how IT support should be done better now and later in a rapidly changing future of increasingly hybrid and cloud modeled computing.

Please join me now in welcoming our guests. We're here with Chris Tinker and Greg Tinker, both HP Master Technologists. Welcome to you, Chris.

Chris Tinker: Hi, Dana.

Gardner: And also to you, Greg.

Greg Tinker: Thank you, Dana.

Gardner: Let me congratulate you on this award. This was I think a worldwide pool, or at least a very large group of people that you were chosen from. So, congratulations on that.

Greg Tinker: Yes, Dana, thank you very much.

Gardner: Did this come as a surprise? How did you feel when you learned about it?

Greg Tinker: It was an honor, I can say that, and we are very grateful for that. Our customer installed base, as well as our peers and the management team, put our names into this situation. It was a great honor.

Gardner: Yes.

Chris Tinker: And it was a surprise.

Gardner: Just so we could fill this out a bit, in addition to the quiz and sweepstakes, there was a philanthropic element as well. Every time folks voted, a $10 donation was made to CARE, a leading humanitarian organization that fights global poverty. Is that right?

Greg Tinker: That's correct. For each vote that was cast, HP donated $10 to the humanitarian organization Care, to max out at a $100,000. They met that goal in just a few days. It was quite astonishing.

Gardner: Great. Now, it's kind of ironic from my perspective, because I'm thinking that some of the most unpopular people can sometimes be the IT support, because people are in a really difficult situation when they encounter them, but you guys won the popularity contest for an unpopular task. How does that feel?

Greg Tinker: It's definitely an honor. It's our livelihood, but it’s definitely rewarding.

Chris Tinker: Very rewarding.

Their darkest hour

Gardner: You deal with people when they are, in some cases, their darkest hour. They're under pressure. There's something that's gone wrong. They're calling you. So, you're not just there in a technical sense, which of course is important, but there must be a human dynamic to this as well. How does that work?

Chris Tinker: We become their confidant. We foster a relationship there between the two parties. For us, it's very exhilarating. It's the ultimate test. You want to build both the technical and business, but also the interpersonal relationship, because you have to weigh in on so many levels, not just technical. That’s a critical component, but not the only component.

Gardner: Anything to add to that, Greg?

Greg Tinker: No, Chris actually summed it up quite nicely. He and I both have a passion for what we do and we really thrive in the heat of the moment.

He and I both have a passion for what we do and we really thrive in the heat of the moment.

Gardner: All right. So what does it take to be a good IT support person nowadays? Let me start with you Chris?

Chris Tinker: It’s simply not enough to be a technical guru -- not in today's industry. You have to have a good understanding of technology, yes, but you also have to understand the tools and realize that technology is simply a tool for business outcomes. If you're listening to the business, understanding what their concerns and their challenges are, then you can apply that understanding to their technical situation to essentially work for a solution.

Gardner: Greg, how about for you? What do you think makes a good IT support person?

Greg Tinker: I second Chris's sentiment on that, and I'll add this. Chris and I study, almost on a daily basis, to stay ahead of the technology curve. Chris and I both do a lot in SCSI I/O control logic, with respect to the kernel structure of HP-UX as well as Linux, which is our playground, if you will.

And, it takes what I would call firm foundation to be able to provide that strong wealth of knowledge to be the customer's confidant. You can't be an expert at one point anymore. You can't be a network expert only. You have to understand the entire gamut of the business, so that you can understand the customer's technical problem.

Gardner: It's not enough to go to them and say, "Well, that's really not part of our technical expertise. You'll have to go somewhere else." People don't want to hear that. They want that one hand to shake, right?

Greg Tinker: That's correct, and today the customer expects the technical master technologist, like my brother and I, not just to know the one thing they're asking about, because that question is going to quickly turn. For example, I am having an Oracle performance issue, the customer thinks it may be disk related, but when you dig into it, you find out that it's actually an ODBC call, a networking issue. So, you have to be quite proficient at a multitude of technologies and have a lot of depth and breadth.

Gardner: How did you both get involved with this? Did one get into it first and the other follow? What's the story behind how you ended up here?

Lengthy road

Greg Tinker: It was quite a lengthy road. Chris and I actually started off going in one direction, and we agreed many years ago in school that one of us would go one direction and the other in another, and see who was enjoying the industry better. Chris joined HP and fell in love with it. He and I have a very strong Linux background. Then, I jumped ship and went with my brother Chris, and we have been with HP ever since, and have loved it dearly.

Chris Tinker: That's a great point. We look at IT support as a ladder and we just climbed that ladder. We started in mission-critical support and found it to be exhilarating. With mission-critical support you're talking about enterprise-class corporations. We're not talking about consumer products. We're talking about an entire corporation's business running on an IT solution and how we're engaged in that process.

Unfortunately, in our line of work, we do see customers, where the technology did not go as planned, predicted, or expected and it's up to us to essentially figure out what the expectations are with technology and ascertain whether or not the technology can deliver that. That's how we moved through support.

We started off as mission-critical support specialists. We became architects, designing solutions for corporations and found out that we were very good at escalations and that's where we are today.

Gardner: You've mentioned exhilarating a couple of times. Maybe you could provide us a memorable example of why that's the case. Is there some event that you were involved with in this capacity that comes to mind that illustrates that sense of exhilaration? Let me start with you, Greg.

When I talk about exhilarating, we're talking about C-level execs and everybody else staring at you with hands on the keyboard to figure out what's causing this panic situation.

Greg Tinker: Well, I can't give customer names out, but I will stick to one particular incident. It was a dire-strait moment, where a customer deployed a particular non-intrusive patch. They didn't think anything of it, and it actually caused a catastrophic kernel panic inside their infrastructure and shut down their entire enterprise. Once that condition was met, they couldn't boot the enterprise back up, and then it became a pointing game as to what was the fault, was it x, y, or z?

That's when my brother and I got engaged in this to find that one smoking gun that was causing the environment to panic. And, all eyes were on us. When I talk about exhilarating, we're talking about C-level execs and everybody else staring at you with hands on the keyboard to figure out what's causing this panic situation.

That’s where Chris and I really thrive. We were able to isolate the condition in probably about an hour-and-a-half and pull out that component, the offender, and get the enterprise back rolling again.

Chris Tinker: Not to speak light of the customer situation, but it was a fun moment -- and I say fun in air quotes -- because you have the C-level execs standing over your shoulder, literally watching what you are doing. They're sweating because they've been down for so much time. I should state here that it wasn't the HP technology or HP solution that was at fault. It was a third-party interoperability issue that had gone down and caused that interruption.

But, we did isolate it and we did figure out what it was. We talked to that vendor, partnered with them, and got the solution in place in very short order.

Gardner: I imagine that, even though typically these vendors don't always have all of their ducks aligned, when it comes to this sort of a mission-critical situation, they're probably thankful that there's someone there trying to corral this. So, I imagine the cooperation is pretty high in these circumstances.

Stakes are high

Chris Tinker: Yeah, the stakes are high at this level. You are talking about, not only the corporation, the customer, but you are also talking about the vendors, whether it be HP or third party, and we are partnering with all these vendors. Everybody has got a stake in the game. Essentially, their reputation is on the line.

So we partner, regardless. As we don’t want to be thrown under the bus, we don’t throw anybody else under the bus. We partner. We come together as one throat to choke or one hand to shake, however you want to look at it. But, essentially, we all have the same thing in common, the customer’s wellbeing.

Greg Tinker: I'll second Chris’ sentiment on that, in the sense that when we're engaged at our level, it's no longer a finger-pointing game. It's a partnership, regardless of who the customer is. If it's HP gear, so be it. If it's somebody else’s gear, and we see where the problem is at, we don't point the finger. We ask the customer to get their vendor on the bridge with us and we work as a team to get the business restored, because that’s priority one.

Chris Tinker: That’s HP technical support. That’s what we thrive at. That’s one of our charters. Our management has dictated that they want team effort, global effort.

Gardner: I suppose you can always deconstruct fault afterward, and the point is to get people up and running ASAP.

Greg Tinker: That’s right.

Chris Tinker: That’s exactly right. Root cause is a nice to have, business online is better.

Catchphrases change. Today it's cloud computing, but cloud computing has been around for a long time. We just didn’t refer to it as cloud computing.

Gardner: Right. How long have you guys been doing this? How long has this been your profession and your passion?

Chris Tinker: Thirteen years now.

Greg Tinker: Twelve for me.

Gardner: Okay, 12 and 13 years. What's changed over that period of time? It seems as if complexity just keeps rolling higher and higher, with more unintended consequences as a result of that. What would you characterize, Chris, as what's evolved or changed most in the past dozen years or so?

Chris Tinker: Catchphrases change. Today it's cloud computing, but cloud computing has been around for a long time. We just didn’t refer to it as cloud computing. Shared infrastructure of course is what we called it.

Virtualization today is becoming a big ticket item, where in years past, big iron was the thing that was a catchphrase. Big iron was very large computers. We still have big iron in storage, that’s true. We still have that big footprint, big powerhouse, that consumes a lot of power, but that’s a necessity of the storage platform.

The big thing for today is converged infrastructure. These are terms you wouldn’t have heard years ago, where we are trying to converge multiple type of protocols, physical media under one medium, networking, Fibre Channel, which of course is your storage network, TCP/IP network, going across the same physical piece of media. These are things that are changing, and of course with that comes extreme amount of complexity, especially when it comes into the actual engine that drives this.

Gardner: Additional thoughts, Greg? What's changed in your perception?

Big iron

Greg Tinker: As Chris stated, the key phrase of yesteryear was big iron. I want a big behemoth machine that can outdo mainframe. If you look back to 1999 and 2000, what you were looking for in the open system world was something to compete with Big Blue.

Today it's virtualization and blades. Everybody used to say -- probably about mid-2005 -- "I want a pizza box. I want a new blade." We no longer call those blades. Those are called pizza boxes now. Today, the concept is all about blades. If you can't make the thing 3 inches tall and 1 inch wide, there is something wrong.

Gardner: You've been describing how things have changed technically. How have things changed in terms of the customer requirements and/or the customer culture? That is to say, what are their expectations or perceptions? Let's start with you Chris.

Chris Tinker: Expectation is more for less. They want more computing power. They want more IT for less cost, which I think that’s been true since day one, but today, of course, that "more for less" just means more computing power. The footprint of the servers has changed.

And two, the support model has changed. Keep in mind, we're in support, and we're seeing a trend with these concepts where customers are having all these physical servers and the support contracts on all these servers are being consolidated down to one physical server with virtual instances.

The support model of yesteryear doesn’t always fit the support model that they should have today.

The support model of yesteryear doesn’t always fit the support model that they should have today.

Greg Tinker: What Chris is talking about there is consolidation efforts. Customers used to have 500 servers. Today, -- I want to exaggerate my point here -- we have it on a virtualization of one or two physical machines that are behemoth and it's virtualized 500 guests.

Though that model works right for consolidating the cost effort of the infrastructure, so your capital cost is less, the problem now becomes the support model. Customers tend to reduce the support as well, because it's less infrastructure. But, keep in mind, most customers kind of forget a lot of times that they've put all their eggs into the basket and that basket needs a lot of protection.

So now you have your entire enterprise running on one or two pieces of physical hardware that is a grossly complex with not only the virtual servers, but the virtual Ethernet modules, the Fibre Channel model concepts are all now basically one concept to run every protocol type, whether you are running infiniband, Gigabit Ethernet, Fibre Channel, etc., the complexity requires a great deal of support.

When a customer calls up and says, "We've made a change in our environment and my server has crashed, the physical server went down, or has lost access to its storage or network," you're not just affecting that one physical server, but you're affecting hundreds. So, the support model today is quick.

Chris Tinker: To add to Greg’s point, a compartmentalization of yesteryear was, "I have physical servers in racks and I will go to another row with a different rack. It has more servers there." So, your compartmentalization, your isolated zones, were in the physical data center, where today your isolated compartmentalized zones are within the same chassis.

Gardner: It sounds to me that there is a higher risk profile. Is that a fair characterization?

Hardware redundancy

Greg Tinker: That would be a fair characterization. There is a higher risk on the hardware end in the sense that you still have hardware redundancy, of course, but you're fully dependent upon cluster technology and complexity.

Let's talk about the chassis. The chassis concept of our blade infrastructure, and this is true for most vendors, is that you are redundant there. But, if you want to be redundant at the hardware layer, you've got to have yet another chassis. In order to get that redundancy across the chassis components, you have to have a virtualization software on top of it, adding more complexity, which becomes a real need for a powerful support base.

Chris Tinker: A good solution design for business risk assessments are still a critical component to your solution design.

Gardner: I'm going to guess that over the past several years in the tradeoff for cost and risk, people probably favor the cost side a bit. So, that means the people in your position are the backstop. "I'll assume more risk and I'll have some cost benefits, but in order for me to survive, I'm going to need a more capable IT support function." Is that a fair assessment?

The new light today is that customers are focused more on the higher end support models, meaning four-hour call to repair.

Greg Tinker: That’s what the trend is becoming. The trend is, "We're going to reduce our cost in the CAPEX and reduce our cost in the infrastructure. We're going to consolidate and virtualize that concept, and we are going to look at our support strategy in a different light." That’s what most customers think.

Gardner: What is that new light?

Greg Tinker: The new light today is that customers are focused more on the higher end support models, meaning four-hour call to repair, where it used to be 24-hour or 48-hour support models, where we were not in a huge rush. If we had a disk drive failure, we had plenty of time, because we had full redundancy, whatever. So we had plenty of time to fix those components.

Today, with all this consolidation effort, it becomes a real critical need when you have a failing component, whether it be hardware or software, to get that component addressed urgently. You don’t really have the time.

Chris Tinker: That’s a great point. Looking at that standard support model, you had so many physical servers and your business was essentially interlaced with these systems. You could handle an outage, whether software or hardware condition. It wasn't as strategic or as strong as today’s virtualized environments, where you would have much heavier business impact.

To Greg’s point, this inter-support model used to work with some of these virtualized environments. I am not saying all virtualized environments, but some of these virtualized environments. With four-hour call-to-repair, you can imagine in four hours what’s required. The technologists who answer the phone first have to address the business concerns to figure out what the business impact is and understand what the problem is.

Once we ascertain what’s causing that problem and the problem has been defined, we have to figure out what’s going wrong with the technology in order to bring it back online.

Business assessment

All that has to be done within four hours on some of our most critical contracts. Of course, that’s the most advanced contract. There are many stages between that one and all the way down to standard support. There are all levels in between, and that customized support model has to be a business assessment.

Gardner: So, we have these trends around increased complexity, reduced time to repair or meantime to emulate your issues. We also have a higher level of concentration of risk and an impetus to cut cost, and you guys are dropped in the middle of that.

What does this mean for your role? It sounds like you need to be good technically. You need to be almost Professional Services as well as helpdesk and support. You need to have those good interpersonal skills, a background in architecture, a background in a variety of different technologies. Help me understand what it is that you think comes together that allow somebody to do what you do?

Greg Tinker: I think the biggest thing I would say is having strong technical background. Having in-depth knowledge of C is a good idea, knowing the kernel structure. That way when you have a failure in a component, software or hardware, you have a clear understanding in the stack as to where the problem most likely resides. You need to have a good idea of where to focus.

"I'm having a set-sock-opt error in the TCP protocol stack." You know you don’t have to look at the Fibre Channel stack. Granted, I'm making that way too simple on purpose. My point is that you have to have a very clear understanding of where the stuff resides.

The very first thing you do is not start looking at logs. You start listening to the customer’s problem and having that relationship

Chris Tinker: It's having an understanding of the actual layers, and in computer technology it's understanding all about the layers of the technology, whether it be the hardware layer or the upper layer stack. If they describe a problem to you as X, it's being able to understand where would that fall, what layer would that fall in. And, that’s going to expedite your ability to troubleshoot that problem.

But, to Greg’s point, that goes back to listening -- listening to the problem, listening to the customer's situation. The very first thing you do is not start looking at logs. You start listening to the customer’s problem and having that relationship. One of the key components here is ownership, letting the customer know that I am engaged now, I own this, I'll work with you, and we will get this solved. That gives them the confidence and the reassurance that there is somebody that’s going to work with them. That’s what HP Technical Support is all about -- having that ownership.

Gardner: There have also been some shifts over the past dozen years or so in the degree to which remote support is possible and your ability to get inside and get that information. Maybe we could take a moment to learn more about what tools have been brought to bear to help you with this, when you get that phone call. When you're dealing with that customer in their moment of need, their darkest hour, you also have a bit more of an arsenal. You have some arrows in your quiver. Maybe you could explain what you think are the most powerful ones and why they work well.

HP virtual room

Chris Tinker: The HP Virtual Room (HPVR). If you go to rooms.hp.com, it’s a good example. As you just mentioned, yesteryear it was, "Hey, send me the logs. Send me the examples. Send me some data, and I'll parse through it and figure it out." You had to wait for data to come in and then start parsing those logs, parsing that data, and building your hypothesis of what might be the problem.

Now, imagine if I were able to take that in real time. So, Greg, talk about real time.

Greg Tinker: Real time is key in today’s technology world. Nobody wants to wait. Take your phone for example. Can you stand it when you have pressed the email button and your phone takes more than three seconds to load it up? Everybody gets annoyed when it's slow. Well, the same is true in technology services support.

When customers call in, they expect immediate response. By the time it gets to our level, where Chris and I sit and our team resides inside the support model, the customer is in dire straits. We use the Virtual Room technology. It's similar to WebEx.

There are a lot of similarities out there. Different vendors have different tools. We use the HP Virtual Room toolset and we can jump onto any machine in the world, anywhere in the world, at a moment’s notice. We can do crash analysis on a Linux kernel crash in real time on a customer’s machine. The same with HP-UX, Solaris, AIX, name your favorite.

We can look at these stack traces and actually find the most likely component that compromises the infrastructure. We can find it, isolate it, and remedy it.

We can look at these stack traces and actually find the most likely component that compromises the infrastructure. We can find it, isolate it, and remedy it.

Chris Tinker: Not only is it just us troubleshooting, but it's bringing to bear our peers. It's team work, a two-heads-are-better-than-one mentality. Greg even lived that first. At the end of the day, you've got 2, 4, or 20 people on the phone. You can imagine all of those people sharing the same desktop at the same time to try to look at a problem. You get all these different levels of expertise.

You're able to take all these talents and focus them on one scenario. So, now with four-hour call to repair, how is that even possible? It's possible when we have to bring these people and partner with these people. They could be not only HP employees and HP technical support. That goes back to vendors and those relationships. We bring those vendors into the same Virtual Room, showing them where we're seeing the problem and asking what we need to do to solve this.

Gardner: That puts you in the role of being the conductor in an orchestra in a sense. That’s another skill set as well, getting that leadership and the ability to get people to line up and focus on a common problem. Does that come up more nowadays?

Chris Tinker: We have many hats to wear. It goes back to our prior point that being a technical guru is not the only critical component to being able to execute at this level.

Greg Tinker: It's knowing one’s limitations. As powerful as Chris and I are in the technology world, we have limitations like anyone would. That’s why it's a team effort. Using tools like the Virtual Room, we can look at a situation and have a good idea of where the problem may be.

Leadership role

If we don’t have that skill set, in a moment’s notice we can get one of our team members to jump into the room with us, look at the desktop, look at the situation, and assess it with us. So, it's a leadership role that we hold in our organization, in the massive technology world of HP, to go out and grab those experts that you need and bring them to bear to the situation.

Chris Tinker: Dana, to your point, it's not enough just to know the technology that you're responsible for supporting. For example, you’re tasked with having to know third-party vendor technology, but you are also tasked with having to understand the technologies like HP Virtual Room.

For example, Greg mentioned WebEx, there are many technologies out there, tools that we use that HP doesn’t create and doesn’t support, but the industry as a whole utilizes on a daily basis. I'm sure you're using one right now that’s either a freeware or a public license.

Greg Tinker: Take Outlook for example. That’s a tool. Today, everybody is expected to know Outlook. If you find someone that doesn't know it, you then question their ability. Everybody would. I'm using that as an example, but a lot of people take these types of tools we use today for granted.

Gardner: While we are on the subject of tools, what's coming next? If I were to design these types of tools, you would be the guys I would go to, to get my list of requirements. What are you asking for? What would you like to see come next in order for you to be able to do your jobs better?

The hard one to fix is "My application is not running the way I want it to, Fix it."

Chris Tinker: The mind meld or The Borg.

Gardner: Reading minds, that’s a good one. More practical.

Greg Tinker: Now, there are some tools that are being leveraged daily inside HP as well as outside. HP Storage Essentials being one. The biggest thing we see today is storage. The growth rate of storage is enormous. And the biggest problems customers run into are performance and capacity.

Capacity is the easy one, right? I am 100 percent full in my file system. I just need more. That's the easy one to fix.

The hard one to fix is "My application is not running the way I want it to, Fix it." Those are the difficult ones. We have to have a lot of tools to help us understand what the load conditions are, because it's no longer the yesteryear scenario of a Superdome, HP Rack, one big behemoth machine, four terabytes of memory, 400 CPUs, loading up one storage array. That's no longer the case.

We have grid computing structures of 600+ nodes running a multitude of different things -- SAP, Oracle, Informix, Exchange, etc. All of these different load-bearing concepts are coming into one monolithic storage array. It can become quite daunting to understand what's causing that load condition, and we have a lot of tools today that are helping us ascertain the root of those problems faster.

Chris Tinker: We have become the bleeding edge of technology. Essentially, it's software that hasn't been released. It's tools which are not actually production ready, and we use these tools as well, and some tools we can’t even speak about.

Business realities

But, these are tools that will be in the enterprise eventually. They will be out in the world eventually. You asked earlier what we see coming down the road? Imagination is essentially one of the only things in technology. In today's world, there are other factors of course. Business realities temper the development of technology, but it's going to be very exciting to see what technology is being developed and what's coming next.

Gardner: While we're looking at what's coming next, you mentioned that level of interest in applications not performing, a very general sort of problem at the surface. It seems to me that the definition of application is shifting. As we look at more hybrid computing models, we look at people who will be compositing from a variety of services, all perhaps coming from a variety of sources. The business process needs to be supported, but the constituent parts now are even more scattered, harder to identify.

It seems as if folks who are in your role are going to have an even more important play here when it comes to these distributed and cloud and hybrid types of applications. Any thought about what you would be needing and what to expect if that's the future?

Chris Tinker: Well, with performance, your key challenge is understanding what tools we use, what metrics we look at. With databases, there are databases tools like AWR with Oracle. When should I be looking at AWR, as opposed to the operating system performance metrics, as opposed to the storage array or network performance?

It's having this very large breadth of technology expertise. It's being able to understand first what tool I use to look at performance.

It goes back to what Greg said earlier. It's having this very large breadth of technology expertise. It's being able to understand first what tool I use to look at performance. Then, of course, you have to go back to the business. You have to ask the business owners, the P&L owners, "What is your expectation? What is actually your business challenge?"

Maybe it's a batch job. Maybe it's a report they want to run at month end. Maybe they want to run a month-end processing for their business accounting, calculate payroll.The business has to be able to define what it is they are going after. Their challenge is being able to align the technology to deliver on that challenge.

Gardner: I wonder if you might have just some last advice for those listening to the podcast as to how they on the consumption side might help folks like you on the services and support delivery side do your job better? What advice do you have for them in order to have a better outcome? Any thoughts on that, Chris?

Chris Tinker: Yeah, it's being able to articulate the actual problem at hand, and the challenge that you have with your technology, because keep in mind that technology, IT, is nothing more than a tool that allows us to have business outcomes. So it's nothing more than a tool that the business utilizes for their requirements.

Then, to have metrics around their environment. They have to have a baseline. They have to have an understanding of what the technology has been doing.

Trending is key

Greg Tinker: Trending is key in a lot of these new virtualized consolidated environments. You need to have a baseline, as Chris stated. We need to have the performance characteristics. Your logging and ESX is about as common as sliced bread in a grocery store. ESX environments are very common and thought of very highly. I enjoy them. They are very nice.

Customers tend to start moving towards ESXi, which is fine, but ESXi doesn't log. It does log but you only get like a two hour history. The point is that customers take that logging for granted. You have to have your logging enabled and you must keep at least a six month trend.

So you don't keep all your logs and your service forever, but a six month trend is very helpful when you have a mysterious problem show up. Then, we can compare yesterday to today and see what differences have shown up in the environment.

Gardner: It comes down to data, having the data at your disposal.

Chris Tinker: Not just data, but having a baseline. We get a lot of calls where customers have no idea of what the environment was doing before. They say, "We're having a problem now. Our users are complaining." We ask, "How did it used to run? How long did this job used to take? Did it use to take 2 hours, and now it takes 20 hours?" A lot of times, they simply do not know.

I wish customers would yield to knowing that logging is critical. You don't have to keep it forever, but keep it for a strategic period of time. Six months is a good number.

I wish customers would yield to knowing that logging is critical. You don't have to keep it forever, but keep it for a strategic period of time. Six months is a good number.

Gardner: So as we look at the benefits from a cost and performance angle of concentrating and converging, you might increase your risk profile and become more dependent on folks like Chris and Greg, but having that data and having an understanding of your baseline can help reduce that risk significantly. That's good advice.

Terrific. I want to thank you two for your input and, again, congratulations on being designated favorites at something that's probably, as I say, not a popular role. So to be popular in an unpopular position really speaks well of you.

We've been listening to a podcast discussion on how IT customer support is growing in importance and why the industry changes are flipped, forcing more work towards reducing that risk, but with an emphasis on the people at the front line on your support services.

So thanks to Chris Tinker. I really enjoyed your thoughts.

Chris Tinker: Thank you, Dana.

Greg Tinker: Dana, thank you again for having us. I would like to add one more comment. For those of your listeners that are willing to come out to the HP DISCOVER Event in Las Vegas, Chris and I have multiple publications and we are giving multiple advanced session discussions on internal I/O control logics at HP DISCOVER Event in Las Vegas, June 6-10. So, if any of your listeners wish to come out and meet us firsthand, we would love to see them.

HP also has a site where you can connect with HP Technology Services experts. We encourage your readers to engage with HP directly.

Gardner: Thanks to you Greg. We have been, as I say, discussing the support life and the trends, and both of you gentlemen are HP Master Technologists. So thanks again.

Greg Tinker: Thank you so much.

Chris Tinker: Thank you.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. I've been your host and moderator and you've been listening to a 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. View the blog.

Transcript of a podcast discussion on new methods for rapid-response IT support on mission critical applications and systems. Copyright Interarbor Solutions, LLC, 2005-2011. All rights reserved.

You may also be interested in:

• HP Premier Services Closes Gap Between Single Point of Accountability and Software Sprawl
• HP's Kevin Bury on How Cloud and SaaS Will Help Pave the Way to Increased Efficiency in IT Budgets for 2011 and beyond
• HP's Instant-On Enterprise Takes Aim at Shifting Needs of Business and Government

Tag-Team of HP Workshops Provides Essential Path to IT Maturity Assessment and a Data Center Transformation Journey

Transcript of a sponsored podcast discussion on two HP workshops that help businesses determine actual IT needs and provide a roadmap for improving data center operations and efficiency.

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

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 some fast-moving trends by addressing the need for data center transformation (DCT). We'll also identify some proven ways that explore how to do DCT effectively.

The pace of change, degrees of complexity, and explosion around the uses of new devices and increased data sources are placing new requirements and new strain on older data centers. Research shows that a majority of enterprises are either planning for or are in the midst of data center improvements and expansions.

Deciding how to best improve your data center however is not an easy equation. Those building new data centers need to contend with architectural shifts to cloud and hybrid infrastructure models, as well as the need to cut total cost and reduce energy consumption for the long-term.

An added requirement for new data centers is to satisfy the needs of both short-and long-term goals, by effectively jibing the need for agility now with facility decisions that may well impact the company for 20 years or more.

We are going to examine two ongoing HP workshops as a means for better understanding DCT and for accurately assessing a company’s maturity in order to know how to begin a DCT journey and where it should end up.

We're here with rather three HP experts on the Data Center Transformation Experience Workshop and the Converged Infrastructure Maturity Model Workshop. Please join me now in welcoming Helen Tang, Solutions Lead for Data Center Transformation and Converged Infrastructure Solution for HP Enterprise Business. Welcome, Helen.

Helen Tang: Thanks, Dana.

Gardner: We're also here with Mark Edelmann, Senior Program Manager at HP’s Enterprise Storage, Servers, and Network Business Unit. Welcome, Mark.

Mark Edelmann: Thank you, Dana. Good to be here.

Gardner: And also Mark Grindle, Business Consultant for Data Center Infrastructure Services and Technology Services in HP Enterprise Business. Welcome, Mark.

Mark Grindle: Hi, Dana. Thanks a lot.

Gardner: Helen, as I mentioned, this is a very difficult situation for organizations. Lots of conflicting data is coming in, and many changes, many different trends are impacting this. Why don’t we try to set the stage a little bit for why DCT is so important, but also why it's no easy task.

Exciting times

Tang: Absolutely, Dana. As you said, there are a lot of difficulties for technology, but also if you look at the big picture, we live in extremely exciting times. We have rapidly changing and evolving business models, new technology advances like cloud, and a rapidly changing workforce.

What the world is demanding is essentially instant gratification. You can call it sort of an instant-on world, a world where everything is mobile, everybody is connected, interactive, and things just move very immediately and fluidly. All your customers and constituents want their need satisfied today, in an instant, as opposed to days or weeks. So, it takes a special kind of enterprise to do just that and compete in this world.

You need to be able to serve all of these customers, employees, partners, and citizens -- 0r if you happen to be a government organization -- with whatever they want or need instantly, any point, any time, through any channel. This is what HP is calling the Instant-On Enterprise, and we think it's the new imperative.

Gardner: When you say instant-on, it means that companies have to respond to their customers at almost lightning speed, but we are talking about infrastructures that can take years to build out. How do you jibe the two, the need to be instant, in terms of how you respond, but recognizing that this is a very difficult, complex, and timely process?

Tang: Therein lies the challenge. Your organization is demanding ever more from IT -- more innovation, faster time to market, more services -- but at the same time, you're being constrained by older architectures, inflexible siloed infrastructure that you may have inherited over the years. How do you deliver this new level of agility and be able to meet those needs?

You have to take a transformational approach and look at things like converged infrastructure as a foundation for moving your current data center to a future state that’s able to support all of this growth, with virtualized resource pools, integrated automated processes across the data center, with an energy-efficient future-proofed physical data center design, that’s able to flex and meet these needs.

Gardner: Of course, one of the larger trends too is that technology is just more important to more companies in more ways. This is not something you do just to support your employees. It really is core to most companies in how they actually conduct business, and is probably one of the chief determinants of their success.

So doing DCT is really part and parcel with how well you actually run your business -- or am I overstating it?

Tang: That’s absolutely true. We talked earlier about how being an Instant-On Enterprise is an imperative. Why do we call it that? Well, because these vast changes are coming, and you don’t have a choice.

If you look at just a few examples of some of these changes in the world of IT, number one is devices. I think you mentioned this earlier. There’s an explosion of devices being used: smartphones, laptops, TouchPads, PDAs. According to the Gartner Group, by 2014, that’s less than three years, 90 percent of organizations will need to support their corporate applications on personal devices. Is IT ready for that? Not by a long shot today.

Architecture shifts

Another trend that we see is some of these architecture shifts. Cloud obviously is very hot today, but two or three years ago a lot of CIOs pooh-poohed the idea and said, "Oh, that’s not real. That’s just hype." Well, the trend is really upon us.

Another Gartner stat: in the next four years, 43 percent of CIOs will have the majority of their IT infrastructure and organizations and apps running in the cloud or in some sort of software-as-a-service (SaaS) technology. Most organizations aren’t equipped to deal with that.

Last but not least, look at your workforce. In less than 10 years about half of the workforce will be millennials, which is defined as people born between the year of 1981 and 2000 -- the first generation to come of age in the new millennium. This is a Forrester statistic.

This younger generation grew up with the Internet. They work and communicate very differently from the workforce of today and they will be a main constituency for IT in less than 10 years. That’s going to force all of us to adjust to different types of support expectations, different user experiences, and governance.

Maturity is a psychological term used to indicate how a person responds to the circumstances or environment in an appropriate and adaptive manner.

Gardner: So, as we recognize that the workloads, the requirements placed on IT are shifting, the data center needs to respond to that as well. I guess it’s important to know where you are, how well you have done in adjusting to what you have been serving up in the last several years in order to know what you need to do in order to be able to provide for these new requirements that we are describing.

Let’s start talking about one of these first workshops. It’s about the Maturity Model, a better understanding of where you are. I guess there is an order to these workshops. This one seems to be in the right order. You have to know where you are before you can decide where to go.

So let’s move to Mark Edelmann. Tell me a little bit about the Converged Infrastructure Maturity Model and why it’s important, as I said, to know where you are before you start charting the course in any detail to the future.

Edelmann: Before we dive into the maturity model though, I recently bumped into a definition on Wikipedia about maturity and I thought it might be useful to consider your IT environment as you listen to this definition that I picked up.

"Maturity is a psychological term used to indicate how a person responds to the circumstances or environment in an appropriate and adaptive manner. The response is generally learned rather than instinctive and is not determined by one’s age. Maturity also encompasses being aware of the correct time and place to behave and knowing when to act appropriately according to the situation."

Now, that probably sounds a little bit like what you might want your infrastructure to behave like and to actually achieve a level of maturity, and that’s exactly what the Maturity Model Workshop is all about.

Overall assessment

The Maturity Model consists of an overall assessment, and it’s a very objective assessment. It’s based on roughly 60 questions that we go through to specifically address the various dimensions, or as we call them domains, of the maturity of an IT infrastructure.

We apply these questions in a consultative, interactive way with our customers, because some of the discussions can get very, very detailed. Asking these questions of many of our customers that have participated in these workshops has been a new experience. We're going to ask our customers things that they probably never thought about before or have only thought of in a very brief sort of a way, but it’s important to get to the bottom of some of these issues.

As a result of examining the infrastructure’s maturity along these lines, we're able to establish a baseline of the maturity of the infrastructure today. And, in the course of interviewing and discussing this with our customers, we also identify where they would like to be in terms of their maturity in the future. From that, we can put together a plan of how to get from here to there.

Gardner: When you say a workshop, are these set up so that people physically go there and you have them in different places, or is there a virtual version where people can participate regardless of where they are? How does that work?

Edelmann: We've found it’s much more valuable to sit down face to face with the customer and go through this, and it actually requires an investment of time. There’s a lot of background information that has to be gathered and so forth, and it seems best if we're face to face as we go through this and have the discussion that’s necessary to really tease out all the details.

The impact of mergers and acquisitions has kind of forced some customers to put together different technologies, different platforms, using different vendors.

Gardner: I'd like to understand a little bit more, Mark, why you break out maturity versus installed base. Help me understand what it takes in order to succeed and what you typically find with these companies? Do they find that they are further ahead than they thought or further behind when we look at this through that distinct lens of maturity?

Edelmann: Most of our customers find out that they are a lot further behind than they thought they were. It's not necessarily due to any fault on their part, but possibly a result of aging infrastructure, because of the economic situation we have been in, disparate siloed infrastructure as a result of building out application focused stacks, which was kind of the way we approached IT historically.

Also, the impact of mergers and acquisitions has kind of forced some customers to put together different technologies, different platforms, using different vendors and so forth. Rationalizing all that can leave them in kind of a disparate sort of a state. So, they usually find that they are a lot further behind than they thought.

Gardner: And, because you've been doing this for quite some time and you've been doing it around the world, you have a pretty good set of data. You have some good historical trend lines to examine, so you have certain domains and certain stages of maturity that you have been able to identify.

Maybe you could help us understand what those are and then relate how folks can then place themselves on those lines, not only to know where they are, but have a sense of how far it is they need to go to get to that higher level of maturity they're seeking.

Edelmann: Sure. We can talk through that level of detail and you can familiarize yourself, at least verbally, with how this model is set up and so forth.

4x5 matrix

Picture, if you will, a 4x5 matrix. We examine the customer’s infrastructure in four, what we call, domains. These domains consist of technology and architecture, management tools and processes, the culture and IT staff, and the demand, supply, and IT governance aspects of the infrastructure and the data center operations. Those are the four domains in which we ask these questions and make our assessment.

From that, as we go through this, through some very detailed analysis that we have done over the years, we're able to position the customer’s infrastructure in one of five stages:

• The first stage, which is where most people start, is in Stage 1; we call that Compartmentalized and Legacy, which is rather essentially the least-mature stage.
• From there we move to Stage 2, which we call Standardized.
• Stage 3 then is Optimized.
• Stage 4 gets us into Automated and a Service-Oriented Architecture (SOA), and,
  
• Stage 5 is more or less IT utopia necessary to become the Instant-On Enterprise that Helen just talked about. We called that Adaptively Sourced Infrastructure.

We evaluate each domain under several conditions against those five stages and we essentially wind up with a baseline of where the customer stands.

We've been doing this for a while and we've done a lot of examinations across the world and across various industries. We have a database of roughly 1,400 customers that we then compare the customer’s maturity to. So, the customer can determine where they stand with regards to the overall norms of IT infrastructures.

It's a difficult and a long journey to get to that level, but there are ways to get there, and that’s what we're here for.

We can also illustrate to the customer what the best-in-class behavior is, because right now, there aren’t a whole lot of infrastructures that are up at Stage 5. It's a difficult and a long journey to get to that level, but there are ways to get there, and that’s what we're here for.

Gardner: I want to make sure I've got this straight in terms of the order of these workshops and why how they play off of one another. Maybe, Helen, you could come back in and help understand which one you see people doing first and which one you think is the one that makes the more sense?

Tang: Both workshops are great. It's not really an either/or. I would start with the Data Center Transformation Experience Workshop, because that sets the scene in the background of how I start to approach this problem. What do I think about? What are the key areas of consideration? And, it maps out a strategy on a grander scale.

The CI Maturity Model Assessment specifically gets into when you think about implementation. Let's dive in and really drill deep into your current state versus future state when it comes to these five domains that Mark just described.

Gardner: Let's go now to the Data Center Transformation Experience Workshop with Mark Grindle. First, do you share Helen’s perspective on the order, and what would people gain by entering into the Data Center Transformation Experience Workshop first? Then, you can then fill us in a little bit on what it's about?

Interesting workshop

Grindle: Thanks, Dana. I agree with what Helen said. It really is more structured if you do the Data Center Transformation Experience Workshop first and then follow that up with the Maturity Model. It's very interesting workshop, because it's very different from any other workshop, at least that I have ever participated in. It's not theoretical and it's also extremely interactive.

It was originally designed and set up based on HP IT’s internal transformation. So, it's based on exactly what we went through to accomplish all the great things that we did, and we've continued to refine and improve it based on our customer experiences too. So, it's a great representation of our internal experiences as well as what customers and other businesses and other industries are going through.

During the process, we walk the customer through everything that we've learned, a lot of best practices, a lot of our experiences, and it's extremely interactive.

Then, as we go through each one of our dimensions, or each one of the panels, we probe with the customer to discuss what resonates well with them, where they think they are in certain areas, and it's a very interactive dialog of what we've learned and know and what they've learned and know and what they want to achieve.

The outcome is typically a very robust document and conversation around how the customer should proceed with their own transformation, how they should sequence it, what their priorities are, and true deliverables -- here are the tasks you need to take on and accomplish -- either with our help or on their own.

It’s a great way of developing a roadmap, a strategy, and an initial plan on how to go forward with their own transformational efforts.

It’s a great way of developing a roadmap, a strategy, and an initial plan on how to go forward with their own transformational efforts.

Gardner: And the same question to you, Mark Grindle, about location. Is this something you prefer to do face to face as Mark Edelmann mentioned, or is this something that people can gather virtually or through road shows? How does it actually come to the market?

Grindle: It absolutely has to be face-to-face. We use a very large conference room and we set up these panels around the room. Each one of these panels is floor to ceiling and height. There are about 4 feet by 5, or 5.5 feet high, and we walk through a series of 10 panels that approaches each of the dimensions of transformation, as we look at it.

So having all the people in the room and being able to be interactive face to face, as well as reference panels that you might have gone through or that you are about to go through as different points in the conversation come up, is critical to having a successful workshop.

Designed around strategy

It's definitely designed around strategy. Most people, when they look at transformation, think about their data centers, their servers, and somewhat their storage, but really the goal of our workshop is to help them understand, in a much more holistic view, that it's not just about that typical infrastructure. It has to do with program management, governance, the dramatic organizational change that goes on if you go through transformation.

Applications, the data, the business outcomes, all of this has to be tied in to to ensure that, at end of the day, you've implemented a very cost-effective solution that meets the needs of the businesses. That really is a game-changing type of move by your organization.

Gardner: And, as part of some of the trends we mentioned, building these for the long-term means that you're building for operational efficiency. The total cost, of course, over time is going to be that ongoing operational penalty or, if you do it right, perhaps payback. How do you help people appreciate the economics of the data center, and how important is that to people in these workshops?

Grindle: The financials are absolutely critical. There are very few businesses today that aren’t extremely focused on their bottom line and how they can reduce the operational cost.

Certainly, from the HP IT experience, we can show, although it's not a trivial investment to make this all happen, the returns are not only normally a lot larger than your investment, but they are year-over-year savings. That’s money that typically can be redeployed to areas that really impact the business, whether it's through manufacturing, marketing, or sales. This is money that can be reinvested in the business, and allowed to help grow the areas that really will have future impact on the growth of the business, while reducing the cost of your data centers and your operation.

Even though you're driving down the cost of your IT organization, you're not giving up quality and you are not giving up technology.

Interestingly enough, what we find is that, even though you're driving down the cost of your IT organization, you're not giving up quality and you are not giving up technology. You actually have to implement new technologies and robust technologies to help bring your cost down. Things like automations, operational efficiency, ITIL processes all help you drive the saving while you are allowed to upgrade your systems and your environments to current technologies and new technologies.

And, while we're on the topic of cost savings, a lot of times when we are talking to customer about transformation, it's normally being driven by some critical IT imperative, like they're out of space in their data center and they're about to look at building out a new data center or perhaps a obtaining a collocation site. A lot of times we find that we sit down and talk with them about how they can modernize their application, tier their storage, go with higher density equipment, virtualize their servers, they actually can free up space and avoid that major investment of the new data center.

Gardner: That gets back to the definition of maturity, where it might not necessarily mean bringing in trucks and pouring cement. It could very well mean transforming in a way that ekes out more productivity from your existing facilities before you rush into something new. Is that typically the case? How often does that really happen where you can wring out enough efficiency to postpone the actual new facility?

Grindle: It happens time and time again. I am working with a company right now that was looking at going to eight data centers and by implementing a lot of these new technologies -- higher virtualization rates, improvements to their applications, and better management of their data on their storage. We're trying to get them down into two data centers. So right there is a substantial change. And, that’s just an example of things that I have seen time and time again, as we've done these workshops.

A big part of this is working through what the customer really needs and what their business drivers really are. In some cases, we're finding out that brick and mortar aren’t really the right solutions for their data centers. They should look at collocation or even at more creative solutions like the HP Data Center POD, where you can stand up one of these containers filled with high density, very modern equipment, and meet all their needs without doing anything to your existing data center.

It's all about walking through the problems and the issues that are at hand and figuring out what the right answers are to meet their needs, while trying to control the expense.

What's next?

Gardner: Okay, I am starting to get it now. I see why these two workshops play off of one another, because you are laying out all the things that have happened at HP, what to expect, and what some of the alternatives are. That way you've got in your mind a set of alternative directions. Then, by doing the Maturity Model, you get a sense of where you are and where you can go, and putting the two together can start you on that path.

Let’s look at that future path a little bit. Folks have taken these workshops and gotten a better sense of the holistic full total equation. What usually happens next? What's the process from research, understanding, and knowledge to actually starting to hammer out a definition of what you and your particular situation as an organization should do?

Let me fire that first off at you, Helen.

Tang: As often happens, it depends. It’s based on your organization’s business needs. Where are you trying to go in the next year, two years, or five years? It’s also based on the level of constraint that you face right now in the data center.

We see one of two paths. In the more transformational approach, whereby you have the highest level of buy-in, all the way up to the CIO and sometimes CFO and CEO, you lay out an actual 12-18 month plan. HP can help with that, and you start executing towards that. You say, "Okay, what would be the first step?" A lot of times, it makes sense to standardize, consolidate. Then, what is the next step? Sometimes that’s modernizing applications, and so on. That’s one approach we have seen.

A lot of organizations don’t have the luxury of going top-down and doing the big bang transformation. Then, we take a more project-based approach. It still helps them a lot going through these two workshops. They get to see the big picture and all the things that are possible, but they start picking low-hanging fruit that would yield the highest ROI and solve their current pain points.

A lot of organizations don’t have the luxury of going top-down and doing the big bang transformation.

Often, in these past few years, it has been virtualization. What is my current virtualization level? How do I take it up to maximum efficiency? And then, look to adjacent projects. So, the next step might be consolidation, or automation, and so on.

Gardner: Mark Edelmann, same to you. Are there some typical scenarios that you've seen that folks when they have digested the implications from these workshops then have a vision or a direction, and what typically would that be?

Edelmann: Helen did a great job of outlining it, because different customers start at different places and they are headed for different places. Often, the journey is a little bit different from one customer to the other.

The Maturity Model Workshop you might think of as being at a little lower level than the Data Center Transformation Workshop. As a result of the Maturity Model Workshops, we produce a report for the customer to understand -- A is where I'm at, and B is where I'm headed. Those gaps that are identified during the course of the assessment help lead a customer to project definitions.

In some cases, there may be some obvious things that can be done in the short term and capture some of that low-hanging fruit -- perhaps just implement a blade system or something like that -- that will give them immediate results on the path to higher maturity in their transformation journey.

Multiple starting points

There are multiple starting points and consequently multiple exit points from the Maturity Model Workshop as well.

Gardner: Mark Grindle, same kind of question. How do people take what they've gathered here to use it? Any stories or anecdotes about what you have seen people do with this that has helped them?

Grindle: Mark and Helen were both right in their comments. The result of the workshop is really a sequence series of events that the customer should follow up on next. Those can be very specific items, like gather your physical server inventories so that that can be analyzed, to other items such as run a Maturity Model Workshop, so that you can understand where you are in each of the areas and what the gaps are, based on where you really want to be.

It’s always interesting when we do these workshops, because we pull together a group of senior executives covering all the domains that I've talked about -- program management, governance -- their infrastructure people, their technology people, their applications people, and their operational people, and it’s always funny, the different results we see.

I had one customer that said to me that the deliverable we gave them out in the workshop was almost anti-climatic versus what they learned in the workshop. What they had learned during this one was that many people had different views of where the organization was and where it wanted to go.

It’s a great learning collaborative event that brings together a lot of the thoughts on where they want to head.

Each was correct from their particular discipline, but from an overarching view of what are we trying to do for the business, they weren’t all together on all of that. It’s funny how we see those lights go on as people are talking and you get these interesting dialogs of people saying, "Well, this is how that is." And someone else going, "No, it’s not. It’s really like this."

It’s amazing the collaboration that goes on just among the customer representatives above and beyond the customer with HP. It’s a great learning collaborative event that brings together a lot of the thoughts on where they want to head. It ends up motivating people to start taking those next actions and figuring out how they can move their data centers and their IT environment in a much more logical, and in most cases, aggressive fashion than they were originally thinking.

Gardner: It sounds like a very powerful exercise for a lot of different reasons. For those folks interested, how could they learn more about these workshops? Are there some resources out there whereby they go to find them? Let me start with you, Helen.

Tang: The place to go would be hp.com/go/dct.

Gardner: That’s pretty straightforward. Any other thoughts Mark and Mark about where you could go to pursue information if you were starting to get interested in these workshops?

Edelmann: Well, it’s probably not a big surprise, but to learn more about the CI Maturity Model, you can go to hp.com/go/cimm.

Gardner: And Mark Grindle?

Grindle: I agree with both of those. Obviously your HP account rep can help you. We have an HP IT Forum coming up soon. For people who are attending, we do mini workshops during this event. We set up a day that individual customers can come in for an hour and we walk them through each one of the panels very quickly and give them a flavor for what the full workshop would look like. There are a lot of options here for people to get a better understanding of the workshop and how it can help them.

Gardner: So, you can get the appetizer before the entrée?

Grindle: Absolutely.

Gardner: Well, thank you. You have been listening to a sponsored podcast discussion on the need for DCT and some proven ways that explore how to do DCT effectively.

I would like to thank our guests. We have been joined by Helen Tang, Solutions Lead for Data Center Transformation and Converged Infrastructure Solutions for HP Enterprise Business. Thanks again, Helen,

Tang: Thanks, Dana. Always a pleasure.

Gardner: And Mark Edelmann, Senior Program Manager, HP’s Enterprise Storage, Servers, and Networking Business Unit. Thanks to you, Mark.

Edelmann: Thank you, Dana.

Gardner: And lastly, Mark Grindle, Business Consultant, Data Center Infrastructure Services in the Technology Services within HP Enterprise Business. Thanks to you.

Grindle: Thank you, Dana. It was great being here.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. 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: HP.

Transcript of a sponsored podcast discussion on two HP workshops that help businesses determine actual IT needs and provide a roadmap for improving data center operations and efficiency.Copyright Interarbor Solutions, LLC, 2005-2011. All rights reserved.

You may also be interested in:

• HP's Instant-On Enterprise Initiative Takes Aim at Shifting Needs of Business and Government
• Hastening Trends Around Cloud, Mobile Push Application Transformation as Priority, says Research
• Well-Planned Data Center Transformation Effort Delivers IT Efficiency Paybacks, Green IT Boost for Valero Energy
• Data Center Transformation Includes More than New Systems; There's Also Secure Data Removal, Recycling, Server Disposal