New Era Enterprise Architects Need Sweeping Skills to Straddle the IT-Business Alignment Chasm

Transcript of a sponsored BriefingsDirect podcast on the role, qualifications, and career paths of enterprise architects. Recorded at The Open Group's 23rd Enterprise Architecture Practitioners Conference and 3rd Security Practitioners Conference in Toronto.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. 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 coming to you from The Open Group's 23rdEnterprise Architecture Practitioners Conference in Toronto. [See a related discussion on the effect of cloud computing on the architect role.]

Our topic surrounds the issue of the enterprise architect (EA) -- the role, the responsibilities, the certification, and skills -- both now and into the future. The burgeoning impact of cloud computing, the down economy, and the interest in projecting more value from IT to the larger business is putting new requirements on the enterprise IT department.

So who takes on the mantle of grand overseer as IT expand its purview into more business processes and productivity issues? Who is responsible? Who can instrument these changes, and, in a sense, be a new kind of leader in the transition and transformation of IT and the enterprise?

To help us sort through all of that, we're joined by our distinguished panel. Please join me in welcoming James de Raeve, vice president of certification at The Open Group.

James de Raeve: Hi.

Gardner: We're also joined by Len Fehskens, vice president, Skills and Capabilities at The Open Group. And, David Foote, CEO and co-founder, as well as chief research officer, at Foote Partners. Welcome.

Foote: Thank you.

Gardner: And Jason Uppal, chief architect at QRS.

Jason Uppal: Thank you.

Gardner: Well, let's look first at this whole issue of the down economy in the changing environment. Let me take that first to you, David. What is afoot, if you will, in the field? Why so much change all of a sudden?

Always in flux

Foote: We're always in flux. There's no doubt about it. There's no doubt about the fact that, when money is scarce, people get scared.

You have a lot of very frightened IT departments out there and a lot of frightened business lines with customers bailing out right and left. Everybody is just focused on the moment, thinking reflexively on how do we possibly save money. How do we renegotiate our vendor contracts in IT? How do we not lose customers? This is probably the thing I hear about the most.

IT does not want to be in a position of being responsible for the loss of market share in any way, because the business loves to blame IT, as you know, for a lot of things -- most recently, challenges to market share and revenues.

But, it's the greatest time possible to be talking about things like enterprise architecture (EA) and transformation, because transformation tends to happen in times like this. It tends not to happen in times of prosperity.

As I've been telling everybody, this is the greatest opportunity you'll have personally in your career, if you're a manager in the management ranks, and especially as an executive, to start raising issues that you were afraid to ask for. These are those plans that were shelved at times when you were making so much money that nobody was listening to your conversation. Right now is a tremendous opportunity. I want to be very positive about that, because you'll probably hear about some negatives today too.

Gardner: Let's go to James. Why are these forces around us forcing the change on the definition of the enterprise architect?

De Raeve: There's been a realization, hopefully a growing realization, that the term enterprisearchitect means something different to everybody who uses it. In this time of increased pressure and constraints on budget and focus on results, there's ever-increasing need to have more coherence and more commonality and the idea of what EA is as a discipline, what it should be as a profession, and what skills and competencies enterprise architects need to display in their job to succeed.

Gardner: Moving from a mismatch of definitions and application of EA, to a more standardized approach or perhaps more fragmentation?

De Raeve: I think there is increasing convergence. There is increasing realization that there is a need for a common understanding. I wouldn't say a standardized approach, because you don't have standardized problems and people aren't standardized, but there is a growing realization of the need for common core skills and competencies.

What the members wanted

We develop certification programs, but the reason we do it and the reason we have one in the architecture space is because that's what our members wanted us to do. They want us to do things for good, commercial, self-centered reasons. As organizations, they need this kind of concentration and increased commonality of understanding of skills and competencies.

Gardner: Well, if we're not moving towards a standardized definition, perhaps we're moving to a more strategic role for the architects. Is that fair?

Fehskens: That's always been the case. In many respects, strategy is sort of the lastfrontier. One of the things that I've seen over my career in architecture is that the focus of architects has moved up the stack, so to speak. Initially the focus was on rationalizing infrastructure, looking for ways to reduce cost by removing redundancy and unneeded diversity. It's moved up through the middleware layer to the application layer to business process, and now people are saying, "Well, the place where we need to look for those kinds of benefits is now at the strategy level." That's inevitable.

The thing to understand, though, is that's it's not moving forward in a linear front across the entire industry. The rate of progress is locally defined, so to speak. So, different organizations will be at different points in that evolutionary path.

There are still organizations where the primary role of an enterprise architect is, in fact, to rationalize the infrastructure. On the other hand, we're starting to see lots more places where they're playing a major role in strategy development.

Gardner: As we move up the abstraction, based perhaps on the maturity of the technology and its importance and its role in the larger enterprise, do we see a stratification of sorts among the architects? If so, how do we rise up this pyramid to more of an über-architect, if that makes sense?

Fehskens: There is some stratification. Again, the people working at the highest levels are not going to be making decisions at the lowest levels, they have to pass those decisions down the chain. They may get passed down and passed down. So, just as we talk about a layered architecture, there is a layer of architecture of enterprise-wide responsibility at those various levels in the overall stack.

This gets into a lot of interesting questions about governance, as a result of this. The ideas of architecture purveyed organizational structures from the bottom to the top. Issues of governance are going to become increasingly critical. You talk about the change in the skill profile. A couple of years ago, governance was something that an architect could get by just knowing about.

Now, an architect has to have full-blown competence in the governance area -- how to turn it into decision-making and implementations that conform to the architecture, both across the enterprise and then vertically through this structure of architectures that go down from the strategy level.

Gardner: Jason, one of the least comfortable positions is to be responsible for something, but without authority. How is the role of the architect from your position as a practitioner reaching up this stratification towards a higher level of strategic overview, but gaining authority at a commensurate rate?

Protecting their turf

Uppal: Several things have happened. Especially in the economic downturn, there are a lot ofpeople who are very sensitive and are afraid about their positions and the power that they have accumulated. Or, it's just the normal nature of protecting their own turf.

As role of the architect starts to ascend in the organization, an acceptance has place to some degree, but it also made a lot of other professionals very nervous about what we do. In this day and age, do you have to be very good at what you always did in the rationalization technology, doing this and doing that, and you also have to be very much almost a priest-like sensitive person so that you don't trample on somebody's feelings.

Another layer that I saw come into architect skills in last 6-12 months is how you make sure that you don't trample somebody else along the way, because, without them, you're not going to go very far. Otherwise, they're going to throw a lot of stones along the way.

So, that's another a huge challenge that we have from skills of the architect as you're going up -- considering everything else, but having this soul who would be sensitive to the other professions that are going along.

Gardner: Is it fair to say that the skill set of an architect, at perhaps a solution level or a technology level, is quite different from the skill set at that higher strategic level you mentioned, a priest-like bearing? How do you transition when the skill sets are different?

Uppal: Well, you need those skills at lower level. Those are just part of the game. They are no longer sufficient for you to do your job. Now, you have to have all of those skills, plus on top of it, you have to have more, and that's where it's more of a challenge for the architect, as we're going up. We're being accepted when we go up, but if we don't succeed there, being insensitive to all those other issues around, we will be sent back very quickly.

Gardner: David, what are you finding in your practice in terms of how people are grasping and grappling with the transition from a high level of technical skills to this more collaborative people type of skill set?

Foote: As I was talking about yesterday, I see so many parallels between the maturation of the CIO job with what's happening in EA.

Basically, true EA is a collaboration between the company's executives and everyone who works for them -- and they pay your salaries. They tell you when you are an enterprise architect. You don't tell them. They will tell you. They will put their arm around you and say, "You are one of us."

You're one of us

At the same time, you want the IT organization having their arms around you, saying, "You're one of us." The moment they tell you you're an architect is when you are an architect. At the moment, what Jason has said is really true.

In the total group of enterprise architects I've met, to a T, every one of them was a great communicator. They were able to really make people feel comfortable around some very abstruse, very abstract, and, for people who are not technical, very technical concepts. They just could communicate. They could set people at ease. They were nonthreatening, and by the way, most of them, I think, were really close to genius or über already.

You have to be über level to be an enterprise architect at this stage in the game, because there really isn't a good role description. The model would be what's happened with project managers. At some point, IT was trying to just teach them so much about project management, how good it was for the organization, much like architecture.

But, at one point the CFO learned that project management can really help me to integrate companies that we're acquiring and merging with. The moment the business discovered it, it was no longer an IT sort of discipline. It was a business corporate competency.

I would love to see that happen to architecture, to be just a natural corporate competency, so that IT could just give it away.

That for me really encapsulated the communications goal for an architect -- to make points about these complex issues so clear that people understand them and feel comfortable with them.

The greatest thing in the world is when you just give something away that you introduced and the business adopts it as if you never even gave it to them or you never really were at conferences like this. Where are the business people at this conference? Well, maybe five years from now they will be here -- the MBAs are whom I'm talking about.

Fehskens: Dana, if I might elaborate on something David said. I had a real "aha" moment. Before I came to The Open Group, I was the worldwide profession lead for the architecture profession at HP Services. One of the architects who I worked with on a fairly regular basis told me that the most satisfying moment in her career was when one of her clients told her, "You make me feel smart."

That for me really encapsulated the communications goal for an architect -- to make points about these complex issues so clear that people understand them and feel comfortable with them.

Gardner: I've heard IBM, in several instances, refer to the architect as having to be a team person and to have deep technical understanding and then horizontal understanding of the business. I want to put another axis on there for those people skills, and to be sensitive and effective in communication. These are very challenging roles, but if you can fill them, you might have yourself one fine career.

James, how do you position yourself to get into this? What's required, and what's the stepping-stone pattern in order to achieve this very fine challenging and well-paid position?

Community crying out

De Raeve: I think what you're asking for is the universally agreed professional framework for the enterprise architect, and I'll give it you the moment we have it.

The community is crying out for it. They may not know that they're asking for it, but they're asking for it. One of my things is that I have to go and sell our certification programs to people. So I visit a number of different organizations and explain what we're doing and what it means.

I've come away with the firm conclusion that we're way too soon in that process. They don't yet have methods of developing, growing, retaining, and managing their people and organizing them as professionals. They've got job definitions and all kinds of stuff from HR, but nothing that actually enables them to develop their architecture practice.

I go along with the idea of, "Well, here are all these criteria that a good competent architect should have, all these things about communication skills and architecture skills and technical knowledge, this whole panoply of stuff, and all of the experience." They say, "That's great -- if I knew whether we had anyone like that, or if I knew how to develop people like that, but we haven't got all of the rest of it."

My analogy is that we've got these certification things there, the cherry on the icing on a cake, but we don't have the icing and we don't have the cake. We need the professional frameworks that help organizations attract, develop, grow, and build these people into professionals. I think it's a gap.

Gardner: Len, you had something?

Fehskens: Yeah. I think one of the real challenges for an individual who aspires to be an architect is to get past the first hurdle, which is, you're usually not allowed to be an architect until you already are one.

Often, one of the ways you can get your foot into the architecture space is by taking on the responsibilities of program manager and acting like a program manager.

In my experience, all the people who started in this profession started acting as architects before somebody was willing to call them one, and that requires networking with architects who are willing to spend some time mentoring you and stepping into the architect role in complex projects.

In the architecture group at Digital -- Digital got acquired by Compaq, which got acquired by HP -- we used to joke that if you had a program without a program manager, the architect filled that role. If you had a program without an architect, the program manager filled that role.

There's a lot of symmetry between the program manger role and the architect role. Often, one of the ways you can get your foot into the architecture space is by taking on the responsibilities of program manager and acting like a program manager. Then, pushing that into the technical domain and starting to act like an architect.

When you start acting like an architect, as Dave pointed out, you're not really one until they tell you you are. But, you have to look like one before they will tell you you are one. The best way to do that is start behaving like one, and best way to do that is to learn by experience. You just put your foot in the water and go for it. As Nike says, "Just do it."

Gardner: So Jason, if this is an experience-based rather than a certification or rigorous predefined process towards architecture position, what is it that you've done in this experience side that allowed you to actually get in and convince people to give you the authority? How do you manage that transition?

Managing the transition

Uppal: That's an interesting question, and Len left it wide open for me to respond. Before Len called me an architect, about four-and-a-half years ago, I was an engineer for the longest time, and I worked as an engineer. That's your job. Nobody told you you were an architect or project manager. That was your degree and that was your title and that's what you did.

But, somewhere along the line, somebody came around and said, "Here are the performance criteria. If you pass all of these things, and we agree that you pass all these things, we'll call you an architect." That's what happened, Len called me an architect, and I became an architect that day.

Going back to "developing the skills" conversation -- how you got here -- if we step outside of the IT industry, you'll see a lot of parallels of other professionals being developed in the industry, very similarly to how we develop architects. Architect is not this nebulous thing that just grows. They are developed.

I remember when I first started working as an engineer. I worked for a French tire company.

All of that stuff that they taught you -- respect for the person who is doing the work -- still applies today as it did before.

We won't name any names, but one of the biggest challenge that they had is that it was a dirty job. Nobody wanted it. So they'd go to universities looking for engineers, bring them into the company, and teach them how to do the job. They would stay there six months and they would leave. That was not necessarily a good attrition. They had close to 100 percent attrition of the newly hired engineers.

Then, they looked at the skills of the people that they were trying to develop and they said, "We need to have people who understand our culture, our product, and our people. Then, we just need to give them some technical skills on how to do analysis."

That was an easy thing to do. So, we created an apprenticeship program. Since then, that organization has developed hundreds and thousands of industrial engineers who are continuous improvement engineers who know how to do things. I came out of that process and became an industrial engineer. From that I became an architect, because I had an affinity for applying information technology.

All of that stuff that they taught you -- respect for the person who is doing the work -- still applies today as it did before. That's one of the areas where, if we want to develop architects in IT, we have to step outside of IT into some of the other areas and learn from it. If you can somehow figure out how to show respect to the person who is doing the work today, we have a much easier time in developing the architects.

Gardner: David Foote, we could leave this to an organic process -- willy-nilly and ill defined -- or, to Jason's point, we could follow the lead of other career tracks. In other career tracks, it's not just the people that fill the positions who are involved. We have human resources (HR) departments, recruiters, and headhunters. In fact, you might have an entire industry setup in order to find, cultivate, and place people in these jobs. Why haven't we seen that with the enterprise architect?

Lack of understanding

Foote: Again, people really don't know who enterprise architects are. As much as you try, try, and try, you haven't reached the critical mass where the average HR department person, at least that we talk to -- and we talk to thousands of them -- really understand what they are.

What they think architects are is a title that all people in IT want to have, so they will get a better job offer. They know that architect is a hot, hot item. Just Google it, or go to anyMonster site or Dice or any of those. They make a lot of money. So what's happened is, without really grabbing hold and defining the architect, they've let the IT organization simply hand out these titles to people as a way to attract them to the organization.

The worst thing that you ever want to have happen to you in HR is the CIO to say, "Okay, we now have a solution architect in this area, whether we had one or not, we have one now. So, go and figure it out." That lack of control in HR is commonplace today. I tell HR organizations that if that's the question they have, send the best people.

You should have a representative to the HR organization that was selected by the CIO or the IT management there to represent them to HR. That person should be the person who advocates also for HR, so that they never are handed job descriptions that do not exist in the company. Then, a compensation person tries to figure out what to pay that person.

That's when they come to Foote partners, saying, "We don't know what to do?" What do we pay this person?" Call them whatever you want, but I can tell you what that solution architect should be making in your town.

You're probably going to be continuing to hire in this area. It might be a good time to just establish this as a job family, and then make sure that this doesn't happen again.

But, this is a workaround solution. Eventually, you're going to have to actually ordain this job, if you think you're going to have several of these in your company, I said, probably you will have. Let me talk to your IT department. If I talk to them I'll say, "You're probably going to be continuing to hire in this area. It might be a good time to just establish this as a job family, and then make sure that this doesn't happen again."

Mainly the lack of control is around job descriptions. Compensation is more egregious in architecture right now than it is in developers, database people, security people, and even voice engineers. They know what a voice engineer is more comfortably than an architect. So, it's just this natural progression.

But the last thing I want to say is, people still don't know what CIOs are. CIOs make anywhere from $25 million a year to $80,000, in our salary surveys. What a crazy job title. Yet, we've been able to exist very well with CIOs for any number of years.

Gardner: I was going to say, James de Raeve, this sounds a lot like what I heard in the CIO category ten years ago, where it was amorphous, and the skill and compensation scales were all over the map. But, over time, what became sort of a hot potato ended up being a very important role that most organizations seem to understand. Should we expect a similar track?

Early stage of maturity

De Raeve: Oh, absolutely. We're at an early stage in the maturity of this concept in the profession or in the industry. One of the roles of organizations, such as this, this community of people, is to try and help us evolve that, to get an understanding of what we mean by it and an understanding of how organizations should address this problem and develop their people. I think it's inevitable. We've got a long way to go. Maturity is needed, and we're in the very early days.

Gardner: Well, does it make sense then to look at the CIO role and say, "Here is what an architect is vis-à-vis it or in contrast to it. Is there a relationship that would help in this maturity process?

De Raeve: I'm not so sure that CIO is the right model. Maybe CTO would be a better match. But as the profession matures, we're also seeing enterprise architects become less technically focused and, as we talked about earlier, more strategically focused and more concerned about the business and less about the technology.

So, there is something to be learned by looking at how those professions developed, but I don't think the specific details of how they sorted themselves out apply directly to enterprise architects, because I think it's enough of a different role.

We used to joke that the best architects have their feet on the ground and their head in clouds,

The other thing is that architects are, by their nature, extremely adaptive, and they redefine themselves to fit into where there are gaps in the organization where there are needs.

and they span this gap from the business side to the implementation side, regardless of what the implementation technology is, not necessarily just IT. It's that extremely broad coverage that makes it really difficult to pin this discipline down and say it's just this.

I've often told people that I've tried unsuccessfully many, many times to tell my family what it is I do for a living. After a couple of sentences, their eyes just glaze over and they say, "Well, you drive a nice car. So, you must be successful." We've got that problem in general, as David pointed out. HR can't get their arms around it, because it's such a vaguely defined thing.

The other thing is that architects are, by their nature, extremely adaptive, and they redefine themselves to fit into where there are gaps in the organization where there are needs. They reshape themselves to address those needs. So, we're sort of like chameleons or shape-shifters, depending on what the organizational context is.

If you've got a whole bunch of people doing that, it's very hard to say, "You people are all basically performing the same role, because it will look different in some respect. See one person do it. It's even worse. So the only thing you could do is say, "Oh, shape-shifter, some kind of a magician."

Gardner: What strikes me that, if the role of the architect is so different from organization to organization that the org chart within those organizations is also very different, and we might have the architect reporting to different types of individuals from enterprise to enterprise. So Jason, among the architects that you know, is there a great variability in who they report to, or am I reading this wrong?

Based on behavior

Uppal: Who architects report to depends on how they behave. There are a lot of architects who behave like technocrats who report to the CTO. There are other architects who operate at a different level and they start reporting to the CIO, the CFO and even to the COO level. I know one very successful architect, he reports to the CEO, along with the CIO.

It's more how that group behaves, and also their EA practices maturity within the organization dictates how they behave and whom they report to. It has a lot to do with the maturity of the practice. In some of these organizations, the maturity of the practice depends on the maturity of the individuals. A couple of them are leading it, because as soon as you take them out of this thing, the whole thing is going to fall apart, because there is no talent in the organization to repeat it.

Foote: Let me add one thing to that. One of the things that we're not looking at is, there are a handful of industries -- it's becoming a much larger group now -- where the CIO and the COO are the same job. You see this in banking, financial services, and insurance. You're seeing it in healthcare. You're seeing it in education, in particular. Now, you're seeing it in retail and all these other places.

Those organizations, where the CIO and the COO are basically the same person, are the ones where you really see these hybrid enterprise architects that really are business/IT. When you meet them, you can't really tell.

A couple of them are leading it, because as soon as you take them out of this thing, the whole thing is going to fall apart.

A lot of it has to do with whether you are working in a company that has this hybrid, where the operations are under the control of a CIO, whether they have that title or not. Usually, they are vice chair, or they just call them an executive vice president or a senior vice president, as we've seen it in the United States. Usually, CIO is not the title unless they're speaking at a conference, but CIOs are separate. It's really important to understand, again, what kind of organization model you have and who is at the top?

Gardner: So, if we have a hard time standardizing the job of architect, perhaps we need to start at some standardization around the organization and the org chart. Is there an accepted methodological approach to setting up the IT department in the context of the business requirements, goals, and so forth, or are we still just sort of thrashing around in a storm, hoping to grab onto some life raft?

Anybody want to take that question? How do we mature the organization, not just necessarily the architect?

Fehskens: First, I'm not sure that standardization equates to maturity, but, again, it's this question about adaptability. My experience is that most organizational structures, at least with respect to who is in what job, have a lot more to do with politics and social chemistry than explicit engineering-driven design.

Gardner: But, aren't these really too important subjects to leave to the vagaries of personalities and popularity contests?

Ability to get along

Fehskens: You'd think so, but the reality is that if you have a perfectly rationally structured organization, and the people that you put into these roles are perfect for those particular roles, but they hate one another, it's not going to work. A feature of a successful architect is the ability to get along with everybody, including people that we would call uncharitable names, and just find some way to work successfully with them.

My attitude about architecture is pretty much that most of the stuff you have to deal with, you have no control over. So, you just have to accept it and figure out how to deal with it and cope with it. You pick your battles wisely and don't waste time trying to change things that you can't change. My experience has been that an awful lot of organizational structures are pretty much cast in concrete, and changing them to be optimal is very, very difficult. So, you just have to figure out how to cope.

Foote: The most frequent question we get right now from companies that have fairly advanced EA groups, is, "Where do I promote these people to?" In other words, they usually don't want to be in management, because they are too hands-on. Their next shot is really to be a director-level manager.

We've been coming up lately with a lot of interesting cases for where they go. They have a great organization, but they never planned for these architect/analyst types, and these are companies where the architects are really doing long-range planning. They're doing a five-year plan, and, usually, we a lot of Silicon Valley, Calif. technology companies is where we find these people.

Gosh, as the challenges of the environment are just going up and up and up, the organizations rely on their architects to be sufficiently flexible to be able to change shape, to adapt, and to adjust.

They're out there doing the strategic planning. The CIO is head of strategic planning in these companies. Maybe not in your company, but they don't know what to do. We just say, "Well, you create a distinguished engineer title or a distinguished architect title, and put them on the road. They should be evangelizing. They should be helping you build market share, not just the strategic plan. Put them out as marketers for the company, and they will probably do very well."

Gardner: How about putting this in the context of some of the other impacting trends in the industry -- ITIL, for example? Changing the character of the IT department from a cost center to a productivity center, a shared-service provider, a partnership in the organization, rather than some ivory tower or dark arts center. Doesn't that provide a springboard for the role of architect, and wouldn't that perhaps lead to maturity more than we've seen in the past? James.

De Raeve: Gosh, as the challenges of the environment are just going up and up and up, the organizations rely on their architects to be sufficiently flexible to be able to change shape, to adapt, and to adjust. So, yeah, I that's the driver, absolutely.

Gardner: External forces like ITIL and shared service, Len, are these going to add to more complexity and more chaos, or is it going to be more of a focusing impact?

Just do it

Fehskens: I tend to think it's the latter. Those kinds of things are a special case of commoditization, which is that after something is well enough understood that there really are, if not just one, at least a very small number of sensible ways to do it, you don't have to spend a whole lot of time thinking about it anymore, you just do it the right way.

We don't spend a whole lot of time each morning trying to figure out how to get dressed. You put your underwear on first, hopefully. Doing it any other way doesn't work. We've gradually learned those things about various aspects of the IT organization and of the organization as a whole.

So there's a whole lot of stuff that gets standardized, because it's appropriate to standardize it, because there's really no value in gratuitous variability anymore. It just makes sense to do it, get it over with, and do it the most efficient way possible. That stuff all generally becomes candidates for outsourcing.

The really interesting question becomes, what do you keep? Where is the stuff where that variability, that customization really makes sense in delivering strategic value to your organization?

One of the things that scares me sometimes about standardization is that premature standardization can be a real catastrophe.

Knowing what stuff you can safely commoditize and ultimately outsource, and what stuff you need to keep close to the vest is a really important decision that companies have to sort out. I think it will vary from industry to industry, and people just have to make smart decisions about that set.

One of the things that scares me sometimes about standardization is that premature standardization can be a real catastrophe, where you make things the same that really can't afford to be the same yet, because that's an opportunity for competitive differentiation. Every time you take away one of those opportunities, you close down your opportunities and the space that you have to move in and you limit your options. So, you have to be very smart about that stuff.

Gardner: We have a question from our audience, and it revolves around the outsourcing word that you brought up, Len. Isn't this all similar to the old role of management consultant? It begs further question of, is this something that, perhaps in a transitionary period like we're in, is best done from the outside?

Jason, what do you think? Is the role of architect something you should outsource, at least for a period of time?

The role of outsourcing

Uppal: That's an excellent question. There are a number of organization that I'm aware of that have actually flirted with the whole idea, because they are fairly good at ITIL and they are fairly good at COBIT, PMI, and all that stuff. At the same time, when they tackle a very fundamental issue for the organization, how to reengineer their entire business process, they don't have anybody in the organization who can step up to the plate and do it.

They have a hell of a time running a million dollar project, let alone running 10, 20, 50 million dollar thing. At that point, they started thinking that perhaps they should outsource this thing and bring somebody else from outside.

Then, they have another dilemma and say, "We decided fundamentally architecture is our internal competency and we have to have somebody internally." Then, they stick in this guy who has no idea about what to do with this thing, and the next thing is the whole thing falls apart. Then, they say, "Well, we did the architecture thing, and it doesn't work.

One of the things that we found is that a number of architectural activities that they thought they were uniquely theirs, are commodity.

Some of the organizations are going to do that first part, bring somebody from outside for a short period and get them started to understand the value of it and also understand what is it going to take for them to institutionalize that practice. Then, they'll take the next step, building their own capacity and capability, only to the point that they need to build.

One of the things that we found is that a number of architectural activities that they thought they were uniquely theirs, are commodity. They didn't have to have them. If you're implementing SAPor Oracle, do you really need to own a SAP solution architect in-house? How many times are you going to implement SAP in house? That's a commodity that exists out in the marketplace.

Those are the kind of things that organizations have dealt with. Bringing somebody from outside for a short time is critical, but also understand that it's a short time. Don't turn that consultant into your staff over the next two years. Then, you're just paying a lot of money for this person who should be an employee. That consultant becomes very useless in about two years, because he knows nothing other than your organization.

Gardner: David Foote, what's your position on this insource, outsource, or hybrid approach?

Foote: There are definitely some activities in architecture that you can't outsource. I wouldn't say that you can't outsource it, but most companies that we talk to say, "We like our architects. They've done very well, because we trust them. The business trusts them. We trust them. They are good channels of communication. They've opened up a lot of thought in our company. We'd really like three times more of these people. How do we accelerate the growth internally?"

Keeping core competency in house

They want to know how they can develop architects internally, because they know that they're not going to get that same quality. Now, these are people who are architecting out of that very delicate core competency, strategic level that you don't want to share with outsiders -- for a lot of reasons.

By the way, one of the things that we talked about when populating the panel is that I said I had an interesting experience at a conference, where they had a headhunter on that did chief security officers. But, I've never met a recruiter who specialized in architects. I don't know that those recruiters exist. They probably don't, because there isn't a lot of demand on the outside for hiring architects.

One of the big differences between management consultant and enterprise architects is that what you put on the table, you have to execute.

I do think the architects that I see that are brought in from outside are often consultants, formerly of Accenture, IBM, CSC, or one of the large houses. They are brought in basically to calm down the chatter, to educate, and train. They're there to cleanup a fire, to calm things down, get people on the same page, and then go. Sometimes, that's the best way to bring in an architect.

Gardner: To the point of the question here, that does sound a lot like management consultant. James or Len, what's your position on that?

Fehskens: In a couple of conversations that I've had with people about where we seem to be evolving the role of enterprise architect, they have said basically, "Yeah, these people are going to become in-house management consultants and they're going to be better for that. They're going to know your business intimately, because they're going to have participated in strategic evolution over time."

There is a lot of merit in that analogy and a lot of similarity. I think the only difference is that what we're trying to do with EA is bring more of engineering rigor and engineering discipline to this domain and less of the touchy, feely, "do it because I think it's the right thing to do" kind of stuff -- not to disparage management consultants and the like.

Uppal: One of the big differences between management consultant and enterprise architects is that what you put on the table, you have to execute. The management consultant says, "You should do this, this, and this," and walks away. At the end of the day, if you, as an architect, put something on the table and you can't execute this thing, you have basically zero value. People are no longer buying management consultants at face value. They want you to execute.

Look to the boutiques

Foote: But they are buying people with consulting talent -- management consultants, because they have consultative talent. When I said bring somebody from Accenture or IBM, I didn't mean from those companies, but rather formerly of those companies, consultants who now are on their own in boutiques.

If you want to look at how to grow a lot of the stuff -- not just architecture, but a lot of areas that are having trouble with definition -- it's the boutiques. They are excellent. Some of these people who used to work with these companies were constrained by the frameworks and programs they had to work with and they went out and created it as it should be.

If you're lucky enough to find one of these and they're not research constrained -- because everybody else wants to have them come in and help them -- you've done a good thing. Always look for the smaller firms, if you're going to bring in any consultants.

Gardner: James, for those folks who have been listening and think they've got the right stuff, where do they go to help convince the rest of the world they have the right stuff? Where do you get started on this beyond some of the traditional and organic approaches we've heard?

De Raeve: This was the very problem that we were given when developing our certification.

So, we provide a lot of material that enables you to actually come to grips with what best practice things are, a set of core skills, competencies, and experiences that are needed by successful architects.

programs. How do we determine whether someone with a business card or a title that's got architect in it actually is an architect? What do we mean by that? How do we manage and control that?

In response to that, we developed our IT Architect Certification Program (ITAC) for the skills and experience, the ITAC Program, and we also have the TOGAF program, which is more about knowledge. What those programs do and the real value of those programs is twofold.

We've got some documentation, which defines what those skills and experience levels are. You can look at that, if you're practicing architecture or you are in the architecture space. You could look at that stuff and say, "These are really good things that I ought to be drawing from as I work on my definitions of roles, or as I look at recruiting people or developing or promoting people." The certification is a separate piece of value.

So, we provide a lot of material that enables you to actually come to grips with what best practice things are, a set of core skills, competencies, and experiences that are needed by successful architects.

Seeing results

Then, there is the certification piece, which allows individuals to be recognized for having met those criteria at different levels. We're trying our best to and introduce the idea of certification for architects into recruitment or procurement, and we're having some results. That's an ongoing piece of work, as we're fairly new in this certification. This professional level is pretty new.

So, we've got the two things: tools to enable organizations to start understanding what best practice is in the space, and then the certification program that allows people to communicate to their customers, their employers, and their next employer that they actually possess these skills and competencies.

Gardner: David Foote, these certification programs aren't the same as a vendor or supplier type of highly focused technical certifications. This is something quite different.

Foote: Yeah, it is. The certification industry has been on a decline lately. The reason why is that certification, for the most part, was an industry created by vendors who wanted to sell and resell their products. In that sense, the certification group is always in the marketing department of any company. Name one vendor, and I don't know any certification group that is not in the sales and marketing departments.

Then there came this whole group of vendor independent certifiers of talent, like in project management and architecture. These are extremely important. These are probably the survivors. Microsoft's certified architect program showed up very high in a recent survey of ours, and we put it on our hot list. I felt bad about that, because The Open Group also has excellent architecture certifications.

The reason a vendor can show up and create a lot of buzz around their products is because they have an enormous amount of money to sell their programs to their vendors. Microsoft evangelizes their products through all of their certification programs. This isn't to say that it's not good to have a certification, but the foundation is to evangelize the Microsoft point of view, and they're very successful at that.

The independents, if they're in competition with a vendor, won't be able to have the resources to get to market, to get the word out. On the other hand, they can create exceptional education and training programs. In architecture, though, if you create a program that caters too much to IT at the exclusion of business, and you are selling EA certification, you're not going to develop the profession.

Three people came up to me at this conference yesterday and today. They were enterprise architects who said, "Should I get an MBA?" Great question. How many of you have MBAs in the room? You're well positioned for the future of EA. You need to be able, if anything, to speak the language of business and make them feel comfortable about you.

But, in general, I'm very bullish on vendor-independent certifications, because you guys have to work so much harder. I have so much respect for The Open Group, and it's where I send anybody who talks to me about educating, training, or wanting to learn more about the profession.

I don't think there is anybody else really to go to, unless they're a Microsoft shop, and they've got a ton of Microsoft stuff. Then, I would say they might want to consider them too. I'm sure it's an excellent certification, but The Open Group has a great opportunity, and as long as they can expand, these MBAs.

Gardner: Well, thanks. I'm afraid we're about out of time. I want very much to thank our panel. We've been joined by James de Raeve, vice president of certification for The Open Group. Len Fehskens, vice president for Skills and Capabilities at The Open Group. David Foote, CEO, co-founder and chief research officer at Foote Partners. And, Jason Uppal, chief architect at QRS. Thank you to everyone.

This is Dana Gardner, principal analyst at Interarbor Solutions. We're coming to you from The Open Group's 23rd Enterprise Architecture Practitioners Conference in Toronto, the week of July 20, 2009. Thanks for listening, and come back next time.

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

Transcript of a BriefingsDirect sponsored podcast on the role, qualifications, and career paths of enterprise architects. Recorded live at The Open Group's 23rd Enterprise Architecture Practitioners Conference and 3rd Security Practitioners Comference in Toronto. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

Cloud Computing Uniquely Enables Specific Business Solutions to Meet New Industry Needs

Transcript of a sponsored BriefingsDirect podcast on cloud computing and the new business opportunities it offers for specific industries.

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

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

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

Today, we present a sponsored podcast discussion on the implications cloud computing has on companies in the manufacturing industry. We'll look at how to best define cloud options and how specific businesses can use these new means to add flexible sourcing to gain new business agility. The goal is not to define cloud by what it is, but rather by what it can do, and to explore what cloud solutions can provide to manufacturing industry companies.

Here to help us uncover the specifics of cloud-enabled business outcomes is Christian Verstraete, Chief Technology Officer for Manufacturing & Distribution Industries Worldwide at Hewlett-Packard (HP). Welcome, Christian.

Christian Verstraete: Welcome, Dana.

Gardner: We’re also joined by Bernd Roessler, marketing manager for Manufacturing Industries at HP. Welcome, Bernd.

Bernd Roessler: Thank you, Dana.

Gardner: And we're also joined by Mick Keyes, senior architect for Business Critical Systems at HP. Welcome to the show, Mick.

Mick Keyes: Many thanks.

Gardner: We want to look at this whole issue of cloud by first better understanding what we are talking about. The notion of how cloud is defined, of course, has been up in the air, pun intended. Let's first go to Christian. What has made the world different about cloud issues now? Why all the fuss?

Verstraete: Well Dana, I think there is a lot of fuss, because on the one side, there are a lot of promises that seem to be coming out of the cloud and, on the other, there are a lot of requests that are actually being asked of IT professionals. One of the major ones is to reduce cost in the current situation and circumstances that we are in.

So, with that in mind, cloud with its "promises" -- and I put promises between brackets -- of drastically reducing costs is obviously appealing to a lot of people. However, there are probably as many cloud definitions as there are people who are actually doing something in the cloud and talking about the cloud.

I don't want to go into any of those. I just want to highlight what we at HP want to do, and are doing, in that particular space, because we feel the company really has a role to play in three different areas.

The first area is that even if you, as a cloud user, don't use any infrastructure or anything, that infrastructure needs to exist somewhere in the cloud. The first thing is that we provide cloud-service providers with an appropriate infrastructure to be able to provide those services that we were talking about earlier.

Number two, many of our own customers don't really know what cloud is and how to get there. So, we help our customers address their needs and help them understand how they can transform their IT to embrace cloud.

Number three is that we, ourselves, as a company, are providing some cloud services.

Gardner: The idea, I think, is "faster, better, cheaper," "Everything as a Service," but with a variety of different approaches that are specifically tuned to the enterprise.

Everything as a service

Verstraete: Absolutely. Ultimately, and you pointed it out, it's going to be "Everything as a Service." Actually, the concept of "Everything as a Service" is nothing new. It goes back to a gentleman named Joel Birnbaum, who was heading up HP Labs around 1980-1982.

He spoke about compute appliances and compute utilities. The cloud is really that compute utility. He was actually foreseeing the beginning of the 21st Century, and he was pretty close.

Gardner: Well, that's very good. Let's go to Bernd, now. Tell me some examples of what we consider to be critical success factors. How do we know, when we look to cloud enablement, that we're going to be getting something for our money or that we are going to be doing something we couldn't do before?

Roessler: I'd like to start by highlighting the fact that cloud services to consumer are distinct, different things, compared to cloud services in the enterprise. I'm representing some thoughts from an industry vertical perspective and I think we need to have a particular look at what is different in providing cloud services for enterprises.

Number one is that everybody likes to live up to the promise of saving costs by introducing cloud services to enterprises and their value chains. Nevertheless, compared to consumer services like free e-mail, the situation in enterprises is dramatically different, because we have a different cost structure, as we need not only talk about the cost of transaction.

In the enterprise space, due to legislation of the surroundings, which are critical for enterprises, we also need to think about, privacy, storage, and archiving information, because that is the context under which cloud services for enterprises live.

The second dimension, which is different, is the management of intellectual property and confidentiality in the enterprise environment. Here it is necessary that cloud services, which are designed for industry usage, are capturing data. At the moment, everybody is trying to make sure that critical enterprise information in IT is secured and stays where it should stay. That definitely imposes a critical functionality requirement to any cloud service, which might contradict the need for creating this, "everybody can access anywhere," vision of a cloud service.

Last but not least, it is important that we're able to scale those services according to the requirement of the function and the services this cloud environment should provide. This is imposing quite a few requirements on the technical infrastructure. You need to have compute power, which you can inject into the market, whenever you need it.

You need to be able to scale up very much on the dependencies, however. And, coming back to the promise of the cost savings, if you're not combining this technology infrastructure scalability with the dimension of automation, then cloud services for enterprises will not deliver the cost savings expected. These are the kinds of environments and dimensions any cloud provisioning, particularly in enterprises, need to work against.

Enterprise requirements

Gardner: Christian, it sounds like we are talking about the true enterprise requirements for doing cloud. As we're pointing out, they're different from a consumer perspective. Another important aspect of any business is the amount of trust and verification and the ability to measure and define expected outcomes and then present some sort of a cost benefit analysis.

These providers of cloud services are in a position now where they perhaps have to gain the trust of these enterprise users, based on what they have been expecting as business as usual for IT services. Could you explain what we mean when we go to the trust issues in how a secured, mature cloud environment might unfold?

Verstraete: Absolutely, Dana. There was one point that Bernd just made that is a very important one and it's often overlooked by people. The cloud, as it exists today -- think Amazon, Google, or some of the others -- is really being built around the consumer. You consume some cloud services. You pay with your credit card.

That’s a very simple example. This is the best shadow IT I have ever seen. IT departments should get absolutely red hot on that one, because now IT can be sourced completely outside of their control, outside of their environment, outside their processes, and outside their structures. With that in mind, how do you maintain Sarbanes-Oxley compliance?

How do you maintain all of the things that need to be done to ensure that enterprises remain within the boundaries of the law and remain within the boundaries of what they need to do? Cloud-service providers will have to rethink a number of things that they're doing and demonstrate to enterprises that yes, they are secure, that yes, they provide and they can avoid having anybody in the organization just tap services without anybody else's knowledge.

Let me give you a very simple example. I was talking to a customer about two months ago. One

There are still a number of things that need to happen and haven’t been put in place yet today to provide enterprises with all the bells and whistles they're used to in either their existing environments that they own or in the environments that they outsource.

of his people had tried hard to convince him to use a cloud service -- in this particular situation, Google Docs -- to share documentation between people who were working together, because it was very secure -- he was told. Everything worked fine. Then, one of the vice presidents did a search in Google and suddenly saw a secured document from that company appearing in his searches. Oops.

There are still some trials and other things going on. I don’t want to beat specifically on Google in this particular example, because the others are in the same situation. There are still a number of things that need to happen and haven’t been put in place yet today to provide enterprises with all the bells and whistles they're used to in either their existing environments that they own or in the environments that they outsource.

That's where the critical element is for an adoption of the cloud in large enterprises. It has to do with the protection of intellectual property. It has to do with trust and the limitation of the risks of the person that provides them the services, and so on. It’s really about that. That's core and central.

Gardner: In addition to having to make these services appealing to enterprises, based on what they have come to expect, in terms of these larger issues of trust and compliance and so forth, we also need to consider that perhaps one size doesn’t fit all, and that these industries, these companies will look for some specialization or customization. They have business processes that are unique.

Let’s go to Mick. Can you offer us some insight into how a specific business might look to cloud computing, not for just the most blunt services but perhaps something a bit more surgical?

Product traceability

Keyes: Sure. One of the major topical areas in this space is the area of product traceability in global supply chains. The more traditional "one step up, one step down" method, which is the norm today in addressing the tracing of any product, has its limitations in providing visibility into the product across its lifecycle. Hence, getting an accurate, single picture of the life story of a product is something the industry and the consumers have struggled with continuously.

That’s part of an initiative in bringing what we call a "cloud traceability platform" to market. We at HP will be creating a number of specific services to address this area. One of the initial services we will target is in the area of product recall. We will be creating a unique product-recall service in conjunction with GS1 Canada, an international standards body.

This service will provide users with secure, real-time access to product information, which will facilitate industry efforts to ensure that recall products are fully traced and promptly removed from the supply chain.

This will enable more accurate targeting of recall products, while security enhancements will make sure that only authorized recalls are issued and only targeted retailers receive notifications. Our plan with this service is to then extend this to other sectors, such as the hospitality sector, and then consumers down the line.

Gardner: As I try to understand it better, now, we have a course in which you’ve got a product recall for some reason or another. You need to bring a product back or alert people of some change in the status of that product. This impacts a number of different players -- retailers, distributors, and manufacturers -- and country-by-country, it could be different organizations entirely. So you’re looking at a number of different players, and a cloud approach benefits that in some way.

Keyes: Absolutely. As I mentioned, the more traditional approach has always been one step up, one step down, and each entity in the supply chain had to be connected together.

What we're offering is a centralized offering, a hub, where any of the entities in the supply chain or nodes in the supply chain -- be they manufacturers, be they transportation networks, retailers, or consumers -- can use the cloud as a mechanism from which they will be able to gain information on whether our product is recalled or not.

Gardner: And, this has a very dramatic economic impact. If you can elevate this process to the cloud, more players can be quickly brought up to speed, and there's more opportunity to control the issue at hand. That can save boatloads of money, I would think.

Consumer confidence

Keyes: Absolutely, and it’s been a very topical area in the last few years with a large number of recalls across the world, which hit industry fairly heavily. But also, from a consumer point of view or visibility into where the food comes from, this can be extended to other product areas. It improves consumer confidence in products that they purchase.

Gardner: I want to go back to Christian. Did you have an example as well about something in the automotive industry that would benefit from a cloud perspective?

Verstraete: Yes. It’s something that already exists in an early cloud format, if I can put it that way, but that will actually evolve over time. It’s called IMDS. It’s basically a database or a central set of information that is providing most of the automotive manufacturers today information on their critical components and particularly on the substances that are comprised within the critical components.

They can get the appropriate reports to be in line with the legislation around sustainability and around hazardous materials in a number of those areas. What we’re doing is tying together the suppliers of parts who know what goes into the parts and the automotive OEM’s who will use those parts and will combine those parts with other parts.

They can figure out what the total hazardous materials are and what the total critical substances are in this particular car. What we are doing is tying together dispersed sources of information to provide consistent answers to the users.

Gardner: That's very interesting. I really like these business examples that show the ability to

You want to get things at your fingertips, even if the source of that data may rely in multiple spaces and from multiple sources. That’s an added value of the cloud in this type of a problem.

pull in multiple partners, which has always been a bit of a difficulty when only one partner’s application might be at use. Then, it became a middleware immigration problem. Now, we’re talking about simply a coordination process problem. Is that fair?

Verstraete: That's absolutely fair, and there's another element in there, Dana, which is critical and important to understand. It's one of the reasons GS1 Canada and HP decided to go to the cloud. In a cloud environment, you can keep your data distributed.

There are all sorts of regulations today that some data needs to remain in particular countries. But, what you want to do, when you start pulling all of that together is you want the countries being able to view a complete set of data. You want to get things at your fingertips, even if the source of that data may rely in multiple spaces and from multiple sources. That’s an added value of the cloud in this type of a problem.

Gardner: Very interesting. Just to go back to consumers for a moment, they're becoming accustomed to using so-called Web 2.0 technologies to be able to communicate and create communities on the fly, harness different viewpoints within ad hoc discussion, and then instantiate that into an application set of some kind. Now, we can take this into the business, but in a way with which enterprises are comfortable.

Let’s go to Bernd. Tell me about some examples that you’ve been working with..

Changing behavior

Roessler: A couple of examples might illustrate that. We've been talking about the requirements of trust, but let me discuss a couple of examples where we have been finding out that some dimensions of cloud are changing business behavior of companies. Let me start with the famous trust element.

In a lot of cases, we're finding constellations, where a market or a particular problem cannot be resolved, because the market participants are in a lock box. Very often, a trustee can come in, destroy that lockbox, and enable new agility and new services towards the market participants. I'll give you a couple of examples.

Point one could be incorporated and accelerated collaboration between automotive OEM’s and their dealerships. Nowadays, it’s still "who owns what data," particularly about the driver. The trustee can come in and provide a set of cloud services, thus enabling the automotive OEM to have a much better view of the real end user situation and demands, but without jeopardizing the requirements of the dealerships to keep the concrete individual data in their hand, because it's their customers.

A trustee can offer cloud services to both of these market participants and thus transform the overall quality of information serving the joint intent -- selling more cars and providing better services towards the automotive drivers.

The other example is this element of the print services. With today's digital printing technology,

This gives the publishers the possibility to address niche markets, which is very often called "addressing the long tail" of publication users at the end.

you have, in combination with cloud services of information generation and production, the possibility to build magazines and print them on demand in very niche areas..

One could think about producing a magazine, which is aimed for people who are interested in analog players the hi-fi market. It's not a very big crowd of people. So, with the cloud service, plus digital printing technology, you have the possibility to create a customized, very targeted type of magazine for those people. This gives the publishers the possibility to address niche markets, which is very often called "addressing the long tail" of publication users at the end.

Gardner: Christian, on this whole point of sharing and trust, we've heard quite a bit about "co-opetition" in recent years, where the competitors can cooperate at some level. It's easier said than done. Is there something about what we can do in the cloud that makes that level of cooperation even among competitors a bit more viable?

Verstraete: Yes, because in the example I was giving, where the data basically resides in multiple places, the data resides and remains with you, being one of the players, and you can identify at the data-item level what information you will share with whom and what access you will give to whom.

You can have within the same environment a series of data that you're prepared to share with your coopetitor, and some other data you definitely want to keep for you. That's not an issue. That's way easier than when the data has to reside in a central location, is outside of your control, and anything can happen.

Out of your control

That data that you don't want to share with your coopetitor you may have to share with somebody else in your supply chain. So, the data can get out of your control in the traditional approach. That's an example where the cloud can really make a number of things easier.

The second related element is that, in the traditional collaboration approach, somebody needs to set up the environment in which people are going to collaborate. Typically, that's the OEM in the supply chain, but that means that somebody needs to go and invest for that to happen.

Here, there are no needs for predefined investment upfront, or at least for very little investment upfront. You can use the cloud and the cloud environment to basically provide that. It facilitates the entry point in starting cross-enterprise collaboration.

Gardner: Now, Mick, this collaboration can take place not only among companies, but between the public and private sector, particularly in this food industry or recall tracking application approach that you mentioned. Tell me more about what might be offering us benefits in the future between public and private cooperation.

Keyes: Certainly. We see quite an extension into what we're doing here from our initial services.

We're looking at how next generation devices, edge of the network devices as well, will also feed information from anywhere in the world into the profile that you may have in the cloud itself.

We see how business and industry, especially in the food or pharma area, will buy into this concept, but we want to extend it directly to the general consumer in some way.

It's not just in the food area. We also see it expanding into areas such as healthcare and the whole pharmaceutical area as well. We're looking at the whole idea of how you profile people in the cloud itself. We're looking at how next generation devices, edge of the network devices as well, will also feed information from anywhere in the world into the profile that you may have in the cloud itself.

We're taking data from many disparate types of sources -- be it the food you actually eat, be it your health environment, be it your life cycle -- and be able to come with up cloud based offerings to offer a variety of different services to consumers. It's a real extension to what industry is doing and to how the consumers live their life.

Gardner: So, it's a sort of common denominator between the private sector, the governments, or public sector, and then also the consumers.

Value-add services

Keyes: Absolutely. For example, in the whole area of recall, we're looking at value-add services that we will offer to regulatory bodies, other industry groups, and governments, so they can have a visibility into what's happening in real-time. This is something that's been missing in the industry up to today.

Gardner: Now, Mick, as an architect, what is it about HP's approach that fosters more of this über perspective on business processes?

Keyes: Our traditional strengths are in certain key areas, particularly in the whole area of transaction processing and next-generation transaction processing. Also, we've been very strong in providing more traditional services to stock exchanges, to telcos, and to a variety of different environments across manufacturing and healthcare.

We're taking the concepts of derived features -- the reliability, the availability, and the service availability of environments that we've implemented in the past. We're looking at the same blueprints of concepts to bring into consideration from defining the actual architectural blueprint of what we offer.

The most important thing here also is scale. So, from our own Business Critical Systems (BCS)

That's one area, working with the provider himself, to help him develop an extremely robust, high-performance environment that can really address the changing demands that are coming up to him.

concept within HP, offering scalability and environments that will host cloud type environments, we'll be able to offer that to industry and consumers.

Gardner: Christian, as we mentioned earlier, we need to make these processes and benefits of going to the cloud enterprise-ready and mission-critical. Perhaps you could fill us in a little bit on how HP has used this services enablement blocking and tackling, if you will, around SOA governance, the ability to exercise a variety of hosting options, and, of course, management software.

Verstraete: Well, let me come back to what I pointed out earlier. We're basically working on three fronts. Mick alluded to the first one, which is working with service providers to make sure that they have data centers that are really optimized from a performance point of view and that are very much capable of ramping up and ramping down services extremely fast.

For example, not long ago, we came out with a new product that we call Matrix that allows a very quick reprogramming of blade servers and storage, so that you can start adapting your environment as and when your needs require. You can provide the uptime and the service levels that consumers and customers expect from you.

That's one area, working with the provider himself, to help him develop an extremely robust, high-performance environment that can really address the changing demands that are coming up to him.

Appropriate security

The second element is looking at it from the other end. We talked about trust earlier -- how we can reassure the enterprise customer that the service that he will use in the cloud has an appropriate level of security and performance, has service level agreements, and so on.

Here we're building on our experience and expertise in our management software in general, and particularly in our own experience with offering these management tools on a software-as-a-service (SaaS) basis to help them using those tools, to understand and assess what level “pipe” they have in the cloud, and how good that one is at any given moment in time.

Gardner: You know what's really interesting to me about this conversation is that many times nowadays we hear cloud discussed strictly in terms of return on investment (ROI), reduced costs, or the savings from getting on-premise systems off of the company's budget and on to a per monthly payment schedule of some sort. But, what we're talking about is being able to do things that couldn't be done before across these businesses that are unique and specific to these industries.

I wonder if we have some sort of a metric of success from some of the examples that we’ve talked

. . . we're able to offer a lot more visibility to every element in the supply chain about the different stages of how the product is actually used.

about so far. We’ve talked about automotive and food and retail recalls. What do these new and interesting processes actually get for us as a business?

Keyes: One example I would like to highlight here especially is in the traceability area around product. If you look at some of the more difficult supply chains, food is one of the more difficult supply chains out there. There can be anywhere up to 20 different nodes or elements from "farm to fork," as they like to say in the industry. Industry or entities near the start of the supply chain would like to get more information on how the product might be used.

In the more traditional way of what we like to call the "one step up, one step down," when a product is bought by a consumer, the actual entity of the grower -- be it the farmer, the producer, or whatever -- may not have information to how that product is actually used.

Now, with this mechanism, this cloud-based service, because each entity is subscribing to the whole cloud hub -- or exchange, as we like to call it -- we're able to offer a lot more visibility to every element in the supply chain about the different stages of how the product is actually used. That becomes something that can be turned into quite a competitive nature also.

Gardner: Does, anyone else out there have some metrics of success of how businesses have already been able to use this to their advantage?

Cost saving potential

Roessler: I'd like to build on some of the thoughts we were discussing earlier. One of the dimensions clearly has cost-saving potential. The cloud is pushing a critical enabling technology into the IT departments, and whether they're sourcing the cloud from outside or they are building cloud services within the enterprise doesn’t matter. In order to be successful and capitalize on the technology, you need to automate a significant portion of your services as an IT company. That will then ultimately deliver the cost savings everybody is waiting for.

A lot of IT departments are still spending the majority of their budgets on operations, and so cloud is pushing even further the need for automation. It subsequently will be measured and judged on the deliverables towards cost savings.

Verstraete: If you'll allow me to give out one additional example, Bernd talked a little bit earlier about this whole concept of MagCloud, and he was pointing out the long tail of magazine printing. Fundamentally, the other element in MagCloud is that it becomes a print on demand, which means you only print the magazine when someone actually buys it.

I don't know whether you realize that 60 percent of the magazines that are printed in the US are

By using cloud services and by changing the approach that is provided to the customer, at the same time you do a very good thing from an environmental perspective.

not sold to customers and are going back for recycling. It’s fascinating when you think about it.

By using cloud services and by changing the approach that is provided to the customer, at the same time you do a very good thing from an environmental perspective. You suddenly start seeing that cloud is adding value in different ways, depending on how you use it. As you said earlier, it allows you to do things that you could not do before, and that's an important point.

Gardner: So, this visibility across multiple partners, including the end consumer, could reduce waste significantly, which of course reduces energy use and the carbon footprint. So, we should think about overall resource efficiency as an aspect of this as well.

Verstraete: Absolutely.

Gardner: Now, for those listeners who are getting some ideas about how they could use cloud and how it could enhance their business specifically, how does one get started? How does one start on this journey, where these cost reductions are in the offing, as well as efficiencies and these innovative new business processes?

Cloud over-hyped

Verstraete: I would suggest they first ask themselves one question, and you alluded to it earlier, Dana. Cloud is very much over hyped. So if we all think about the Gartner Hype Curve, what’s going to happen is we’re going to go through a trough of disillusionment?

Companies that are able at this point in time to invest in cloud are companies that understand that we’re going through that disillusion. We will start hearing bad noise and bad news about cloud. Despite that they continue investing and continue learning where and how the cloud could actually serve in their environment. If they're not, it’s probably not a good time to invest right now. I want to say that first.

The second element is to gain a good understanding of what the cloud is and then really start thinking about where the cloud could really add value to their enterprise. One of the things that we announced last week is a workshop that helps them to do that – The HP Cloud Discovery Workshop -- that involves sitting down with our customers and working with them, trying to first explain cloud to them, having them gain a good understanding of what a cloud really is, and then looking with them at where it can really start adding value to them.

Once they’ve done that, they can then start building a roadmap of how they will start experimenting with the cloud, how they will learn from implementing the cloud. They can then move and grow their capabilities in that space, as they grow those new services, as they grow those new capabilities, as they build a trust that we talked about earlier.

Gardner: Does anyone else have some thoughts on how to get started?

Roessler: I'd like to build on what Christian was saying. I think that we are, particularly in the

What we’re offering to our clients is to capitalize on some of the research, some of the findings, and also some of our own insights . . .

enterprise space, seeing that a lot of companies that are at the very beginning of the learning curve. I think it’s a joint requirement to work on that learning.

What we’re offering to our clients is to capitalize on some of the research, some of the findings, and also some of our own insights, because we shouldn't forget that HP is not only building the computer, we’re also in the consumer environment. So we're in the unique position to capitalize on what we would call the cloud to the business, as well as the cloud for consumer environments, and we are inviting our clients to basically capitalize on that.

Gardner: We've been discussing how the cloud can help uncover new technology-enabled business opportunities. The cloud is more than just a blunt instrument that cuts cost for consumer services, but increasingly is now being used in the enterprise, and we expect that to pick up over the coming years.

Helping us to understand these issues we've been joined by Christian Verstraete. He is the Chief Technology Officer for Manufacturing and Distribution Industries Worldwide at HP. You've been joining us from Brussels, is that right Christian?

Verstraete: Absolutely.

Gardner: Very good. I appreciate your input.

Verstraete: You're welcome.

Gardner: We’ve also been joined by Bernd Roessler, marketing manager for Manufacturing Industries at HP. Where are you joining us from today, Bernd?

Roessler: Frankfurt, Germany.

Gardner: Very good, I appreciate your input as well. Then lastly, we've been joined by Mick Keyes, senior architect for Business Critical Systems at HP, and I believe you're in Dublin today, is that right Mick?

Keyes: Yes indeed. I'm here from sunny Dublin for a change.

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

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

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

Transcript of a sponsored BriefingsDirect podcast on cloud computing and the new business opportunities it offers for specific industries. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.