Enterprise Architecture and Enterprise Transformation: Related But Distinct Concepts That Can Change the World

Transcript of a sponsored podcast discussion on the respective roles of enterprise architecture and enterprise transformation and the danger --and opportunity -- of conflating the two.

Listen to the podcast. Find it on iTunes/iPod. Download the transcript. Sponsor: The Open Group.

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 in conjunction with The Open Group Conference held in San Francisco the week of January 30, 2012.

We've assembled a panel from among the conference speakers and contributors to examine the fascinating relationship between enterprise architecture (EA) and enterprise transformation. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

For some, the role and impact of an information technology and the organizing benefits of enterprise architecture make them larger than life, when it comes to enterprise transformation. In other words, if you really want enterprise transformation, you really need enterprise architecture to succeed in the modern enterprise.

For others, the elevation of enterprise architecture as a tag team to enterprise transformation improperly conflates the role of enterprise architecture and, as such, waters down enterprise architecture and risks obscuring its unique contribution.

So how should we view these roles and functions? How high into the enterprise transformation firmament should enterprise architecture rise? And will rising too high, in effect, melt its wings and cause it to crash back to earth and perhaps become irrelevant?

Or is enterprise transformation nowadays significantly dependent upon enterprise architecture, and therefore, we should make enterprise architecture a critical aspect for any business moving forward?

We'll pose these and other questions to our panel here to deeply examine the relationship between enterprise architecture and enterprise transformation. So with that, let me now introduce our guests.

We're here with Len Fehskens, Vice President of Skills and Capabilities at The Open Group. Welcome, Len.

Len Fehskens: Hi, Dana. Great to be here.

Gardner: We're also here with Madhav Naidu, Lead Enterprise Architect at Ciena Corp. Welcome to the show, Madhav.

Madhav Naidu: Thanks, Dana.

Gardner: We're also here with Bill Rouse, Professor in the School of Industrial and Systems Engineering and the College of Computing, as well as Executive Director of the Tennenbaum Institute, all at the Georgia Institute of Technology. He's also the Principal at Rouse Associates. Welcome to our show, Bill.

Bill Rouse: It's great to be here, Dana. Thank you.

Gardner: And Jeanne Ross, Director and Principal Research Scientist at the MIT Center for Information Systems Research, join us. Welcome back, Jeanne.

Jeanne Ross: Good morning, Dana.

Architecture and transformation

Gardner: Let's start with you Len. You’ve been tracking enterprise architecture for quite some time. You’ve been a practitioner of this. You’ve been involved with The Open Group for some time. Why is enterprise transformation not significantly dependent upon enterprise architecture, and why would it be a disservice to bring enterprise architecture into the same category?

Fehskens: I don't think that's quite what I believe. My biggest concern is the identification of enterprise architecture with enterprise transformation.

First of all, these two disciplines have different names, and there's a reason for that. Architecture is a means to transformation, but it is not the same as transformation. Architecture enables transformation, but by itself is not enough to effect successful transformation. There are a whole bunch of other things that you have to do.

My second concern is that right now, the discipline of enterprise architecture is sort of undergoing -- I wouldn’t call it an identity crisis -- but certainly, it's the case that we still really haven't come to a widespread, universally shared understanding of what enterprise architecture really means.

Just go onto any Internet discussion group about enterprise architecture, open up the discussion about the definition of enterprise architecture, and I guarantee that you will get hundreds and hundreds of posts all arguing about what enterprise architecture is. To make that problem worse by trying to fold enterprise transformation into the function of enterprise architecture is just not a good idea at this point.

To make that problem worse by trying to fold enterprise transformation into the function of enterprise architecture is just not a good idea at this point.

My position is that they're two separate disciplines. Enterprise architecture is a valuable contributor to enterprise transformation, but the fact of the matter is that people have been transforming enterprises reasonably successfully for a long time without using enterprise architecture. So it's not necessary, but it certainly helps. It's just like having power tools makes it easier to build a house, but people have been building houses for a long time without power tools.

I'm concerned about making bigger promises than we can actually keep by falling into the trap of believing that enterprise architecture, by itself, is sufficient to make enterprise transformation successful. I don’t think that’s the case. There are other things that you need to be able to do besides developing architectures in order to successfully transform an enterprise.

Gardner: Okay, Len, if the concept, the notion, or the definition of enterprise architect is changing, I suppose we also have to recognize that enterprise transformation, as it's defined, is changing as well. To borrow from your analogy, the power tools to build a house are not necessary, but you might be able to build a better house a lot faster. And building things better and faster seem to be much more a part of enterprise transformation now than they used to be.

Fehskens: No argument, but again, to use that analogy, you can do more with power tools than build just houses. You can build all kinds of other stuff as well. So, no argument at all that enterprise architecture is not a powerful means to effecting enterprise transformation, but they are distinct disciplines. The means to an end doesn’t mean the means is the end and doesn’t make them synonymous. They are still, as I said, distinct.

Gardner: I think we’re getting close to understanding the relationship. Madhav, as a practitioner of enterprise architecture at Ciena Corp., are you finding that your role, the value that you’re bringing to your company as an enterprise architect, is transformative? Do you agree with Len? Do you think that there's really a confluence between these different disciplines at this time?

Means and ends

Naidu: Definitely. What Len mentioned, it rhymes very well with me. The means and the end, kind of blending it down. Transformation itself is more like a wedding and EA is more like a wedding planner. I know we have seen many weddings without a wedding planner, but it makes it easier if you have a wedding planner, because they have gone through certain steps (as part of their experience). They walk us through those processes, those methods, and those approaches. It makes it easier.

That’s why, definitely, I agree with what Len said. Enterprise transformation is different. It's a huge task and it is the actual end. Enterprise architecture is a profession that can help lead the transformation successfully.

One another point Len brought up in this discussion is that, it is not just the enterprise architects who will be doing the whole thing. Almost everybody in the enterprise is engaged in one way or another. The enterprise architect plays more like a facilitator role. They are bringing the folks together, aligning them with the transformation, the vision of it, and then driving the transformation and building the capabilities. Those are the roles I will look at EA handling, but definitely, these two are two different aspects.

Gardner: Is there something about the state of affairs right now that makes enterprise architecture specifically important or particularly important for enterprise transformation? I believe I'm getting more towards this idea that IT is more important and that the complexity of the relationship between IT and business necessitates EA and therefore transformation really can't happen without it.

There is a lot of discussion about what really constitutes an EA and where are the boundaries for EA.

Naidu: We know many organizations that have successfully transformed without really calling a function EA and without really using help from a team called EA. But indirectly they are using the same processes, methods, and best practices. They may not be calling those things out, but they are using the best practices. When they do that, the transformations have been successful, but then when they don’t apply those best practices and standards, there are many organizations that fail.

That’s why, now, like Len brought up earlier, there is a lot of discussion about what really constitutes an EA and where are the boundaries for EA, because it is part IT, there are different roles, and part business, and a lot of people are engaged.

So there's a lot of churn going on over what should be the part of EA. But going back to your question, I definitely see the critical role EA is playing. Hopefully, in the next few years, EA will form its appropriate objectives, processes, and methods so that we can say this is what we mean by EA.

Gardner: Bill Rouse, how do you come down on this? Clearly there's an impact that EA has on enterprise transformation. We seem to grasp for analogies when we try to define this relationship. Are you finding in your research and through the organizations you're working with that the role of architecture creeps in? Even if people don’t know they’re doing architecture, when they get to transformation and a complex setting in today’s world, architecture is almost a necessity.

Rouse: There are two distinctions I’d like to draw. First of all, in the many transformation experiences we've studied, you can simplistically say there are three key issues: people, organizations, and technology, and the technology is the easy part. The people and organizations are the hard part.

The other thing is I think you’re talking about is the enterprise IT architecture. If I draw an enterprise architecture, I actually map out organizations and relationships among organizations and work and how it gets done by people and view that as the architecture of the enterprise.

Important enabler

Sometimes, we think of an enterprise quite broadly, like the architecture of the healthcare enterprise is not synonymous with IT. In fact, if you were to magically overnight have a wonderful IT architecture throughout our healthcare system in United States, it would be quite helpful but we would still have a problem with our system because the incentives aren’t right. The whole incentive system is messed up.

So I do think that the enterprise IT architecture, as I see it -- and others can correct me if I'm wrong, but I think that's what you’re talking about -- is an important enabler, a crucial enabler, to many aspects of enterprise transformation. But I don’t see them as close at all in terms of thinking of them as synonymous.

Gardner: Len Fehskens, are we actually talking about IT architecture or enterprise architecture and what's the key difference?

Fehskens: Well, again that’s this part of the problem, and there's a big debate going on within the enterprise architecture community whether enterprise architecture is really about IT, in which case it probably ought to be called enterprise IT architecture or whether it’s about the enterprise as a whole.

For example, when you look at the commitment of resources to the IT function in most organizations, depending on how you count, whether you count by headcount or dollars invested or whatever, the numbers typically run about 5-10 percent. So there's 90 percent of most organizations that is not about IT, and in the true enterprise transformation, that other 90 percent has to transform itself as well.

There's a big debate going on within the enterprise architecture community whether enterprise architecture is really about IT.

So part of it is just glib naming of the discipline. Certainly, what most people mean when they say enterprise architecture and what is actually practiced under the rubric of enterprise architecture is mostly about IT. That is, the implementation of the architecture, the effects of the architecture occurs primarily in the IT domain.

Gardner: But, Len, don't TOGAF at The Open Group and ArchiMate really step far beyond IT? Isn’t that sort of the trend?

Fehskens: It certainly is a trend, but I think we've still got a long way to go. Just look at the language that’s used in the architecture development method (ADM) for TOGAF, for example, and the model of an enterprise architecture. There's business, information, application, and technology.

Well, three of those concepts are very much related to IT and only one of them is really about business. And mostly, the business part is about that part of the business that IT can provide support for. Yes, we do know organizations that are using TOGAF to do architecture outside of the IT realm, but the way it's described, the way it was originally intended, is largely focused on IT.

The TOGAF standard was developed almost entirely by the IT community. But it is clear to people who step back far enough from the details of where the implementation happens that architectural thinking is a very generally applicable discipline and certainly can be applied to that other 90 percent of the enterprise that I talked about.

Not a lot going on

It's just that there's not a whole lot of that going on, and as Madhav pointed out, what is going on is generally not called architecture. It's called organizational design or management or it goes under a whole bunch of other stuff. And it's not referred to as enterprise architecture, but there is a lot of that stuff happening. As I said earlier, it is essential to making enterprise transformation successful.

My personal opinion is that virtually all forms of design involve doing some architectural thinking. Whether you call it that or not, architecture is a particular aspect of the design process, and people do it without recognizing it, and therefore are probably not doing it explicitly.

But Bill made a really important observation, which is that it can't be solely about IT. There's lots of other stuff in the enterprise that needs to transform.

Gardner: To that point, let's go to Jeanne Ross. Jeanne, in your presentation at The Open Group Conference, you mentioned data management and that the ability of leveraging analytics and presenting that to more people with good data in real time is an essential ingredient for transformation and for just doing things better, faster, cheaper, more impactful in the market, and so on.

Now wouldn’t the data management as a category sort of crossover. It's got parts of IT, parts of architectures, and parts of organizational management. When we think about making data management essential, doesn’t this in a sense bring about more recognition that an architectural approach that helps foster something at that level at that category becomes really important in today’s world?

Ross: I actually would discourage people from focusing on data management first. We've had a number of companies we studied who thought, "All I care about is the data. I'm just going to get that cleaned up." What they learned was that if they didn’t clean up their processes, they didn’t need to be thinking about data. It was going nowhere.

Analytics has been over-hyped as something that we can do a lot of in IT, while we're waiting for the rest of the organization to get its act together around architecture. Similarly, that has led to a lot of IT efforts that haven’t added real value to organizations.

So I wouldn't emphasize data management as a priority, even though we'll get there eventually. It is actually essential at some point. I think a lot of efforts around data management have been around the idea "Data makes this organization run. Let's get data fixed," as if we could just do that in isolation from everything else. That is a really frustrating approach.

I'd go back to the challenge we have here of enterprise architecture being buried in the IT unit. Enterprise architecture is an enterprise effort, initiative, and impact. Because enterprise architecture is so often buried in IT, IT people are trying to do things and accomplish things that cannot be done within IT.

We've got to continue to push that enterprise architecture is about designing the way this company will do it business, and that it's far beyond the scope of IT alone. I take it back to the transformation discussion. What we find is that when a company really understands enterprise architecture and embraces it, it will go through a transformation, because it's not used to thinking that way and it's not used to acting that way.

Disciplined processes

If management says we're going to start using IT strategically, we're going to start designing ourselves so that we have disciplined business processes and that we use data well. The company is embracing enterprise architecture and that will lead to a transformation.

Data management will be a crucial element of this, but the big mistake I see out there is thinking that IT will fix up data, and that is going to have some big impact on either enterprise architecture or enterprise transformation, or both. The ‘I’ is simply a critical element. It's not something that we can just fix.

Gardner: You also said that someday CIOs are going to report to the enterprise architects, and that’s the way it ought to be. Does that get closer to this notion that IT can't do this alone, that a different level of thinking across disciplines and functions needs to occur?

Ross: I certainly think so. Look at companies that have really embraced and gotten benefits from enterprise architecture like Procter & Gamble, Tetra Pak, and Maersk. At P&G’s, IT is reporting to the CIO but he is also the President of Shared Services. At Maersk and Tetra Pak, it's the Head of Global Business Processes.

Once we get CIOs either in charge with more of a business role and they are in charge of process, and of the technology, or are reporting to a COO or head of business process, head of business transformation, or head of shared services, then we know what it is we’re architecting, and the whole organization is designed so that architecture is a critical element.

But in practice, what we’re seeing is more CIOs reporting to someone who is, in fact, in charge of designing the architecture of the organization.

I don’t think that title-wise, this is ever going to happen. I don’t think we’re ever going to see a CIO report to chief enterprise architect. But in practice, what we’re seeing is more CIOs reporting to someone who is, in fact, in charge of designing the architecture of the organization. By that, I mean business processes and its use of data. When we get there, first of all, we will transform to get to that point and secondly, we’ll really start seeing some benefits and real strategic impact of enterprise architecture.

Gardner: Madhav, at Ciena, do you see that this process-level capability around enterprise architecture is what's occurring, even if the titles are not aligned that way or the org chart doesn’t point to the CIO reporting to an architect. Is architecture in practice elevating a process orientation to this capability set that therefore fosters better transformation?

Naidu: Definitely. Some progress has been happening, especially what Jeanne was mentioning about the business process changes itself, rather than just bringing the systems and customizing it to our needs, and rather than transforming our business processes so that they match industry standard.

That’s definitely happening, and the architecture team has engaged and is influencing that process. But that said, the maturity level takes quite a few years, not only at Ciena, but in other places too. It will take some time but this is happening.

Gardner: Len Fehskens, we have a mentality in our organizations that architecture isn't that important, and there's some cynicism and skepticism around architecture, and yet, what we’re hearing is it's not in name only. It is important, and it's increasingly important, even at higher and higher abstractions in the organization.

How to evangelize?

How then do you evangelize or propel architectural thinking into companies? You may have been concerned that advancement of architectural thinking would have been impelled when we conflate enterprise architecture into transformation, but until then, what should you do? How do you get the thinking around an architectural approach more deeply engrained in these companies?

Fehskens: Dana, I think that’s the $64,000 question. The fundamental way to get architectural thinking accepted is to demonstrate value. I mean to show that it really brings something to the party. That’s part of my concern about the conflation of enterprise transformation with enterprise architecture and making even bigger promises that probably can't be kept.

The reason that in organizations who’ve tried enterprise architecture and decided that it didn’t taste good, it was because the effort didn’t actually deliver any value. Certainly the advice that I hear over and over again, and that I myself give over and over again, is: “Don’t try to boil the ocean.” Start small and demonstrate success. And again, there's that old saw that nothing succeeds like success.

The way to get architectural thinking integrated into an organization is to use it in places where it can deliver obvious, readily apparent value in the short-term and then grow out from that nucleus. Trying to bite off more than you can chew only results in you choking. That's the big problem we’ve had historically. There are all these clichés and the reason of clichés is because there's certain amount of truth to them about your reach exceeding your grasp, for example.

It’s about making promises that you can actually keep. Once you've done that, and done that consistently and repeatedly, then people will say that there's really something to this. There's some reason why these guys are actually delivering on a big promise.

Trying to bite off more than you can chew only results in you choking. That's the big problem we’ve had historically.

Rouse: Can I offer something, another perspective?

Fehskens: Yeah, please do go.

Rouse: We ran a study recently about what competencies you need to transform an organization based on a series of successful case studies and we did a survey with hundreds of top executives in the industry.

The number one and two things you need are the top leader has to have a vision of where you’re going and they have to be committed to making that happen. Without those two things, it seldom happens at all. From that perspective, I'd argue that the CIO probably already does report to the chief architect. Bill Gates and Steve Jobs architected Microsoft and Apple. Carnegie and Rockefeller architected the steel and oil industries.

If you look at the business histories of people with these very successful companies, often they had a really keen architectural sense of what the pieces were and how they needed to fit together. So if we’re going to really be in the transformation business with TOGAF and stuff, we need to be talking to the CEO, not the CIO.

Gardner: Jeanne Ross, let’s focus on what Bill just said in terms of the architecture function really being at the core and therefore at the highest level of the organization.

Corporate strategy

Ross: I totally agree. The industries and companies that you cited, Bill, instinctively did what every company is going to need to do in the digital economy, which is think about corporate strategy not just in terms of what products do we offer, what markets are we in, what companies do we acquire, and what things do we sell up.

At the highest level, we have to get our arms around it. Success is dependent on understanding how we are fundamentally going to operate. A lot of CEOs have deferred that responsibility to others and when that mandate is not clear, it gets very murky.

What does happen in a lot of companies, because CEOs have a lot of things to pay attention to, is that once they have stated the very high-level vision, they absolutely can put a head of business process or a head of shared services or a COO type in charge of providing the clarification, providing the day-to-day oversight, establishing the relationships in the organizations so everybody really understands how this vision is going to work. I totally agree that this goes nowhere if the CEO isn’t at least responsible for a very high-level vision.

Gardner: So if what I think I'm hearing is correct, how you do things is just as important as what you do. Because we’re in such a dynamic environment, when it comes to supply chains and communications and the way in which technology influences more and more aspects of business, it needs to be architected, rather than be left to a fiat or a linear or older organizational functioning.

So Bill Rouse, the COO, the chief operating officer, wouldn’t this person be perhaps more aligned with enterprise architecture in the way that we’re discussing?

We can't find a single instance of a major enterprise transformation in a major company happening successfully without total commitment of top leadership.

Rouse: Jeanne makes a good point. Let's start with the basic data. We can't find a single instance of a major enterprise transformation in a major company happening successfully without total commitment of top leadership. Organizations just don’t spontaneously transform on their own.

A lot of the ideas and a lot of the insights can come from elsewhere in the organization, but, given that the CEO is totally committed to making this happen, certainly the COO can play a crucial role in how it's then pursued, and the COO of course will be keenly aware of a whole notion of processes and the need to understand processes.

One of the companies I work very closely with tried to merge three companies by putting in ERP. After $300 million, they walked away from the investment, because they realized they had no idea of what the processes were. So the COO is a critical function here.

Just to go back to original point, you want total commitment by the CEO. You can't just launch the visionary message and walk away. At the same time, you need people who are actually dealing with the business processes to do a lot of the work.

Gardner: Madhav, at the Ciena, how do you view the relationship between what you do as a lead enterprise architect and what your operations officer does? It might not be that title, but the function of operations management and oversight. How do they come together?

Not role, but involvement

Naidu: Not by role, but by involvement. There are quite a few business executives engaged in the business process identification and changes. Many of them report to the top executives in the business line. That’s what the current setting right now. We're pretty happy that that kind of support is coming from many of the executives and business teams. That said, there is no formal relationship in terms of reporting and all.

Gardner: Len Fehskens, you mentioned a while ago that finding success and demonstrating value are instrumental to promulgating the use of architecture and understanding the benefits of architecture. Would operations, rather than just technology, be a target than for how you can demonstrate that? The architecture processes might be the sweet spot in some of the thinking now about where to demonstrate that enterprise architecture is the way to go.

Fehskens: Absolutely. And this ties into another thing we need to be aware of, which is that the need to transform, the motivation for enterprise transformation, doesn’t always come from disruptive technologies. There was a really interesting talk last week at the conference on sustainable enterprise architecture, and they made the point that there are lots of major disruptions that have nothing to do with technology.

In particular, in a world where resources are becoming increasingly scarce, and impact on the environment is a significant concern, the drive to transform an enterprise will often come from other places than the appearance of disruptive technologies. There will be disruptions of all sorts that have to be dealt with. The transformation in response to those isn't going to come out of the IT organization. It's going to have to come from other organizations.

The idea that we talked about at the beginning of the discussion was that architecture is a very powerful means for figuring out what kind of transformation is necessary, and how to effect it, means that we need architectures that aren’t about IT, we need to understand driving architectural approach to the other considerations that an enterprise deals with.

Architecture is a very powerful means for figuring out what kind of transformation is necessary, and how to effect it.

As Bill said, historically it's been the case that the lead architects in the most successful organizations were the guys who had the vision and the guys who were at the very top of the organizational structure who created this organization in the very first place. And they weren’t IT guys. Bill Gates, in particular, didn’t build Microsoft around its IT capability. He built it around a whole bunch of other ideas that were really business ideas, not IT concepts. So, yeah, absolutely.

Gardner: I'm afraid we'll have to wrap it up. I’d like to go once around the panel with a pretty direct question and if you could perhaps provide your succinct thoughts. What is the relationship between enterprise architecture and enterprise transformation? Let's start with you first, Jeanne.

Ross: I'd say the relationship between enterprise architecture and enterprise transformation is two-way. If an organization feels the need for a transformation -- in other words, if it feels it needs to do something -- it will absolutely need enterprise architecture as one of the tools for accomplishing that.

It will provide the clarity the organization needs in a time of mass change. People need to know where they're headed, and that is true in how they do their processes, how they design their data, and then how they implement IT.

It works just as well in reverse. If a company hasn't had a clear vision of how they want to operate, then they might introduce architecture to provide some of that discipline and clarity and it will inevitably lead to a transformation. When you go from just doing what every individual thought was best or every business unit thought was best to an enterprise vision of how a company will operate, you're imposing a transformation. So I think we are going to see these two hand-in-hand.

What's the relationship?

Gardner: Bill Rouse, same question, what in your view is the relationship between enterprise architecture and enterprise transformation?

Rouse: I think enterprise transformation often involves a significant fundamental change of the enterprise architecture, broadly defined, which can then be enabled by the enterprise IT architecture.

Gardner: Madhav, also to you the same question, relationship between EA and enterprise transformation?

Naidu: Like I mentioned in the beginning, one is end, another one is means. I look at the enterprise transformation as an end and enterprise architecture providing the kind of means. In one way it's like reaching the destination using some kind of transportation mechanism. That’s how I look at the difference between EA and ET?

Gardner: Len, I know you’ve gone out at some length about this, but perhaps the elevator version. How do you view the relationship between EA and enterprise transformation?

Enterprise transformation often involves a significant fundamental change of the enterprise architecture, broadly defined, which can then be enabled by the enterprise IT architecture.

Fehskens: One of the fundamental principles of architecture is taking advantage of reuse when it's appropriate. So I'm just going to reuse what everybody just said. I can't say it better. Enterprise architecture is a powerful tool for effecting enterprise transformation. Jeanne is right. It's a symmetric or bidirectional back-and-forth kind of relationship, and what Bill and Madhav said applies as well. So I really don't have anything to add.

Gardner: Well, I found it very interesting. I have a newfound appreciation for architecting how you do something better enables you to decide what it is that you're going to do in the future, and there is an interesting relationship between how and what that perhaps escape some folks. I hope they recognize that a little bit more deeply.

You’ve been listening to a sponsored podcast discussion in conjunction with The Open Group Conference in San Francisco, the week of January 30th, 2012. We've enjoyed our discussion with our guests and I’d like to thank them and call them out individually one more time.

Len Fehskens, the Vice President of Skills and Capabilities at The Open Group. Thank you, Len.

Fehskens: Thank you, Dana.

Gardner: Madhav Naidu, Lead Enterprise Architect at Ciena Corporation. Thanks so much.

Naidu: It's been my pleasure.

Gardner: Bill Rouse, Professor in the School of Industrial and Systems Engineering as well as the College of Computing and also Executive Director at The Tennenbaum Institute, all at the Georgia Institute of Technology, and Principal at Rouse Associates. Thank you, Bill.

Rouse: Thank you. I enjoyed it.

Gardner: And Jeanne Ross, Director and Principal Research Scientist at the MIT Center for Information Systems Research. Thanks so much for your input.

Ross: Thank you. Great talking with you all.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. Thanks to our audience for joining us, and come back next time.

Listen to the podcast. Find it on iTunes/iPod. Download the transcript. Sponsor: The Open Group.

Transcript of a sponsored podcast discussion on the respective roles of enterprise architecture and enterprise transformation and the danger --and opportunity -- of conflating the two. Copyright Interarbor Solutions, LLC, 2005-2012. All rights reserved.

You may also be interested in:

• Open Group Conference Speakers Discuss the Cloud: Higher Risk or Better Security?
• Capgemini's CTO on Why Cloud Computing Exposes the Duality Between IT and Business
• San Francisco Conference observations: Enterprise transformation, enterprise architecture, SOA and a splash of cloud computing
  
• MIT's Ross on how enterprise architecture and IT more than ever lead to business transformation
• Overlapping criminal and state threats pose growing cyber security threat to global Internet commerce, says Open Group speaker
• Enterprise architects play key role in transformation, data analytics value -- but they need to act fast, say Open Group speakers
  
• Exploring Business-IT Alignment: A 20-Year Struggle Culminating in the Role and Impact of Business Architecture

Open Group Conference Speakers Discuss the Cloud: Higher Risk or Better Security?

A sponsored podcast discussion from The Open Group Conference in San Francisco on what the burgeoning cloud movement means for enterprise security.

Listen to the podcast. Find it on iTunes/iPod. Download the transcript. Sponsor: The Open Group.

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 in conjunction with The Open Group Conference held in San Francisco the week of January 30, 2012.

We've assembled a panel from among the conference speakers and contributors to examine the relationship between cloud computing and security. For some, any move to the cloud, at least the public cloud, means a higher risk for security. For others, relying more on a public cloud provider means better security. There’s more of a concentrated and comprehensive focus on security best practices that are perhaps implemented and monitored centrally.

And so which is it? Is cloud a positive or negative when it comes to security? And what of hybrid models that combine public and private cloud activities, how is security impacted in those cases? We'll pose these and other questions to our panel here now to deeply examine how cloud and security come together, for better or worse.

Please join me now in welcoming our panelists. We're here today with Jim Hietala, Vice President of Security for The Open Group. Welcome, Jim. [Disclosure: The Open Group and HP are sponsors of BriefingsDirect podcasts.]

Jim Hietala: Thanks Dana. Glad to be here.

Gardner: We're also here with Stuart Boardman, Senior Business Consultant at KPN, where he co-leads the Enterprise Architecture Practice as well as the Cloud Computing Solutions Group. Stuart is also a co-chair of the Security for the Cloud and SOA Projects under The Open Group Cloud Work Group. Welcome.

Stuart Boardman: Thanks.

Gardner: And we're here with Dave Gilmour, an Associate at Metaplexity Associates and a Director at PreterLex Ltd. Welcome, Dave.

Dave Gilmour: Good afternoon.

Gardner: And lastly, we're here with Mary Ann Mezzapelle, Strategist for Enterprise Services and Chief Technologist for Security Services at HP. She's also a member of The Open Group Security Forum Steering Committee. Welcome, Mary Ann.

Mary Ann Mezzapelle: I'm glad to be here.

Gardner: We've heard quite a bit here at the conference, and one of the speakers, Andy Mulholland, the Chief Technology Officer at Capgemini, was raising this concept of "outside IT" as an important business imperative. More organizations are looking to do more activities that would have previously been inside the firewall under the purview of IT.

Now, whether it’s software as a service (SaaS), or whether it’s cloud, whether it’s business services from a variety of different providers, more business activities and business processes are being combined with an outside-the-enterprise-firewall entity.

So Jim Hietala, to you. This poses a problem to the traditional IT folks, to the chief security officer, if you have one. Is this notion of going outside the firewall fundamentally a good or bad thing when it comes to security?

Failed strategy

Hietala: It can be either. Talking to security people in large companies, frequently what I hear is that with adoption of some of those services, their policy is either let’s try and block that until we get a grip on how to do it right, or let’s establish a policy that says we just don’t use certain kinds of cloud services. Data I see says that’s really a failed strategy. Adoption is happening whether they embrace it or not.

The real issue is how you do that in a planned, strategic way, as opposed to letting services like Dropbox and other kinds of cloud collaboration services just happen. So it’s really about getting some forethought around how do we do this the right way, picking the right services that meet your security objectives, and going from there.

Gardner: For a moment I thought you were going to say it depends and I'm glad you didn’t, but in a sense that’s what it comes down to. We'll get into that in a little bit more detail, but let’s go around the panel first.

Stuart Boardman, is cloud computing good or bad for security purposes?

Boardman: It’s simply a fact, and it’s something that we need to learn to live with, and I think Jim has covered quite a few of the things that I think are really important.

What I wanted to add to that is what I've noticed through my own work is a lot of enterprise security policies were written before we had cloud, but when we had private web applications that you might call cloud these days, and the policies tend to be directed towards staff’s private use of the cloud.

Then you run into problems, because you read something in policy and if you interpret that as meaning cloud, it means you can’t do it. And if you say it’s not cloud, then you haven’t got any policy about it at all. Enterprises need to sit down and think, "What would it mean to us to make use of cloud services and to ask as well, what are we likely to do with cloud services?"

Gardner: Dave, if you're a cloud provider, you have to be secure or you're dead. You're not going to be in business very long. Is there an added impetus for cloud providers to be somewhat more secure perhaps than enterprises?

Gilmour: It depends on the enterprise that they're actually supplying to. If you're in a heavily regulated industry, you have a different view of what levels of security you need and want, and therefore what you're going to impose contractually on your cloud supplier. That means that the different cloud suppliers are going to have to attack different industries with different levels of security arrangements.

The problem there is that the penalty regimes are always going to say, "Well, if the security lapses, you're going to get off with two months of not paying" or something like that. That kind of attitude isn't going to go in this kind of security.

What I don’t understand is exactly how secure cloud provision is going to be enabled and governed under tight regimes like that.

Gardner: It seems as if we almost have a runaway market. We have things that are happening faster than we've got anything in place to accommodate it, whether it’s at different layers, for different regulatory purposes, and how to price around. We're really in the wild west so far.

Mary Ann, any thoughts about whether this period of shakeout that we're in will provoke market forces so that security is perhaps better managed than it would have been without these sort of dynamic market forces?

An opportunity

Mezzapelle: You're right that there's a differentiation, and there's an opportunity in each of the sections, because it’s a place where you can either have the supplier provide the security for you, if it’s not in a regulated industry. Or, if you're in a regulated industry, you have the option of layering your own security services on top of it, hopefully integrated with it, or embedded with it even better. But you have that opportunity.

Gardner: Jim, we've seen in the public sector, governments recognizing that cloud models could be a benefit to them. They can reduce redundancy. They can control and standardize. They're putting in place some definitions, implementation standards, and so forth. Is the vanguard of correct cloud computing with security in mind being managed by governments at this point?

Hietala: I'd say that they're at the forefront. Some of these shared government services, where they stand up cloud and make it available to lots of different departments in a government, have the ability to do what they want from a security standpoint, not relying on a public provider, and get it right from their perspective and meet their requirements. They then take that consistent service out to lots of departments that may not have had the resources to get IT security right, when they were doing it themselves. So I think you can make a case for that.

Gardner: Stuart, being involved with standards activities yourself, does moving to the cloud provide a better environment for managing, maintaining, instilling, and improving on standards than enterprise by enterprise by enterprise? As I say, we're looking at a larger pool and therefore that strikes me as possibly being a better place to invoke and manage standards.

Boardman: Dana, that's a really good point, and I do agree. Also, in the security field, we have an advantage in the sense that there are quite a lot of standards out there to deal with interoperability, exchange of policy, exchange of credentials, which we can use. If we adopt those, then we've got a much better chance of getting those standards used widely in the cloud world than in an individual enterprise, with an individual supplier, where it’s not negotiation, but "you use my API, and it looks like this."

Will we get enough specific weight of people who are using it to force the others to come on board? And I have no idea what the answer to that is.

Having said that, there are a lot of well-known cloud providers who do not currently support those standards and they need a strong commercial reason to do it. So it’s going to be a question of the balance. Will we get enough specific weight of people who are using it to force the others to come on board? And I have no idea what the answer to that is.

Gardner: We've also seen that cooperation is an important aspect of security, knowing what’s going on on other people's networks, being able to share information about what the threats are, remediation, working to move quickly and comprehensively when there are security issues across different networks.

Is that a case, Dave, where having a cloud environment is a benefit? That is to say more sharing about what’s happening across networks for many companies that are clients or customers of a cloud provider rather than perhaps spotty sharing when it comes to company by company?

Gilmour: There is something to be said for that, Dana. Part of the issue, though, is that companies are individually responsible for their data. They're individually responsible to a regulator or to their clients for their data. The question then becomes that as soon as you start to share a certain aspect of the security, you're de facto sharing the weaknesses as well as the strengths.

So it’s a two-edged sword. One of the problems we have is that until we mature a little bit more, we won’t be able to actually see which side is the sharpest.

Gardner: So our premise that cloud is good and bad for security is holding up, but I'm wondering whether the same things that make you a risk in a private setting -- poor adhesion to standards, no good governance, too many technologies that are not being measured and controlled, not instilling good behavior in your employees and then enforcing that -- wouldn’t this be the same either way? Is it really cloud or not cloud, or is it good security practices or not good security practices? Mary Ann.

No accountability

Mezzapelle: You're right. It’s a little bit of that "garbage in, garbage out," if you don’t have the basic things in place in your enterprise, which means the policies, the governance cycle, the audit, and the tracking, because it doesn’t matter if you don’t measure it and track it, and if there is no business accountability.

David said it -- each individual company is responsible for its own security, but I would say that it’s the business owner that’s responsible for the security, because they're the ones that ultimately have to answer that question for themselves in their own business environment: "Is it enough for what I have to get done? Is the agility more important than the flexibility in getting to some systems or the accessibility for other people, as it is with some of the ubiquitous computing?"

So you're right. If it’s an ugly situation within your enterprise, it’s going to get worse when you do outsourcing, out-tasking, or anything else you want to call within the cloud environment. One of the things that we say is that organizations not only need to know their technology, but they have to get better at relationship management, understanding who their partners are, and being able to negotiate and manage that effectively through a series of relationships, not just transactions.

Gardner: Jim Hietala, it’s almost ironic that if you're an enterprise that doesn’t do security particularly well, moving to the cloud might be an improvement for you. On the other hand, if you're an enterprise that is a crackerjack security organization, going to the cloud might be a step down.

So does this mean that the cloud providers will be sopping up all of the poor practitioners of security out there, probably for the betterment of everyone?

For small to mid-size enterprises, it may be that the cloud service that they're looking at does security a whole lot better than they do

Hietala: You can make that case, and certainly for small to mid-size enterprises, it may be that the cloud service that they're looking at does security a whole lot better than they do. So maybe it raises the floor for a large numbers of companies. That can be true, sure.

Gardner: Another thing we heard today during the opening speeches at the conference was this notion of enterprise transformation and the role of the enterprise architect. One of the things that jumped out at me that was common was this view that data, good data available to everyone, is an imperative, and this is where the businesses want to go.

One of the things that’s been bandied about in cloud computing is that putting data in the cloud is the risk. I think we've moved beyond that. I think that was an oversimplification.

But if data, sharing data, and getting the data to everyone in your organization is so important, it strikes me that cloud component is going to be part of that, especially if we're dealing with business processes across organizations, doing joins, comparing and contrasting data, crunching it and sharing it, making data actually part of the business, a revenue generation activity, all seems prominent and likely.

So to you, Mr. Boardman, what is the issue now with data in the cloud? Is it good, bad, or just the same double-edged sword, and it just depends how you manage and do it?

Boardman: Dana, I don’t know whether we really want to be putting our data in the cloud, so much as putting the access to our data into the cloud. There are all kinds of issues you're going to run up against, as soon as you start putting your source information out into the cloud, not the least privacy and that kind of thing.

A bunch of APIs

What you can do is simply say, "What information do I have that might be interesting to people? If it’s a private cloud in a large organization elsewhere in the organization, how can I make that available to share?" Or maybe it's really going out into public. What a government, for example, can be thinking about is making information services available, not just what you go and get from them that they already published. But “this is the information," a bunch of APIs if you like. I prefer to call them data services, and to make those available.

So, if you do it properly, you have a layer of security in front of your data. You're not letting people come in and do joins across all your tables. You're providing information. That does require you then to engage your users in what is it that they want and what they want to do. Maybe there are people out there who want to take a bit of your information and a bit of somebody else’s and mash it together, provide added value. That’s great. Let’s go for that and not try and answer every possible question in advance.

Gardner: So if I understand, your position is don’t put the data in the cloud, put the pointers to the data that you retain control over. Is that essentially it?

Boardman: In general. Well, put the data in the cloud if you have a very good reason to do it, but if you are sharing your information, no, don’t put it in the cloud.

Gardner: Dave, do you agree with that, or do you think that there is a place in the cloud for some data?

Gilmour: There's definitely a place in the cloud for some data. I get the impression that there is going to drive out of this something like the insurance industry, where you'll have a secondary cloud. You'll have secondary providers who will provide to the front-end providers. They might do things like archiving and that sort of thing.

If you have that situation where your contractual relationship is two steps away, then you have to be very confident and certain of your cloud partner.

Now, if you have that situation where your contractual relationship is two steps away, then you have to be very confident and certain of your cloud partner, and it has to actually therefore encompass a very strong level of governance.

The other issue you have is that you've got then the intersection of your governance requirements with that of the cloud provider’s governance requirements. Therefore you have to have a really strongly -- and I hate to use the word -- architected set of interfaces, so that you can understand how that governance is actually going to operate.

Gardner: Mary Ann, do you see the data available in the cloud as something that’s going to continue, and what if organizations that don’t do security very well? Wouldn’t their data perhaps be safer in a cloud than if they have a poorly managed network?

Mezzapelle: You're right. It makes a difference as to how you approach it. There is data in the cloud and there will continue to be data in the cloud, whether you want it there or not. The best organizations are going to start understanding that they can’t control it that way and that perimeter-like approach that we've been talking about getting away from for the last five or seven years.

So what we want to talk about is data-centric security, where you understand, based on role or context, who is going to access the information and for what reason. I think there is a better opportunity for services like storage, whether it’s for archiving or for near term use.

There are also other services that you don’t want to have to pay for 12 months out of the year, but that you might need independently. For instance, when you're running a marketing campaign, you already share your data with some of your marketing partners. Or if you're doing your payroll, you're sharing that data through some of the national providers.

Data in different places

So there already is a lot of data in a lot of different places, whether you want cloud or not, but the context is, it’s not in your perimeter, under your direct control, all of the time. The better you get at managing it wherever it is specific to the context, the better off you will be.

Gardner: I think it was Jeanne Ross from MIT who said today that the customer data is perhaps the most important, that a full, common, trusted view of customer data is really an important strategic asset for companies. A lot of where the metadata about customers is these days is in these social networks like Facebook. So if Facebook has a fairly good chunk of information about your customers, that’s already in the cloud, it seems to me that this is a slippery slope that we're already halfway down. Is that the case, Jim?

Hietala: I'd agree it’s a slippery slope. That’s the most dangerous data to stick out in a cloud service, if you ask me. If it's personally identifiable information, then you get the privacy concerns that Stuart talked about. So to the extent you're looking at putting that kind of data in a cloud, looking at the cloud service and trying to determine if we can apply some encryption, apply the sensible security controls to ensure that if that data gets loose, you're not ending up in the headlines of the Wall Street Journal.

Gardner: Stuart, thoughts about what's already in the cloud, Facebook? Let's use that as an example. You want to compare and contrast your customer data with what these customers have put up there for everyone to see. How do you think that this goes against your thought of just joins for the cloud?

Boardman: Well, if we are seeing it as a hybrid cloud, the information that you have about your own customers is internal. It could be in a private cloud, whatever, it could be in any secure situation where the access is secure. There's nothing, of course, that would stop you from using information that people put on the Facebook, because it isn't protected by privacy laws, because they have chosen to put it out there themselves, in general.

There is data in the cloud, and we may make use of the cloud subject to the appropriate constraints.

I'm sorry, but I'm not the world’s greatest legal expert, and there may be some privacy laws that say you can't do that, but I think, in general, if people make it publicly available, then there is nothing in that profile to stop it.

It's a question of, if you've got to get data on Facebook, you're doing that via Facebook’s APIs. You can't just go into Facebook and go join some of their tables. So I don’t think that conflicts at all with what I said before. I have to come back to what Mary Ann said. You're right. There is data in the cloud, and we may make use of the cloud subject to the appropriate constraints. My point was more that information is something that we have to provide that provides value, and we should exploit it that way.

Gardner: I want to take a wild guess that Facebook would probably like to sell you the opportunity to join their cloud more deeply, but of course they would run into trouble with the permissions, the access, and the trust of their customers. So there's another whole podcast discussion in that.

Let's go to Dave. You said there will be different levels on a regulatory basis for security. Wouldn’t that also play with data? Wouldn't there be different types of data and therefore a spectrum of security and availability to that data, and we're waiting to see how that shakes out in the market?

Gilmour: You're right. If we come back to the Facebook example, Facebook is data that, even if it's data about our known customers, it's stuff that they have put out there with their will. The data that they give us, they have given to us for a purpose, and it is not for us then to distribute that data or make it available elsewhere. The fact that it may be the same data is not relevant to the discussion.

Three-dimensional solution

That’s where I think we are going to end up with not just one layer or two layers. We're going to end up with a sort of a three-dimensional solution space. We're going to work out exactly which chunk we're going to handle in which way. There will be significant areas where these things crossover.

The other thing we shouldn’t forget is that data includes our software, and that’s something that people forget. Software nowadays is out in the cloud, under current ways of running things, and you don't even always know where it's executing. So if you don’t know where your software is executing, how do you know where your data is?

Gardner: That raises the regulatory issues about some requirements for data to reside in some physical location within some boundary. How is that practically managed? It seems like a whole big can of worms, but nonetheless, the top is off the can and we're already into it.

Gilmour: It's going to have to be just handled one way or another, and I think it's going to be one of these things where it's going to be shades of gray, because it cannot be black and white. The question is going to be, what's the threshold shade of gray that's acceptable.

Gardner: Mary Ann, to this notion of the different layers of security for different types of data, is there anything happening in the market that you're aware of that’s already moving in that direction, either from a structured basis or ad hoc, organic in the marketplace, do we have a taxonomy of data types yet? How are we progressing in that direction?

That's the importance of something like an enterprise architecture that can help you understand that you're not just talking about the technology components, but the information.

Mezzapelle: The experience that I have is mostly in some of the business frameworks for particular industries, like healthcare and what it takes to comply with the HIPAA regulation, or in the financial services industry, or in consumer products where you have to comply with the PCI regulations.

There has continued to be an issue around information lifecycle management, which is categorizing your data. Within a company, you might have had a document that you coded private, confidential, top secret, or whatever. So you might have had three or four levels for a document.

You've already talked about how complex it's going to be as you move into trying understand, not only for that data, that the name Mary Ann Mezzapelle, happens to be in five or six different business systems over a 100 instances around the world.

That's the importance of something like an enterprise architecture that can help you understand that you're not just talking about the technology components, but the information, what they mean, and how they are prioritized or critical to the business, which sometimes comes up in a business continuity plan from a system point of view. That's where I've advised clients on where they might start looking to how they connect the business criticality with a piece of information.

One last thing. Those regulations don't necessarily mean that you're secure. It makes for good basic health, but that doesn't mean that it's ultimately protected.You have to do a risk assessment based on your own environment and the bad actors that you expect and the priorities based on that.

Leaving security to the end

Boardman: I just wanted to pick up here, because Mary Ann spoke about enterprise architecture. One of my bugbears -- and I call myself an enterprise architect -- is that, we have a terrible habit of leaving security to the end. We don't architect security into our enterprise architecture. It's a techie thing, and we'll fix that at the back. There are also people in the security world who are techies and they think that they will do it that way as well.

I don’t know how long ago it was published, but there was an activity to look at bringing the SABSA Methodology from security together with TOGAF. There was a white paper published a few weeks ago.

The Open Group has been doing some really good work on bringing security right in to the process of EA.

Mezzapelle: Jim, you may want to talk about the work that we're going to do about integrating the security part of the framework into TOGAF.

Hietala: In the next version of TOGAF, which has already started, there will be a whole emphasis on making sure that security is better represented in some of the TOGAF guidance. That's ongoing work here at The Open Group.

Gardner: As I listen, it sounds as if the in the cloud or out of the cloud security continuum is perhaps the wrong way to look at it. Somebody, I think it was Mary Ann, mentioned lifecycle. If you have a lifecycle approach to services and to data, then you'll have a way in which you can approach data uses for certain instances, certain requirements, and that would then apply to a variety of different private cloud, public cloud, hybrid cloud.

You may come to the conclusion in some cases that the risk is too high and the mitigation too expensive.

Is that where we need to go, perhaps have more of this lifecycle approach to services and data that would accommodate any number of different scenarios in terms of hosting access and availability? The cloud seems inevitable. So what we really need to focus on are the services in the data. Is that fair, Stuart?

Boardman: That’s part of it. That needs to be tied in with the risk-based approach. So if we have done that, we can then pick up on that information and we can look at a concrete situation, what have we got here, what do we want to do with it. We can then compare that information. We can assess our risk based on what we have done around the lifecycle. We can understand specifically what we might be thinking about putting where and come up with a sensible risk approach.

You may come to the conclusion in some cases that the risk is too high and the mitigation too expensive. In others, you may say, no, because we understand our information and we understand the risk situation, we can live with that, it's fine.

Gardner: It sounds as if we are coming at this as an underwriter for an insurance company. Is that perhaps the way to look at it, Dave?

Current risk

Gilmour: That’s eminently sensible. You have the mortality tables, you have the current risk, and you just work the two together and work out what's the premium. That's probably a very good paradigm to give us guidance actually as to how we should approach intellectually the problem.

Gardner: Mary Ann, what do you think?

Mezzapelle: One of the problems is that we don’t have those actuarial tables yet. That's a little bit of an issue for a lot of people when they talk about, "I've got $100 to spend on security. Where am I going to spend it this year? Am I going to spend it on firewalls? Am I going to spend it on information lifecycle management assessment? What am I going to spend it on?" That’s some of the research that we have been doing at HP is to try to get that into something that’s more of a statistic.

So, when you have a particular project that does a certain kind of security implementation, you can see what the business return on it is and how it actually lowers risk. We found that it’s better to spend your money on getting a better system to patch your systems than it is to do some other kind of content filtering or something like that.

Gardner: Perhaps what we need is the equivalent of an Underwriters Laboratories (UL) for permeable organizational IT assets, where the stamp of approval comes in high or low. Then, you could get you insurance insight, maybe something for The Open Group to look into. Any thoughts about how standards and a consortium approach would come into that?

Hietala: I don’t know about the underwriter’s lab for all security things. That sounds like a risky proposition.

Gardner: It could be fairly popular and remunerative.

Hietala: It could.

Mezzapelle: An unending job.

Hietala: I will say we have one active project in the Security Forum that is looking at trying to allow organizations to measure and understand risk dependencies that they inherit from other organizations.

At the end of the day, you're always accountable for the data that you hold. It doesn’t matter where you put it and how many other parties they subcontract that out to.

So if I'm outsourcing a function to XYZ corporation, being able to measure what risk am I inheriting from them by virtue of them doing some IT processing for me, could be a cloud provider or it could be somebody doing a business process for me, whatever. So there's work going on there.

I heard just last week about a NSF funded project here in the U.S. to do the same sort of thing, to look at trying to measure risk in a predictable way. So there are things going on out there.

Gardner: We have to wrap up, I'm afraid, but Stuart, it seems as if currently it’s the larger public cloud provider, something of Amazon and Google and among others that might be playing the role of all of these entities we are talking about. They are their own self-insurer. They are their own underwriter. They are their own risk assessor, like an underwriter’s lab. Do you think that's going to continue to be the case?

Boardman: No, I think that as cloud adoption increases, you will have a greater weight of consumer organizations who will need to do that themselves. You look at the question that it’s not just responsibility, but it's also accountability. At the end of the day, you're always accountable for the data that you hold. It doesn’t matter where you put it and how many other parties they subcontract that out to.

The weight will change

So there's a need to have that, and as the adoption increases, there's less fear and more, "Let’s do something about it." Then, I think the weight will change.

Plus, of course, there are other parties coming into this world, the world that Amazon has created. I'd imagine that HP is probably one of them as well, but all the big names in IT are moving in here, and I suspect that also for those companies there's a differentiator in knowing how to do this properly in their history of enterprise involvement.

So yeah, I think it will change. That's no offense to Amazon, etc. I just think that the balance is going to change.

Gardner: Because we'll get more of an ecosystem of accountability. Is that fair?

Gilmour: Yes. I think that's how it has to go. The question that then arises is, who is going to police the policeman and how is that going to happen? Every company is going to be using the cloud. Even the cloud suppliers are using the cloud. So how is it going to work? It’s one of these never-decreasing circles.

There's going to be a convergence of the consumer-driven, cloud-based model, which Amazon and Google represent, with an enterprise approach that corporations like HP are representing.

Gardner: Last word to you, Mary Ann. Do you see an opportunity here for something new, something quite unexpected, to happen in this market? There are so many questions. Is there a bigger shoe to fall at some point?

Mezzapelle: At this point, I think it’s going to be more evolution than revolution, but I'm also one of the people who've been in that part of the business -- IT services -- for the last 20 years and have seen it morph in a little bit different way.

Stuart is right that there's going to be a convergence of the consumer-driven, cloud-based model, which Amazon and Google represent, with an enterprise approach that corporations like HP are representing. It’s somewhere in the middle where we can bring the service level commitments, the options for security, the options for other things that make it more reliable and risk-averse for large corporations to take advantage of it.

Gardner: Well, great. We have to leave it there. I'd like to thank our panel. We've been joined by Jim Hietala, Vice President of Security for The Open Group. Thank you, Jim.

Hietala: Thank you, Dana.

Gardner: And Stuart Boardman, Senior Business Consultant at KPN. Thank you, Stuart.

Boardman: It was a pleasure.

Gardner: And Dave Gilmour, an Associate at Metaplexity Associates, as well as a Director at PreterLex. Thank you.

Gilmour: Thanks Dana.

Gardner: And last, Mary Ann Mezzapelle, Strategist for Enterprise Services and Chief Technologist for Security Services at HP. Thank you.

Mezzapelle: Thank you.

Gardner: You've been listening to a sponsored podcast discussion in conjunction with The Open Group Conference here in San Francisco, the week of January 30, 2012. I'm Dana Gardner, Principal Analyst at Interarbor Solutions. Thanks again for joining, and come back next time.

Listen to the podcast. Find it on iTunes/iPod. Download the transcript. Sponsor: The Open Group.

A sponsored podcast discussion from The Open Group Conference in San Francisco on what the burgeoning cloud movement means for enterprise security. Copyright Interarbor Solutions, LLC, 2005-2012. All rights reserved.

You may also be interested in:

• Capgemini's CTO on Why Cloud Computing Exposes the Duality Between IT and Business
• San Francisco Conference observations: Enterprise transformation, enterprise architecture, SOA and a splash of cloud computing
  
• MIT's Ross on how enterprise architecture and IT more than ever lead to business transformation
• Overlapping criminal and state threats pose growing cyber security threat to global Internet commerce, says Open Group speaker
• Enterprise architects play key role in transformation, data analytics value -- but they need to act fast, say Open Group speakers
  
• Exploring Business-IT Alignment: A 20-Year Struggle Culminating in the Role and Impact of Business Architecture

Expert Chat on How HP Ecosystem Provides Holistic Support for VMware Virtualized IT Environments

Transcript of a sponsored podcast discussion in conjunction with an HP Expert Chat series on the best practices for service and support of highly virtualized environments.

Listen to the podcast. Find it on iTunes/iPod. Download the transcript. Sponsor: HP.

Redefine the potential of your virtualization investments.
View the full Expert Chat presentation on VMware support best practices.

Dana Gardner: Welcome to a special BriefingsDirect presentation, a sponsored podcast created from a recent HP Expert Chat discussion on best practices for VMware environment support.

Advanced and pervasive virtualization and cloud computing trends are driving the need for a better holistic approach to IT support remediation. That’s why HP has made the service and support of global virtualization market leader VMware a top priority.

And while the technology to support and fix these virtualized environments is essential, it’s the people, skills, and knowledge to manage these systems that provide the most decisive determinants of ongoing performance success.

This is Dana Gardner, Principal Analyst at Interarbor Solutions. To learn more, I recently moderated a discussion with Cindy Manderson, Technical Solutions Consultant for Complex Problem Resolution and Quality for VMware Products at HP. Cindy has 27-plus years of experience with HP and 8-plus years supporting VMware specifically. [Disclosure: HP and VMware are both sponsors of BriefingsDirect podcasts.]

In our discussion, you’ll hear the latest recommendations for how IT support should be done. As part of our chat, we’re also be joined by two other HP experts: Pat Lampert, Critical Service Senior Technical Account Manager and Team Leader, as well as Sumithra Reddy, HP Virtualization Engineer. Our discussion begins with an overview from me of the virtualization market and user adoption trends.

Virtualization isn’t just server-by-server, but really impacts the entire data center. You need to think about it more holistically, particularly in regard to things like security, performance and how your brands and businesses are perceived across the globe. Many of the companies that I deal with day in and day out are up at 80 percent and even 90 percent virtualized.

When they think about virtualization, they go beyond just server virtualization. It’s really now looking at storage, applications, networks and even the end-user desktop experience, or desktop as a service (VDI).

These are all reasons why it’s no longer just about servers, but has to be something that includes how you're looking at IT in general. It’s also a cultural issue. It’s about managing complexity when you get to that 20 percent or 30 percent level, and not letting the value and benefits for virtualization be eroded by a management issue, or complexity around management.

So how to take advantage of the best things about virtualization? Part of that means allowing your IT team to have access to other experienced support teams, from HP and VMware, around the world, 24×7, to help keep systems up and running. Such support also allows your IT team to progress, to learn as they go, and to be able to take advantage of more virtualization benefits over time.

Another thing to consider is that the way your organizations is perceived, not only your IT organization, but your total company, is so dependent now on how your systems perform. It’s really impossible to separate a business from its IT performance. In many cases, your applications are the business. How you present on performance is, in fact, how you present your sense of competency, capability, and your overall brand.

We encourage people, as they pursue more virtualization, to recognize that their web applications, their mobile applications or e-commerce activities all are running on a combination of virtual and a physical infrastructure. These need to be tuned, and performance needs to be considered on an ongoing basis.

Expert panel

So how do you go about attaining such benefits? How do you keep the positive side of virtualization on track? And how do you put in place an insurance policy around service and support? That’s what the HP experts are going to help us understand.

I’d like to introduce one of our chief experts: Cindy Manderson, a consultant for complex problem resolution at HP with 27 years of experience. She’s been supporting VMware products and the ecosystem of VMware for eight years, when VMware came on the scene in a big way.

Cindy is going to provide more insights into how mission critical support works in virtualization, how HP and VMware are working together, and what the synergy between their products amounts to. Cindy, tell us about yourself.

Manderson: Thanks, Dana. I've been in the multi-vendor space for many, many years -- from applications to operating systems -- all with HP.

In 2002, when VMware came on the scene, HP actually became alliance partners with them. In 2003, we became a reseller, and thus began our support partnership with them. It would only extend recent in 2005, we also became an OEM.

We have the largest number of VMware-certified professionals. We're also the largest global VMware off-site training center

We have thousands of trained and certified Microsoft engineers and Linux professionals, too.

But we have the largest number of VMware-certified professionals. We're also have the largest global VMware off-site training center. So HP also does education on these technologies as well. We’ve trained over 20,000 students in the VMware space alone.

And we have had this very strong collaboration with VMware for many years and have support teams around the globe. In addition, we also offer the same level of training that VMware support engineers do. We actually go to their facilities and train right alongside them, too.

We further do this training virtually. The training is then recorded and made available on demand for reference, for folks who are not able to attend a scheduled course. There's definitely a very strong partnership, and as you see from our history with the other vendors as well as VMware, we are no strangers to multi-vendor support.

With all of the VMware products that HP sells, we do provide support across them all. It runs the gamut from the vSphere operating system that will install on the x86 server, through the enterprise management to the vCenter, and virtual desktop infrastructure products like VMware ThinApp. We also support the converter product getting into vCloud Director.

In addition to that, we have the ability to access our peers on the other teams across HP hardware support. This includes servers and storage, and our networking chain. We are quickly able to collaborate with them and pull together a virtual team in to focus on the customer's whole environment, to provide a one-stop shop.

Expertise across technologies

Additionally, you saw that we’ve been in this multi-vendor support business for so many years, with many experts across the other technologies, such as Microsoft and Linux. Of course, the virtual machines (VMs) are running these operating systems. So if the contract is also with them, we can easily pull them in to help us work an end-to-end solution and support it.

Gardner: Let’s think about what happens when there are different levels of support at work. How does that shake-out?

Manderson: We're in a reactive support business. If the customer has a problem, they can either call in at their local region telephone number -- whether they are in America, Europe, or Asia Pacific. There are different phone numbers for them to call.

They can also log in via the web, and they'll get to our next developer Level 1 engineer. They're a great organization and have solved over 85 percent of their cases.

If they have issues where they have to escalate, first they will be collaborating with us. We also have an online chat tool, where we are all in a virtual room, the Level 1 engineers, Level 2 engineers, etc. So we’ll be consulting and collaborating with them before they even get to a point of escalation.

If the case does end up needing escalation, chances are this person that they're already collaborating with will end up taking that case.

If the case does end up needing escalation, chances are they're already collaborating with the first person, and will then end up taking the case. That saves a lot of information transfer, as far as what type of server you have, what’s the firmware, what build level, and what’s the problem there, etc.

Once it reaches Level 2 support, as far as we can continue to collaborate, we can reach our teammates and the hardware teams, too, so we can look at the server and make sure that the environment is what we need it to be. If we can't resolve it, we can also go to Level 3 with VMware at an offline service-partner level.

We have a great relationship with the folks that we work alongside with and would escalate calls to at VMware. We’re obviously not going into Level 1 at VMware because we’ve already done all that work, and we are a service partner. They'll go right up to our peers over at VMware and then we work together, while always owning the solution that we provide back to the customer.

Gardner: And let’s look at this also from the perspective of globalization. So many organizations now just don’t stop in the afternoon and go home. The ongoing problems can’t just be left until the next day. How does it work on a continuity basis, time zone to time zone, region to region?

Manderson: Another part of our infrastructure-as-a-support-organization is that we have a single customer database. I can give an example. A call came into our Level 1 French engineer. When this call came in, for the European folks, it was already the end of their day, and the French engineer could not speak English. It was a critical down, their VMs were offline.

HP Virtual Room

So we worked in a virtual room and they talked to us, and brought the case to us here in America’s time zone. We worked with this case and another tool called HP Virtual Room, where we could actually all look at the customers' desktops in real time. They happened to have EVA storage, and we quickly got an EVA engineer engaged. Of course, we had to find a resource in the Americas because the European folks had already left. So we're all looking in real-time at the customer’s environment and found out that they had locked the storage.

The EVA engineer helped to get back online, while we all watched and the French engineer was translating in French for the customer in order to get it all resolved. We got it back online, and the customers were ready to home.

We gave instructions on getting log files and we placed a call for follow-up for the daytime hours in Europe the next day. So our counterparts in European support teams picked that up and worked with the customers to resolution, to analyze exactly what happened and prevent it in the future.

Gardner: You have a lot of examples at your disposal, I can tell. You've been through a lot with different customers. What sticks out in your mind as a particularly complex engagement that ended up turning out pretty well that might illustrate a bit more about what this takes and what’s involved?

Manderson: A lot of examples I've given have all been involved with the Level 2 support organizations, the HP server storage hardware, and also engaging VMware. There was another case.

Many of the examples that I've given so far are pretty much based on individual incidents. You call in and you get connected to the next available resource.

We have another process in HP that can actually go with top organizations, our escalation manager process. I was lead source for a particular case where we had a field team assisting a customer deploying a virtual desktop infrastructure (VDI) design. They had a third-party VDI vendor. They had HP hardware, servers, and virtual connects. They had our storage, and we didn’t quite know where the bottleneck was. They were having performance issues by trying to have this VDI at two different locations with the hardware at one site.

The escalation manager was able to get the local office to borrow equipment, and then try to get performance and network traces. They had the Engineering Problem Management Resource (EPMR) lab in Houston trying to duplicate the problems.

Our escalation manager was able to drive the issue to completion across not only the solution standards, but the local office, to owning the actual escalation with all the action items to keep this all on track. We knew where we were going to go. That was about a six-month case, but we did finally find was that the customer was on the technological edge, and the "pipe" to have that performance just did not exist.

Many of the examples that I've given so far are pretty much based on individual incidents. You call in and you get connected to the next available resource.

We have another level, mission-critical support, and we have several offerings in this phase. Essentially, it’s more personalized. We know who you are. We already know your environment. You’re going to find a technical account manager.

Redefine the potential of your virtualization investments.
View the full Expert Chat presentation on VMware support best practices.

Site visits

For example, Pat Lampert is a technical account manager and does site visits. The technical account managers do go out on site. So we’re aware of the environment. We have the information of your environment documented into the database. When you call, we’re not saying, "Now what kind of server is this? What’s the firmware?" We know this because we already have it documented. We could be calling them to say, "Server 3 is running a little off." We already which know VMware version this is on, because we have that information.

And because we have that, we can also offer proactive advice. We can know that there's a new firmware update, or VMware just came out with a new build, and we have a place where you can go find the latest that's specific to your environment. So this helps to reduce further incidents, because we can be more proactive to help you maintain your business.

Gardner: Okay, none of these organizations are the same. They have difference legacy, different installations, and different physical-virtualization mixes. How do you manage that sort of complex combination, as well as customize the service delivery, too?

Manderson: Actually, we have a team, our customer service team. Anything that's been not already in our pre-packaged service offerings, we can add. For example, a customer may need their own 800 number for when they log cases. And they may need just an email sent out.

Pat Lampert is one of our our custom technical account managers. He does have additional requirements and possibilities for some of the customers that he is assigned. This way, we can personalize the businesses even more and focus on choosing that business model.

Our critical and independent support includes onsite resources from HP that also include a lot of proactive support.

Gardner: Tell me about the mission critical offerings, and then the whole portfolio.

Manderson: We have several different packages. Our highest level is the mission-critical. In this particular process, you're assigned a team that are across the technology that you have in your environment. But you also get a set of folks who would actually look at not just the reactive support and even some of the proactive, but how actually your entire business is running according to the ITIL standard.

That is coupled with keeping you up and running, and we also can work with you on a type that would be best suited for your environment.

Our critical and independent support includes onsite resources from HP that also include a lot of proactive support. In addition, they're more focused on specific management, but that would be more of an ITSM technology. We can look at that for you.

One of our most creative services would be Proactive Select, a core product series of credits. You can use these credits for maybe planning on migration and upgrade. You can say you need some consulting time. You can use these credits and work with upgrade and migration. You may need some performance or you may need some type of environmental assessment, and these credits can be used for that.

Gardner: When people do employ these services, how do they measure what the payoff is, the value of these services?

IDC study

Manderson: In 2010, IDC did a study. They went out and looked at the methodology, and this is out on our website. They saw that the customers who have the mission-critical services, reduce their downtime by over 70 percent, and increase their return on investment (ROI) quite high, over 400 percent. The main benefit was in problem management as well as help desk calls, because these were alleviated due to the proactive nature, a lot of looking at the entire environment, and looking at the business processes.

So take a look at the study. It shows IDC's methodology. So looking at things proactively and these support processes can certainly help you reduce that downtime.

Gardner: This support extends across a variety of different areas. We looked at the mission critical, we looked at those complex issues, the need for customization. Can you give a quick overview of some of the additional support services?

Manderson: We have the hardware and software support. One of the cool things we have with our hardware support is support automation, our Insight for remote support. That can notify HP that you're having a disk drive failure. Or we will call you and say that we know that disk drive is failing, or something on a buffer server and storage is about to.

You can even take that a step further to look inside at the Windows operating system. We're hardware agnostic on that operating system. We don't care about the vendor -- and I believe we are looking at expanding that automation to other operating systems. We have installation and startup services that we can actually go out and set up and configure the hardware and software at a site.

We're hardware agnostic on that operating system. We don't care about the vendor.

So we definitely integrate across all the multi-vendor services. We run the gamut between all the x86 operating systems, as well as our proprietary operating systems, our servers and storage. Again, we're no stranger to multi-vendor support and keeping the entire environment up and running.

Gardner: We've talked about the need for ecosystem-level view on virtualization. We looked at how HP and VMware have been working together very closely for a number of years, talked about some of the services available, why the experts’ personal experience and knowledge is essential, and the ability then for them to react toward something that’s unique that they haven’t seen before, bring in the expertise when they need it, act as a adjunct to the teams at the sites of these organizations.

And we have heard a little bit about some of the payback, 400 percent ROI, according to IDC. Now let's take this back to the experts themselves. We've heard from Cindy, but there are others involved. Hi, Sumithra.

Reddy: Dana, I'll address two questions that are frequently showing up. One is, what is the difference between the VMware ESXi image and an HP ESXi image?

Basically, HP takes the same ESXi image that VMware provides to the customers. It then adds HP thin components for hardware management, and it also adds any latest fibre channel and network drivers. Once it's tested and certified, it's available for download both from HP and VMware websites.

Major differences

And one of the major difference between the two images is that VMware image is disk installable only, whereas HP image can be installed on a disk, USB key, or a SD card.

The other question we're getting nowadays is how to upgrade from VCA4 to VCA5. As with any major upgrades, planning helps. The first thing I would do is understand the difference between ESX 4 and ESX 5, because starting with ESX 5, we have no service console. So we need to understand what the architectural differences are.

Also learn about the new licensing policies. Then, use the System Analyzer that VMware provides to evaluate the current environments, and download, check, and complete the checklist. Once this is done, hopefully the upgrade will go smoothly.

Gardner: Pat, tell us about some of the other questions and your answers please.

Lampert: Another question that has come up from customers has to do with the added value of getting support directly from HP. It was partly addressed during the presentation we just gave. First of all, VMware does have a fine support organization. I have a couple of friends who work in VMware Support, and they do a good job of supporting their product.

HP, in addition to a similar level of expertise in the product, also offers our expertise in HP hardware, especially if you have systems based on HP Blades. The infrastructure behind that often is tied very closely to the performance and availability of your ESX host. So when you call us, you will have not only someone who is very familiar with the VMware product, but also is familiar with the HP hardware and able to pull in the proper resourced results, problems you might encounter with running vSphere on HP hardware especially.

In addition to that, we have a partnership agreement with VMware, and when you call in for support through HP, you're getting that same level of service when we have to go to VMware to get answers to questions or fixes.

One other question that has come up is about our lab ability to reproduce problems. We have two global labs, one in India and one in the United States. We have several static vSphere cluster configurations with a number of different types of servers already in those configurations, and the ability, when needed, to add specific models, if there is a problem that’s specific to a particular Blade or rack-mounted server model, or a particular card or something like that. So we're quite able to reproduce most problems that come in. We even have some Dell and IBM equipment in our lab also.

Gardner: Back to you Sumithra. Do you have any thoughts on some of the questions that really caught your attention that you think are representative of what our audience is thinking and feeling today?

Reddy: One little question I can answer is how to troubleshoot server crashes. When something goes wrong in ESX, we call it the "Purple Screen of Death." Often, these are results of hardware failure, but we still need to rule out the software. So we collect all the logs, and look at it to see if it's a software issue. If it's not a software issue, then we engage the hardware team to see how we can get to the root cause and fix the issue.

Lampert: To dovetail with Sumithra’s comment there, one of the questions I get frequently is what to do if you don’t have a dump. Say the host hangs, and that seems to be almost more common than the Purple Screen of Death. Some customers are't aware that through HP’s Integrated Lights-Out Management, there is the ability to generate a non-maskable interrupt (NMI) just by pressing a button, and by saving a certain environment variable ahead of time in your ESX host.

KB article

There is a KB article on this, by the way, if you just search on NMI and core dumping in VMware. But with that setup, you can force a dump while a system is in a hung state, and that will assist us usually in troubleshooting and isolating what caused the hang, whether it be hardware or a problem with the ESX host software.

Gardner: Pat, we have time for one more.

Lampert: One question that came up ahead of time is what HP suggests as far as getting a handle on our inventory of VMs? I happened to be involved in field testing some new tools from HP that will be available in January and February regarding vSphere.

One of them is a Holistic Blade and Firmware Analysis that takes into account the VMware environment on our Blade systems which we are working on having ready soon. We have just completed field tests.

And the second is a really nifty Inventory Report HP has just put together. We're just completing field tests on that now. It will be available soon. Basically, we install a small Perl script in the customer environment on any machine that has access to the vCenter host and has a vSphere CLI installed.

This Perl Script crawls through the VMware environment and builds an XML file, which we then feed into a report generator here at HP. This can be used for us to gather information on customers, so we have ahead of time a clear picture of the environment. But also it will be sold as a service to customers.

This Perl Script crawls through the VMware environment and builds an XML file, which we then feed into a report generator here at HP.

The report is really quite nice, with all sorts of charts and showing availability of machines and availability of memory and also disk space. It's a very nice report. You should be able to get a sample, if you're interested.

Gardner: Well, that about wraps up our hour. I really want to thank our audience for joining us. I hope you found it valuable.

This is Dana Gardner, Principal Analyst at Interarbor Solutions. You've been listening to a special BriefingsDirect presentation, a sponsored podcast created from a recent HP expert chat discussion on best practices for VMware environment support.

I would like to also thank our guests, Cindy Manderson, Technical Solutions Consultant for Complex Problem Resolution & Quality for VMware Products at HP; Pat Lampert, Critical Service Senior Technical Account Manager and Team Leader at HP, as well as Sumithra Reddy, HP Virtualization Engineer. And to our audience, again, thanks to you all for listening and come back next time.

Transcript of a sponsored podcast discussion in conjunction with an HP Expert Chat series on the best practices for service and support of highly virtualized environments. Copyright Interarbor Solutions, LLC, 2005-2012. All rights reserved.

Listen to the podcast. Find it on iTunes/iPod. Download the transcript. Sponsor: HP.

Redefine the potential of your virtualization investments.
View the full Expert Chat presentation on VMware support best practices.

You may also be interested in:

• Continuous Improvement and Flexibility Are Keys to Successful Data Center Transformation, Say HP Experts
• HP's Liz Roche on Why Enterprise Technology Strategy Must Move Beyond the 'Professional' and 'Consumer' Split
• Well-Planned Data Center Transformation Effort Delivers IT Efficiency Paybacks, Green IT Boost for Valero Energy
• Hastening Trends Around Cloud, Mobile Push Application Transformation as Priority, Says Research
• Data Center Transformation Includes More Than New Systems, There's Also Secure Data Removal, Recycling, Server Disposal