Embarcadero Technologies' AppWave Modernizes PC Desktops with App Store Convenience

A sponsored podcast discussion of how enterprise app stores can bridge the gap between software development and improved PC software distribution and maintenance. Learn more about AppWave.

Listen to the podcast. Find it on iTunes/iPod. Download the transcript. Get free AppWave download. Sponsor: Embarcadero Technologies.

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

Today, we present a sponsored podcast discussion on the productivity gap between modern software and the aging manner in which most enterprises still distribute and manage applications on personal computers.

At a time when business models and whole industries are being upended by improved use of software, we're also seeing mobility, cloud services, and data analytics. IT providers inside of enterprises are still painstakingly provisioning and maintaining PC applications in much the same way they did in the 1990s.

Furthermore, with using these older models, most enterprises don’t even know what PC apps they have in use on their networks and even across thousands, in many cases, of notebook computers. That means they're also lacking that visibility into how, or even if, these apps are being used, and they may even be paying for licenses that they don’t need to pay for.

So while the software inventory and business service management initiatives are helping along these lines, there's a general lack of control over PC applications. I don’t think you can solve that without including new ways to engage the PC users directly. This is really a function about the use and the users, not just the applications and the PC.

To learn more about how things can be done better, I recently interviewed the President and CEO of Embarcadero Technologies, Wayne Williams, to examine the ongoing problems around archaic PC apps management and how new models -- taking a page from the popular app store model -- can rapidly boost the management of PC applications. [Disclosure: Embarcadero Technologies is a sponsor of BriefingsDirect podcasts.]

Wayne has more than 15 years of experience in founding and leading companies. He was appointed CEO of Embarcadero Technologies in 2007 and he is a former COO, Senior Vice President of Products and CTO at Embarcadero.

I want to welcome you to BriefingsDirect, Wayne. It’s good to have you with us.

Wayne Williams: Good morning. Thanks for having me, Dana.

Gardner: As I said, it’s kind of ironic that, on one hand, we have software taking over in a larger sense how businesses are run and how industries are being innovative in reaching customers in new ways. This has been highlighted recently by Marc Andreessen in some of his writings. At the same time, the corporate PC, also driven by software, is still sort of stodgy and moribund, at least in the perception of how it’s being used productively.

So let’s unpack this a little bit, Wayne. How is it that software is advancing generally, but PCs remain, in a sense, unchanged?

Williams: I've been asking myself that question for many years. I've spent most of my life in software, and I'm embarrassed to say that the industry has really done a poor job at making software available to the users, which is the fundamental issue.

Windows is clearly the dominant PC platform but it has fundamental design flaws, which sowed the seeds for the problem.

Part of the story

But that’s only a small part of the story. Software vendors are so focused on building the next great application and on features and functions in that application that they've lost sight of what really matters, which is making sure that the application that you build gets used, gets in the hands of the users, and that they get their work done.

When I look at the PC industry and where it has come, the applications themselves have improved dramatically. I can’t imagine being as productive as I am without Microsoft Outlook, for example, for email and calendaring. And Adobe Photoshop. I don’t think you can find a photo anywhere that has not been edited with Photoshop. It’s incredibly powerful.

But unfortunately, a lot of the gains that really could be made have been wasted, because it’s very, very tough to get an application from a vendor into a user's hands.

Gardner: It seems to me that while the technology is somewhat unchanged since the '90s, the users are a different breed nowadays. We have different behaviors and different levels of anticipation and expectation around what productivity is all about. We used to call these productivity apps, but now productivity comes from being able to innovate, self-start, even learn from your peers -- that social fabric type of an interplay.

Are these some of the core problems? We're at a dissonance between expectations and behaviors on one hand and the same old local area network (LAN) level of management on the other.

At the end of the day, all technology is about productivity. Software certainly is about productivity.

Williams: Absolutely. That’s a great point. At the end of the day, all technology is about productivity. Software certainly is about productivity. And if you're going to radically increase the productivity of a team, the knowledge that team can share about what tools are used for what job is critical knowledge. That’s why we’ve built in the ability to rate and review apps into AppWave. Team members can find the best tool for the job based on peer feedback.

Gardner: What about this as it applies to application development and deployment? I know that Embarcadero has been involved with that for an awfully long time. Is there something of a disconnect between development, gathering requirements, creating an application, and then the operations, thinking about operations through that adoption pattern, and user expectation and behaviors?

It seems as if we're still stuck in this era, where there's a wall between the two, but some of the activities that you have been up to strike me as trying to close that, or at least create a feedback loop, or a life cycle benefit, between apps, how they're developed, how they're used, and then how they are iterated on.

Williams: There are a few ways to look at it from a development perspective. One way is that software developers are probably the most aggressive in terms of the need for productivity, the most aggressive users of applications and tools and all the issues that surround that.

At the end of the day, software developers, whether at a garage start-up or one of the large software vendors, are passionate about solving a problem, creating software that solves a problem, and getting it into the hands of their users. That’s what really drives developers.

Important disconnect

The problem is that there's a disconnect between creating your software and getting it into the hands of the users. You very rarely are talking about this happening in seconds, which it should. It’s something that happens more on the order of months or quarters in a large company.

Gardner: I have to imagine that this contributes also to the security problems. So many organizations now are really doubling down on what they need to do for security, recognizing that it’s not something you buy out of a box, that it’s really part and parcel of process, methodology, standards, and governance.

There must be some benefits by closing this loop, as you pointed out, when it comes to bringing better security and then making automated changes that bring even better security on an ongoing basis.

Williams: There's a whole host of problems that emanate from the root problem, the root problem that we're talking about, and security is one of them.

You have an environment which is high-friction. It reminds me really of a state of manufacturing before the Industrial Revolution, where you had processes that were slow, expensive, unpredictable, and error-prone. That’s how PC software has operated over the last 20-plus years.

When you have an environment that is so high friction, users will go around it.

When you have an environment that is so high-friction, users will go around it. So you have this process with the PC, where IT tries to get more control and locks down the environment more, and the business users that need to get the work done find ways to get it done.

We have large customers that have a policy: When somebody is hired, all controls are turned off so that they can get their desktop together and get the apps that they need for the first three days. Then they'll lock it down. That’s not a good environment for security.

Gardner: That’s begging for trouble. You mentioned the core problem or the root problem. I wonder if you wouldn’t mind fleshing that out a bit for us. What do you think the real root problem is here?

Williams: The root problem is that software should move at the speed of light, yet it moves at the speed of a glacier.

Let me give you an example. In a mid- to large-sized company, if an employee is looking for a special pen for a new project, they can go to a catalog, take out a pen, and they can usually have it the next day, and that’s a physical good.

Software is virtual. So it could and should move at the speed of light, but for many of our large customers it takes quarters to get software into the user’s hand.

Looking for productivity

Gardner: So we've identified the problem internally. As I said, it's ironic, because when we look to the larger landscape of business, we're still in a tough economic situation around the globe. People are looking for productivity.

Marc Andreessen wrote recently that software is really revolutionizing how we procure things like entertainment and books and how we discover new products and services online. We can do this as a consumer. Doesn’t it seem almost absurd that, at a time when individuals using some of the tools that are available on a retail basis, are leaps and bounds ahead of someone who is just trying to get some basic work done in a large corporation?

Williams: Yes, you can take a fairly simple device like a smartphone from Apple or an Android device and find and run applications literally in seconds. Yet you have this sophisticated environment with hundreds of billions of dollars worth of software sold every year, powerful hardware and processing power, but it's like pulling teeth for a user to get the applications she or he needs.

Gardner: Wayne, you and I have been around long enough to know that the way to instigate change in an enterprise environment is not necessarily to attempt wholesale radical shifts. You need to work with what's in place and recognize that investments have been made and that those investments are going to continue to be leveraged.

So let's start defining the solution at a high level here. We want the applications that have been developed. We want the interfaces and data that folks are used to to continue to benefit them. But we also want to start energizing this new sense of empowerment that people have through their personal lives and their consumer roles and bring some of these things together.

What I see from our big customers is that for every commercial app that they license they will have 10 that are built internally.

Craft for me, if you could, the vision about retaining what's good about the enterprise and what's been invested in and brought to the daily grind, but at the same time start to bring innovation and allow people to exercise their behaviors and their empowerment.

Williams: As far as what's good and what can be retained, there's a great footprint of hardware out there, PC hardware. A massive investment has been made.

It's the same with software. There are tons of software, both licensed and built internally. And the internal part is really important. What I see from our big customers is that for every commercial app that they license they will have 10 that are built internally. And while there is very little visibility into how commercial licenses are used, there is some, but it's little. And there's zero visibility into who’s using internally built software, for the most part.

There have been massive investments made in software, and unfortunately, a lot of the productivity that could have been realized hasn’t been. But the good news is that it can be.

When I look at the opportunities, it's really two constituents, which you described. You talked about the user for a second and then you talked about the investment and what can be reused, and that’s really management, typically IT management, which is centralized. AppWave is about bringing these two stakeholders together.

Gardner: How can we do that? I'm familiar with what you've been doing with developers. Developers have unique requirements, but it seems like you've gained some insight and some technology in serving their needs in a fast-paced, agile environment, and can now bring that to the larger group of consumers within the enterprise.

Removing friction

Williams: If you look at mobile software, the friction between the user and the app is removed, and the results are fantastic. For us, that was a great proof point, because we started on AppWave before anybody had heard of the Apple App Store.

For PCs, the problem is much more difficult and it's much larger. Mobile software is about a $10 billion industry, and PC is somewhere around $300 billion. So the opportunity for productivity gains and overall results is much, much bigger, and the problem is much more difficult. Now, with AppWave the mobile experience -- find, run, rate, review -- comes to the PC. So the agile enterprise has tools to support it.

Gardner: So bringing that mentality of search, discover, share your experience, ease of access when you want to then act on that kind of information, almost instant gratification when the app comes down, being able to run it, and then upgrade it along the way with very little oversight, very little maintenance, certainly very little disruption, you have to ask yourself -- why would I want to do it any other way?

How do we bring these together? How do we bring the app store experience to IT? How do we enable them to bring that to their own constituents, their own users?

Williams: The key is the system. With the enterprise app store we bring two constituents together: users and management.

For users, there are really three principles that drive everything that we do. One of them is self-service, the next is socialization, and the third is instant gratification.

You mentioned a few things that are core principles. For users, there are really three principles that drive everything that we do. One of them is self-service, the next is socialization, and the third is instant gratification.

As a user, when I have a problem to solve and I'm looking for an app to help me solve it, I want to be able to find it myself, quickly. I want to understand what my peers are saying about that app. When I decide I want to try it, I click a button and run it. Everything we do goes through one of those filters. It’s about the user experience.

From a management perspective, for IT they need centralized control and visibility into real usage. So those are two principles that really drive everything we do with AppWave from a management perspective.

People talk about the consumerization of IT now, and initiatives like "bring your own device." The key for IT is to put an environment in place that draws users in and gives them what they're looking for, but you can still maintain overall control and have real visibility into who is using software and when.

Gardner: I'm curious. With AppWave, is there the opportunity to bring down apps fresh, or more frequently than the typical install, lockdown, patch process that we're familiar with now? Is there a hybrid model that incorporates some of the goodness from other trends like software as a service (SaaS) or virtual desktop infrastructure (VDI), but allows the same PC apps, the rich graphical user interfaces (GUIs), the investments that have been made in the code and logic to remain?

Results is conflict

Williams: This is one of the difficult engineering challenges we had, and it goes back to my first point about Windows sowing the seeds of some of the problems. If you look at Windows, it's designed around the concept of sharing and sort of a utopian view, where applications could all share parts, and typically those are called DLLs in Windows. Unfortunately, the end result of that is conflict.

When a user wants to try a new application, that application is installed and will typically conflict with other applications that were previously installed. The problem gets worse when you get into new versions.

In the PC market, most vendors update their software multiple times a year. For example, we put out new release of every major product once a year and then we will have point releases typically quarterly. You have an awful lot of change, and every time there is a change, you stand to break other things that are already installed on your computer.

That was one of the things we had to tackle, and we did with AppWave. That folds into instant gratification. If I'm a user who has an existing version of a particular application, and I need either the older version or the newer version, I should be able to click a button and be productive. I should be using it in seconds.

Gardner: Well, we've defined our problem. We recognize that it's severe. We recognize that the environment is propelling people for change. We know that people have alternatives in the market for at least some apps, and we have been describing some of what is required of a solution, at least at a high level. So I guess it's time now to really dig in a little bit. Describe for us what AppWave is, what it does, and how it came to be?

At the heart of it, we removed the dependencies that applications would have with other applications and with the environment in general.

Williams: AppWave is an enterprise app store for PCs that provides self-service. Users can very easily type in a search term and get a result. The result is a set of applications. Then they can click and run those applications, read ratings and reviews from their peers, and they can be assured that when they do run those applications, they're not going to disrupt anything else that they have on their PC.

Gardner: Tell me a little bit about that problem you mentioned a moment ago, that ability to bring down new or quickly upgrade or change apps, but without losing the config, the importance of the legacy, the use and trail of what that application has done for the user. How did you solve that?

Williams: Years and years of engineering, but at the heart of it, we removed the dependencies that applications would have with other applications and with the environment in general. Each of these applications is able to stand on its own, which means you can have multiple versions of a particular app and move between them painlessly with no concerns.

I think that’s important for just about any knowledge worker. I've seen company after company -- and ours is no different -- afraid to move, for example, to the newest version of Office, because they're not sure if documents from the old version are going to work properly. Problems like that are gone, because you can easily move from version to version with the click of a button.

This is particularly important in R&D,where a tremendous amount of time is spent retooling to go from one configuration of applications for a particular system.

Prior to having AppWave, developers had multiple PCs, one for working on the new release that’s going to come out this year and then one for going back and fixing bugs on last year’s release.

What are the metrics?

Gardner: As you pointed out, Wayne, you've been doing this for some time. A lot of R&D, starting with tools, is probably the hardest category to crack. And you've seen how organizations have adopted and used your AppWave approach, creating this storefront, making those apps available to solve some of these issues that plague PC software distribution.

What have people gained from this? Do we have some metrics? Can we look at some examples? What do you get if you do this properly? How impactful is the shift when you go from say a traditional distribution to an AppWave and an app store distribution model?

Williams: I can give you a few examples. It's been amazing for us certainly. We drink our own champagne. We've made incredible gains, with the biggest gains being in two areas.

One is in R&D, where teams generally produce a daily build of most of the products. Those apps, when they come off the build machine, are now immediately available to all of R&D. It's particularly important for QA, because the downtime that you would have retooling and getting a new app is gone. It’s literally seconds. So we've seen some great gains internally with R&D.

We've also seen it with sales. We've got roughly 20 products. We put out a minor release once a quarter and majors once a year. So if you just looked at the explosion of that set of apps that a salesperson would have to have on their PC, just in two years, it’s 160. That historically has been a problem. It’s just a productivity drain and it’s error prone. Now that problem is gone.

What’s most exciting is when a customer really sees that this can help them get to market quicker.

There are certainly metrics out there as far as productivity and under-utilization of software and over-utilization of software, but I think what’s most exciting is when a customer really sees that this can help them get to market quicker.

A large financial services company had a nine-month rollout cycle for of a new version of a PC app. They had a really pressing business need to get this done before the holidays, their biggest season. It was impossible using their current methods for PC software distribution. With AppWave, users were upgraded to the right version of software in minutes.

The thing that they loved about that whole experience wasn't really the metrics. Certainly they put together their ROIs and they were impressive, but what that really did for them was that it allowed them to move quickly, to solve the business need in a time that would really make a difference.

Gardner: And at a time when software is more important than ever, they're going to gain an advantage by being able to deliver that software, put it in the hands of their employees, and also put it in the hands in the market, learn from that market and adjust, it just seems like you get generally better business agility, particularly when you are in a software intensive field which, as I said, most companies are nowadays.

Williams: One of the things that's frustrating for me, seeing how the software industry has matured and grown over the years, is that everybody talks about ROI. There's nothing wrong with the concept of ROI, but what I see often is a forest-and-trees problem, where people will lose sight of what the real goal is.

Losing sight of the goal

They will get so buried in a metric here and a metric there to build up an ROI, that they will lose sight of the goal. What’s the goal? The goal is to get my product or service to market sooner, better, and with better quality than the competition. That ROI is almost immeasurable.

Apple is a great example. This is a company that was in serious trouble for a number of years. It's the most incredible turnaround success story than any of us have ever seen. And all of that may not have happened if the iPod was a year late. Sony wasn't totally sleeping. They owned consumer electronics, and given a little more time, they probably could have stopped that move.

It’s so important for people to remember that software is going to help you get your product or service to market sooner and better, which is going to help you beat your competition.

Gardner: I'm afraid we are about out of time, Wayne, but I wanted to look just at a couple of the building trends now that point to the future. We're seeing tremendous uptake in mobile devices and tablets. We're seeing people who want to be able to combine their roles as consumers and individuals at home with what they do at work.

This is blurring the lines between on-premises, doing work within a corporate environment, or over a VPN even. But they need this. This is how they're going to be productive. It's putting an onus now, a different level of requirements, on IT, on developers.

It's all about getting the right app in the hands of the user as quickly as possible and that should happen on all relevant platforms.

Is there something about AppWave and what we've been talking about that can be brought into the mobile and even cloud spheres, these trends being sort of locomotives in the market right now, that brings together them and what we have been talking about?

Williams: Absolutely. Our view is that, at the end of the day, it's all about getting the right app in the hands of the users as quickly as possible and that should happen on all relevant platforms. So certainly mobile tablets, Android tablets, and iOS, iPads, are very cool and powerful devices that we are certainly going to support.

The important thing to remember is about getting the app to the user, regardless of what device they're using. So whether it's a tablet, a PC, or it's their own PC, as opposed to the company PC, they should still have access to all the apps that matter, with all the same kind of principles we've talked about, instant gratification, very easy to find. Those are all things that we're covering in AppWave.

Our initial focus was all about solving the PC problem, because in my view that’s the big problem. That’s where so much productivity has been locked away. We've solved that for the PC now and we certainly will support other popular platforms as they emerge.

Gardner: Well, very good. I hate to say we will have to leave it there.

You've been listening to a sponsored podcast discussion on how enterprise app stores are quickly creating productivity improvements and speed the value benefits for those PC users and across the applications that they are accustomed to. This is something that’s been of interest to IT departments and those users as well.

I'd like to thank our guest. It's been a very intriguing discussion. We've been with Wayne Williams, President and CEO of Embarcadero Technologies. Thanks so much, Wayne.

Williams: Thank you, Dana. Have a good day.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions, as always, thanks for listening, and come back next time.

Listen to the podcast. Find it on iTunes/iPod. Download the transcript. Get free AppWave download. Sponsor: Embarcadero Technologies.

A sponsored podcast discussion of how enterprise app stores can bridge the gap between software development and improved PC software distribution and maintenance. Learn more about AppWave. Copyright Interarbor Solutions, LLC, 2005-2012. All rights reserved.

You may also be interested in:

• Take a Deep Dive on How Enterprise App Stores Help Drive Productivity
• Enterprise App Store Trends Point to Need for Better Applications Marketplace for ISVs, Service Providers, Mobile Business Ecosystems
• App Stores -- They're Not Just for Consumer Any More, as More Enterprises Adopt the Model To Support Mobile Applications
• Embarcadero Brings Self-Service App Store Model to Enterprises to Target PCs and Their Universe of Software

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