Monday, May 18, 2009

Role and Perception of Enterprise Architects Needs to Align Better with Business Goals, Panel Discovers

Transcript of a BriefingsDirect podcast on enterprise architecture and its role and value in the face of the current economic downturn.

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

Announcer: Hello, and welcome to a special BriefingsDirect production, a sponsored podcast discussion coming to you from The Open Group's 22nd annual Enterprise Architecture Practitioner's Conference in London, England on April 22, 2009. Please welcome The Open Group's President and CEO Allen Brown, as he introduces the moderator and panelists for our discussion.

Allen Brown: This panel is about "Resisting Short-term Thinking: Rationalizing Investments in Enterprise Architecture During a Recession."

I'm glad there's not a recession in enterprise architecture (EA). We've got quite a full room, haven't we? The panel is going to be moderated by Kevin White, contributing editor to Computer Business Review in the UK. In that role, he closely monitors the infrastructure and enterprise management markets, consulting and writing about both the technology details and the business strategies of the major vendors and user corporations in these domains.

He also regularly writes about IT economics and business case analysis for Technology Investment. He was formerly editor-director for the CIO Connect Network of FTSE-level chief CIOs. Kevin also works as research director for Datamonitor Technology, and before that, headed the Computerwire IT news service.

I'm going to introduce Kevin. He's going to introduce his panel. Please give a big, warm welcome to Kevin White.

Kevin White: Thank you, and good afternoon everyone. So resisting short-term thinking, how does EA thrive and survive in recession? It's a tough subject, and I can't do it without some expert witnesses.

I would like to invite Henry Peyret from Forrester Research. He has focused for 25 years on the concepts, techniques, and tools used in EA.

We also have Phil Pavitt, the group chief information officer (CIO) for Transport for London. Phil is the man who is responsible for all the technology behind London buses, Underground, the Light, Docklands Railway. Phil admits to being responsible in part for the Central London Congestion Charging Scheme. So, a very warm welcome to Phil.

Next, we have Thomas Obitz, a principal architect at Infosys. Thomas's key areas of interest are the potential versus the perceived benefits of EA. It's very relevant.

Mike Turner, enterprise architect at Capgemini is a very familiar figure in this room. He's one of the core team that developed the SAP Enterprise Architecture Framework, which was a joint initiative between Capgemini and SAP. [More from Mike Turner on BriefingsDirect.]

Finally, we have Terry Blevins, a senior principal information systems engineer at MITRE and Customer Council Board member of The Open Group. Terry has been involved with architecture discipline since the late 1980s, and he currently heads a team of 40 enterprise architects. As his accent will show, he is based in the US. So welcome, panelists.

Talk about business

We've talked today about frameworks. We've talked about certification. We've talked about software tools. I just want to raise our heads somewhat and talk about business, because that's what we're all in. You don't need to look very far to realize that we live in very interesting times. The challenge for EA is to be able to balance the long-term goals against the pressing short-term needs of the business.

There are intense commercial pressures right now to reduce costs at a time when capital expenditure is severely constrained. Operational efficiency has become an imperative, but agility and speed to market are equally as important.

In a downturn, there is a natural tendency to accentuate the tactical, short-term initiatives, and EA arguably is inherently long-term. This is a crucial issue of how you balance that long-term architectural goal against the short-term needs of the business.

So let's explore that. To kick off, it would be interesting to understand what business is like at the top. Phil, perhaps you could share with us some of the challenges, some of the pressures, some of the dynamics currently in the CIO's office as it relates to this flex between short-term and long-term goals.

Phil Pavitt: Thank you. It's an interesting issue, because although this talk is entitled around recession, I'm not sure that pressures of the CIO's office have ever changed. Certainly the role I have, looking after an enormous organization that spends almost $2 billion a year through my team on technology, I don't remember having any other conversation around cost cutting, efficiency, or speed to market, that's particularly changed this week from this time last year.

What has changed though is that suddenly those business units that had two choices -- do we use the internal teams or do we do our own thing? Perhaps two or three years ago, in most business units, they felt strong enough to do their own thing and then once they've got it, or a third party has given it to them, come to the center and say, "Is there any chance you can run it?"

Now, perhaps that money is not so readily available to them. Suddenly, I can see where EA actually become a critical part. Taking our standards and designs, because they're common across the business, becomes a very efficient way to operate and to run.

Having sat here for the last hour, I'm worried about some of the "business speak" interface between the architects and the business, but I'm sure once you move away from your internal conversations to the external ones, it's much more business-focused.

Most businesses, and certainly the businesses I operate and am responsible for, want to talk about standards and designs that produce speed-to-market, save money, help with maintenance, do actually give longevity to application development, application maintenance. They wouldn't necessarily recognize the tools to do that, but they recognize the people and the business partner to supply those tools.

Demonstrate added value

So my role as CIO, it is to demonstrate to the business that we can add value, and that value is primarily helping them with their business needs, as it ever was, but now helping them in a way that's cost-effective and frees up cash on other things.

In this last year, the project meetings I've been to, where the respective project director says, "And that will be $X million over 12 years, etc.," all those conversations have gone. It's much shorter values over much shorter times. The day of the big program is dead. The day of the big outsource is dead.

The understanding of our architectural process that's going to apply to that is a critical interpretation that CIO and his office will do for the business. Otherwise, they will go for "short-termism," because they'd go for what they see in front of them. So, that's some of the pressures we face.

White: Thanks, Phil. I think you're suggesting, perhaps, that time-to-value is probably more important now than a big return on investment (ROI). Is that the case?

Pavitt: I work in the government sector, which has an interesting history of major programs, some of which is true and some of which is hype. At the end of the day, IT is judged by what a business can take and use tomorrow. It's no good to have some of my strategy team and my business relationship team sitting with customers and saying, "Look, we can do stuff that will change your world tomorrow," and they say, "But, my printer doesn't work."

I know as architecture, you don't want to talk about that. You want to talk about the big world-changing, world-challenging processes. Sometimes, our most simple architectures do not serve the customer and help them do their stuff today. The more we can learn to do that today, then the more we get long-term support.

Therefore, if you find in my organization a program or a project -- even things like the Congestion Charging, for which I'm responsible -- has programs that go over 12 months, we have to sit. If the ROI is acceptable, we have to seriously consider whether it's actually the right thing to do. Can we do these small parcels? Can we architect something that does now and is then put on the shelf to re-brought down or reused again and again and again or built on again and again?

Each one of those small components must be successful in terms of their hurdles, whatever their hurdles may be. That's the biggest challenge we currently face. It doesn't change the overall theme or the overall process. It's a repositioning of that relationship with the business.

White: Thanks, Phil. Thomas, EA needs to prove value. Infosys did some interesting research late last year and early this year. Perhaps you could pick up on some of those key themes and explore some of those issues.

Thomas Obitz: There are a couple of things that we found that closely relate to what you've been saying.

First of all, EA clearly becomes a tool for strategic business transformation. That is visible from a couple of indicators. One of them is that 42 percent of the organizations have their enterprise architects actively involved in the strategic planning process.

Another indicator is that 16 percent of all organizations have the EA report outside IT. That means to the head of strategic planning, to the CFO, to the COO, and to the CEO. So, enterprise architects are changing their positioning, and that means that the value that the organizations are expecting out of them is changing, and also, the way they are talking about value and how they are proving value.

I don't fully agree with this view that EA is strategic, and strategic is short-term. What is strategy? Strategy is, "I am here. I have a vision of being here. I need to take this and this steps, when I do a starting step. I start tomorrow, not in two years." The best way of making large transformation programs fail is actually to have something that does the tactical thing and another program that does the long-term strategic thing, because the tactical thing solves the problem.

What is EA good for? It's an approach for solving the problems of an organization. As we say, the problems are here and now. You need to make out the places where you have current issues. You need to identify architectural approaches to solve them. And, you need to start gradual change right now. So, yes, you are capable of demonstrating a long-term path, but you are creating value in the short-term.

Basically, as enterprise architects what we need to change in our overall approach is that we need to go away completely from this architectural approach, which is about, "We build a big picture of how we could imagine things work and then implement that over a long time," to "What's an approach that's issue-driven." We need to identify where the issues of the organizations are today, identify what needs to change, and then consolidate that into the big picture.

Uniquely positioned

Architects are uniquely positioned for that, because our key capability, which basically constitutes what we call architecture, is that we work out solutions from the standpoint of a multitude of stakeholders, but then we consolidate against a common set of models. Instead of having marketing do something, finance do something, and human resources (HR) do something, which then don't go together, we can come up with holistic solutions. This is the unique strength of architects.

That also means that we need to change the way we are talking about our solutions, as you rightly said. I often hear that architects need to talk business, but it takes it a bit short. The problem is not business in the sense of what the organization is doing. It's not sufficient that an enterprise architect understands banking.

The point is that an enterprise architect needs to understand the mechanics of management. He needs to understand how decisions are made at the top level, and he needs to have an approach of presenting what he's doing and what he suggests in a way that is understandable and traceable for the most senior decision makers in the organization. We're basically moving towards management consulting.

White: Terry, you had a large group. You just heard about the requirements of the group to have an understanding of management skills and the mechanics of management. Do you think the typical EA group now has the right sort of skills to be able to face off to clients within the business in that sort of fashion?

Terry Blevins: EA, architecting, and the architects themselves are much different than maybe domain-specific, technology-specific architectures, architects, and architecting. This is where the soft skills really come into play.

I've seen more than one CIO get pretty angry to the point of you're not invited back if you come in and just start talking about technology and architecture speed. In the DoD, if you start throwing out OV1 and SV1 and stuff like that, that doesn't make it.

You certainly do need to approach the decision makers with a mind toward the business. I don't think it hurts to speak "business speak" to them. But, the point is to show a true appreciation that you're there to help them, help them make decisions, help them implement what they need implemented, help them be responsive, and think about the day to day. It's not 5 or 10 years out anymore. It's the day to day.

White: Let's change tack slightly, Mike. EA has to make an impact, a business impact. What other ways can we accelerate fast impact programs, where there is a necessary focus on operational efficiency, productivity, and cost reduction?

Mike Turner: If organizations have been doing EA in the past, then now is a really good time to demonstrate the value of that in the world that's happening. A lot of the talk has been about using EA as a tool to increase the agility of your organization. Organizations that have understood their EA and understood their operating model and how their organization functions should be well placed to make significant strategic, cross-silo decisions to respond to new market situations.

One of the real opportunity areas that EA is uniquely placed to deal with is working across silos. IT could be one of those silos, but there's any number of other silos within the business, across HR, finance, and different parts of operations.

EA is a fantastic tool to be able to consult a wide variety of stakeholders about a particular market change, get a consensus viewpoint about that, and really have to define the responses across the whole organization. Also, to look for ways that traditional silos can work together more effectively. Most silos, when considered in isolation, in the majority of organizations, are quite efficiently run. There isn't a huge amount of extra value that can be driven from those silos or extra costs that can be taken out. The opportunities really span across those multiple silos.

In order to react quickly, you really need those essentials in place, and you need to understand your operating model and your stakeholders. You have a mechanism in which you can articulate how you're going to respond to a need to change, and then you really have the tools in place to be able to quickly make changes and have a coordinated response.

The worst thing you could do in any crisis situation is to allow fragmentation and different parts of the business to go and try different strategies. You may be cutting cost in one area and trying to increase value in a different area. You end up conflicting with each other and ultimately creating more tension and having a destructive impact on the business.

White: There are some strong communication and influencing skills that are required.

Turner: Absolutely.

White: You mentioned three keywords for me there: speed, response, and agility. Henry, I know you've got a real interest in agility and you consider it almost a benchmark that needs to be melded somehow into the EA group. Can you talk us through how that might develop?

Henry Peyret: At Forrester, we think that there is probably a breakthrough for the EA job currently. We are launching something we call EA 2.0, a renewal of the EA world. Take agility, for example. We think that we should now move the agility at the business level and say what type of agility we can provide for the business to deliver new products, to deliver new capabilities, and to transform the enterprise.

A new metric for EA is coming -- key agility indicators at the business level, but also key agility indicators for architects.

We talked a lot today about the strategy angle that enterprise architects are taking currently. We've seen lot of changes with service-oriented architecture (SOA), which brings a new iterative manner to more principles about driving different changes.

You talked about the fact that we need to adapt to different geographical zones, different constraints and compliance, different type of architectures. The big picture is not valuable enough for the enterprise architect. We think that brings a new way of doing EA, and we call that EA 2.0.

White: I want to introduce a question from the audience. This is from Colin Wheeler. Phil, you might want to take this one. How can big EA providers and consultancies demonstrate the cost benefit of EA to board-level management in today's climate?

Pavitt: Stay away really. That's just a small joke. You've got to remember that at the board level there's massive frustration with most IT departments. A CEO, or a principal in charge of an organization, has poured millions and even billions over the years into its IT department. Someone said, "Just a few million more, and I would have architected the right agile, fast-to-market, cheapest benchmark thing in the world. Just a few million more."

They've heard this so many times. I can tell you from the organizations I have led as an IT person, that is the single biggest source of frustration. Yet, and I think the conversation is totally valid, we to go back to the question of how you actually demonstrate value?

We see here an assumption that most organizations work with each other for the common good. Perhaps you work in a more perfect world than I do, and you're lucky in your company. With all respect, most business units in most companies are looking after their own horizontal profit and loss statement (P&L), their own horizontal income, or dealing with their own horizontal challenges. IT among two or three other project functions is the only one that goes horizontally.

The idea that the whole business can say, "Shall I chuck in my bit of my application, my bit of infrastructure, my bit of data center, and my bit of technology, so the common good can happen" -- those conversations don't happen very often, or perhaps they happen when I'm never in the room.

Some people I know in the businesses are so wedded to their application and their architecture, they think the threat of losing it is the threat of their job.

Common good vs. individual good

So to answer the question, fundamentally we have to demonstrate not just the common good, but the individual unit good, because although everybody says at the boardroom, "Yes, of course, we're here for the common good," how they all bonus and objectivize isn't the reality.

An enterprise architect who says, "I've decided that the good thing to do is to bid on this architecture, on this infrastructure, on this, or whatever, because we over the next few years would get a overall pound in the pocket for the business," will not get listened to, although they may well be right.

We have to understand that, whether it comes from a third party, an organization, a consultancy or whatever -- internally or externally -- is irrelevant. It's someone who can scratch where the business itches, not necessarily for the overall common good, but within the unique good that feeds the overall common good. Otherwise businesses are going to say it's more money in what is, in their view, almost a failing department.

Peyret: It is becoming very important to contractualize better, including internally. The more we become a shared service as an IT department, servicing different business unit with their own profit and loss, with their own requirements, the more we would be required to contractualize.

That's what we call the contractualization trend that's internal for the IT relationship with the business unit and also for the business unit relationship between themselves and between business units and also partners.

As you say, if we do not reflect those contract aspects, including the key agility indicators I talked about previously, within our personal incentives within each group, we will not obtain that contractualization in a wide manner.

At the same time, when we talk about contractualization, very often we talk about something that is more constrained, a way to get more money, and other things like that. There is something that is changing dramatically about that too, which is flexible contract.

That's a different type of relationship, but that's where EA should play a big, big role to obtain a wide level of contractualization. You cannot contractualize everything, particularly internally. At the same time, you should define an effective way to negotiate or at least discuss with the CEO and the business unit. That's a key requirement to make that happen as a shared serviced is different business units with different requirements.

White: Another question from the audience here, How can EA be positioned in this scenario? One of the key focuses of EA is business transformation.

The key for enterprise architecture, in either a business transformation scenario or maintaining operations, is really to understand the decisions that do get made.

Well, in the current climate, I'm not interested in transformation. I'm not interested in making major changes, because major changes are disruptive at any cost. They just want to run the business [well]. Terry, where does EA live in that scenario?

Blevins: Decisions are made every day. Some of those decisions are about transformation, and some of those decisions are about operational day-to-day things. The key for enterprise architecture, in either a business transformation scenario or maintaining operations, is really to understand the decisions that do get made. It's key to understand who is making those decisions, understand the information they need to make those decisions, and build your enterprise architecting or do your enterprise architecting and build your EA to support that decision making. ... To me, that's absolutely critical.

We're not here to go to the boardroom and say, "Here is an EA or here is our architecture anything. We're here to support decision makers. We're the back. We help them and empower them. We give generals more stars and give CIOs the CEO positions.

Turner: Being realistic, though, there is a fairly clear relationship between the amount of change that's happening within an organization and the demand for EA. If an organization is completely static, then there is little value to be had from having an EA.

Two-dimensional question

I guess the question is two-dimensional. One is about the amount of change that's happening, and the other dimension is the horizon on which that change comes into effect.

If you're seeing an organization that is taking its change budget and employing the same amount of money into very short-term change activity, then, absolutely, there is a need for EA there. You would probably expect that doing that would actually completely disrupt the business. If an organization is really just pulling back on the amount of change that it is doing, that, by consequence, has to have an affect on the requirement for EA.

White: In terms of understanding what your comment is, you really need to understand the business criteria that the business is trying to address. Is it the cash cycle that's an issue? Do you think that the EA group thinks out of the box departmentally? Does it think like a CFO? Does it understand the financial flows that are impacting the business? And, how important are they considered in the boardroom? How do you accelerate that or enhance that process?

Turner: If it wants to be relevant, it absolutely should do it. What you would aspire to and what you observe in organizations is not necessarily the case. Certainly, there's been a tendency in the past to focus on technology, elegance, and large theoretical exercises that look beyond the horizon of where the rest of the organization is thinking. That type of activity is really irrelevant to most people within an organization.

To really attain relevance is to focus on the problems that the business has, and grouping them in terms of agility. You could characterize that as agility on two different levels, because there is an agility that you can gain from having very flexible systems that can change based on unknown requirements. There's a lot of thinking around things like SOA, Agile Development, and those types of techniques, which are really looking to build open-ended systems that can address many different types of requirements.

I think another area of agility that is often slightly overlooked is the end-to-end business agility, which can often be derived from having static fixed systems that go end-to-end. Re-looking at the ERP platform that you have and how that can help increase time to market, supply chain visibility, or the usage of capital within the organization is something that shouldn't be overlooked, because it's not considered to be interesting from a technical standpoint.

White: Henry, earlier you mentioned earlier development in application portfolio management of EA. Does that pick up on Mike's point?

Peyret: Currently, there is a trend to rationalize everywhere, to try to decrease the cost. Obviously, it's the right time to score applications and be able to say, "Okay, I would like to cancel and kill some of those systems that are expensive, that cost a lot, are not maintainable, are not sustainable for the long-term, and many other things like that."

At the same time, I also see some industries in which IT is becoming more important, and where some of the business will be done with IT involvement.

I worked in some pharmaceuticals, for example. To decrease the risks of taking drugs, they're bringing now a bundle of IT testing machines. That's completely changing the business. That's becoming part of the pharmaceutical business. It's not something that's a sideline that's there to support a process.

I see some innovation, and one of the roles obviously of EA is to help businesses bring that innovation in at a right time. We have seen some of those mistakes in the past. We had client-server, which was adopted. Finally, it was not scalable or deployable, or whatever you want. That's the sort of thing where EA is playing different types of roles, which are more on the strategic side.

I agree with you on the rationalization and standardization. That really is the right place to come back with some recommendation you made in the past and say, "Okay, we can kill that application because the business is ready to save."

The issue of value

White: One of our participants has rightly brought us back to the issue of value, and it's actually addressed to you, Phil. Do you have an EA group? How did you form the group, and how do you demonstrate value to the individual business units of that group? Perhaps you can lead into the discussion of value generally?

Pavitt: Do I have an EA group? It's very small compared to the overall organizational size. Each of the groups in my team lives or dies by their contribution and the value the business perceives. The EA team now is a fifth of what it was when I first started. It will get smaller, if it doesn't continue to show value.

Despite all the conversation, we carry 12 million people a day in our transport systems. If we don't know where the buses or where the tube train is, if we cannot produce the countdown data which helps you to tell when the next underground train or bus comes along, you can have as much TOGAF design as you like, but at the end of the day, "Where is the damn bus" would be the obvious question from the business.

So value is not value necessarily, but not exclusively in monetary terms. I do agree with the sentiment that's been expressed here: get to know your customers. I've been frustrated with my own EA team time and time again. They are politically naive. As a CIO, I meant to be one of the sharpest political operators in my business, not because my business is particularly more political than anybody else's, but I'm the one who operates horizontally.

I'm the one who can be used as an excuse for every other department's failure, whether I've caused it or not. I'm the one in my company who is measured 1.7 million times every hour when someone presses the Enter button. We're the only department that's measured that often in real time of any other team in the company.

Our EA team turns up with the best thing since sliced bread that they have been working on in a hothouse environment for the last three months, which will feed all known starving people across the world.

It doesn't help me select the business in terms of value. Recognizing value in terms of what the customer, in our case the actual user, wants is critical. EA should be much more physical, politically savvy, and much closer to their customers. This is not a visit once a month.

Most of my EAs -- I think they have just stepped out, so I can say it now -- most of my EAs will end up in the business in the next six months, not in IT. I'll force them to be in the business, because I've asked them to do it nicely. Then they'll judge even more the value they can contribute. Of course, if the business then doesn't value them, they would do something about it.

So, value is a very important thing, but you have to get close physically to your customer to turn what value really means to them in terms of what they're trying to deliver.

White: So the way that EA group can create meaningful propositions with stakeholders is by working alongside them, by being fused in the business?

Thomas, surely everyone appreciates the value of EA. The business can see it. It's just that we're using the wrong measures, isn't it?

The need for rigor

Obitz: Well, that's an interesting thing. What enterprise architects think is a good explanation of the value of EA, may not be something that is even worth looking at for a CEO. Enterprise architects need to put rigor into how they justify and explain the value of what they are doing.

As part of our annual EA survey, we're asking enterprise architects if they feel capable of justifying the expenditure for the EA department. In our first survey, in 2005-2006, 76 percent felt capable of doing that. Then, 18 months later, only 68 percent felt capable of doing it, and in our last survey, in August last year, it went down to 61 percent.

Organizations are putting much more rigor into the metrics that people are reporting, and they want to get real numbers. We found that there are massive differences between architecture teams. If organizations are not collecting any metrics, only 42 percent of them feel capable of justifying the work of the EA group.

If they are very rigorous and are collecting data about what they're doing, collecting data about the business value they're influencing and enabling for the whole organization, and if they are collecting data on how they're accepted and involved with the work of the remaining organization, then 85 percent are capable of justifying the work of the EA team.

You need to put in this work. It's extra work, admin work, and it's boring. Enterprise architects don't want to do that. They need to talk about it. If an EA team doesn't report metrics on a regular basis, they're not recognized as a value source in the organization. Only 35 percent of those organizations that do not report metrics feel capable of explaining their value, versus 77 percent, where you have a periodic reporting of EA KPIs into the IT and business function.

Enterprise architects need to do something. They can do it. It's just that you need to take a different approach. The typical IT architect approach, "I do this because I think this is best practice," is something that nobody outside a team has ever accepted as a measure that is presentable.

White: Terry, another notion of perceived value of EA is that it delivers a value at the end of a very long process. How can we kill that notion off completely?

Blevins: Yeah, that's a bad thing. Is it true that 99 percent of the statistics are made up on the fly?

White: 87 percent.

Getting on the same timeline

Blevins: We have to get enterprise architecting -- I'm going to focus on the verb -- on the same timeline as the decision-making process in an organization. Decisions are being made every day in the organization. I couldn't agree more with Phil's comment about getting architects where the stakeholders are, getting them out of the back room, getting, at least part of them, very close to whatever process is being made.

One of the things we haven't talked a lot about today is the importance of connecting the architects to the governance process within the organization. Architecture is not there to build a solution. Architecture is not the solution. Architecture represents a resource base, where people can analyze to help others make decisions, and those decisions need to be made on a daily basis.

The key thing is for the enterprise architecting projects to be very closely aligned with whatever governance process happens to be there and then create deliverables to meet the timelines of those processes. It's essential to connect with those decision-making stakeholders, understand what their information needs are, and make sure that you package your enterprise architecting with no more than has to be there to support a given decision. That could be a decision about a process improvement. That could be a decision about an ERP buy. That could be a decision about the deployment of a business rule or an information standard. It doesn't matter.

White: There's a very relevant question from the floor. A key frustration for our CEO is that implementing the new solutions is constantly delayed by the business lines demanding new development, which can only be done by developing the very things you're trying to replace. So you're building an even bigger legacy. How would you deal with this within the EA?

Turner: One of the things that really helps in that context is simply the act of defining where you're trying to get to. If that target is not really defined in any detail and there aren't aspirational statements that say, "We'd like to do this," it doesn't really hit home with something that's real and in the here and now.

If you can say, "We want to be here. This is what it looks like in a bit more detail, and this is roughly how we're going to get there," and then put that in place within the governance processes that applies to those tactical decisions that are being made, you can then start to build the negative side of the equation for those changes. You can impact and assess those changes against, "This is taking me away from where I want to be rather than toward it."

There's a cross-implication to put this change in, but there is also a cross-implication to take this change out, and then start to look at alternatives of where you can maybe do it in a slightly different way that would take you closer to where you want to be.

A lot of organizations are simply making the commitment through a target state. Describing what it looks like in a way that people can understand means that they will almost instinctively make those decisions in a way that takes them towards where they want to go rather than away. They can start to factor that into their own decision making process.

Good to great

White: Thank you. One of the key drivers to any EA group right now is focusing on getting things done and getting done very well. Phil, you mentioned a book Jim Collins wrote, Good to Great. I think one essence of that is that in the soul of every great company, there is a sense of discipline. Do you see an EA group having any influence on enterprise discipline to keep the business going in the right direction?

Pavitt: The book Good to Great describes how companies can be pretty good, but there are quite big steps in making them great. There are lots of business principles in there that applies to IT in particular.

IT can really help any organization become great in a number of ways, particularly around architecture. As you sell to the business what architecture can do for them, I think they begin to get it. I guess they understand what the actual personal implications are, both positive and negative, but they also begin to build this sense of, "Well, if we do this, then we have a platform to launch on to something else."

What I find quite challenging, as any IT support organization would, is anticipating what the business needs. I enjoy the business planning around any organization, because the IT department says, "We'll set our strategy and our plan once the business has set their strategy and their plan."

I don't know if really good businesses always have those things. I've clearly made mistakes in my 25 years. I have not met one really. Most business plans are around survival or around getting to the next stage of a market. IT can't wait for that, but we can lead and guide business in a positive way to make those right choices.

In my organization, when I took responsibility, we had 63 data centers. We also had an architectural team of around 40 people. I could have put those two things together and made a very obvious conclusion. They both tried to separate themselves from the other, the physical reality. Someone had to persuade the business that to have 60 plus data centers was the wrong answer.

Now, we're down to three. Is that because of personality? Is that because of business case? Is that because of any of those? All of them have played a part, but the biggest thing was an architectural-type role. I'll use it as loosely as that.

Let's pick something the business is very bad at -- resilience. That might not be true for many companies, but in our company it was an issue. Disaster recovery is an issue, resilience, because politically we were savvy with the business.

We said 63 to 3 gives resilience, and suddenly everybody was on board. It wasn't because they saw having less was better, because nothing improved in their daily lives. It didn't get faster. It didn't get quicker. In fact, they didn't particularly save a lot of money individually, because those things are charged centrally.

But, the idea of resilience and disaster recovery, which has been a critical part of an operation of running a transport system, became very important to them. Suddenly, the architects could guide the business to make what in the background is an obviously right decision. A critical part that enterprise architects can play is the political part of helping the business make the right choices.

I'm not saying it should be self-diffusion or manipulation, although I think both things are perfectly legitimate tools in the IT world, but nevertheless, ultimately, you're doing the right thing for the business.

Survival without EA?

White: Thank you. Two questions from the floor, and I want to direct this to Henry. This is probably the most straightforward question, Henry. How can enterprises survive without EA? Another question, if the EA group can't produce a positive contribution to the business, is there any reason to keep it? That's addressing the current status of EA. I want to ask you what you think the future of the EA group is.

Peyret: I think that there is more EA. First, more enterprise are adapting EA. To answer some of your remarks, at the moment, EA is sharing some measurements, which are not addressing the complete enterprise, typically in travel and transportation. That's one industry that has four typical key performance indicators that they should share.

One is productivity. I fully agree with that approach. Second is quality, and third is risk. There are lots of risks transporting people without a level of security, which will bring them to the right place. The fourth one is about agility.

When we try to assess those metrics on each of the industries, some in finance should have cared a little bit more on the risk aspects. Also, subprime was a bad risk assessment. That was not sharing the key risk indicators with not only their buyers, but also their customers and many others.

So, to come back to your point, first, there are more enterprise architect groups within the enterprise. EA groups may not mean more people on the EA team. That means that we are seeing more federated, more virtual EA, and more EA involving business unit architects and business analyst architects -- the EA team. That's where the soft skills I talked about previously are becoming more and more important -- to involve the right person, to talk to the right person, to politically find the right way to bring the right message to the right person.

That's also why the enterprise architect role is changing currently. Now, we see different people jumping in as an enterprise architect, and not only people with a huge background in IT. Yes, they should have, but more and more, we see additional people coming to the business. It's a good way of muddling the business, muddling the architecture as a process, and many other things like that. What does that mean to the business?

White: Perhaps we could go to Thomas?

Obitz: Regarding your question what to do with an EA team that doesn't add value to the business, that's a difficult question. You can interpret business in two ways, and its commonly interpreted in two ways in the world of EA. One is, everything which is outside IT, and the second is the organization as a whole.

The last one is easy, if the EA team doesn't add any value to the organization in any shape or form, well, then it probably should be gone. If it doesn't add value to the organization outside IT, that's a different animal.

Basically, you have three value levers that you can use in an organization as an EA team. One is IT cost and risk, cost internal to IT. The second is cost and risk of the organization as a whole, and the third one is the top line -- revenue and opportunities.

An EA team may not be at a level of maturity to influence the organization's top and bottom line directly, but it may help running the business of IT more effectively. If you're looking at the research of Ross, Weill, and Robertson, just standardizing technology reduces the cost of running the IT by 15 percent. So, there are certain value levers inside IT that EA can address without going outside the IT department.

White: Thank you. So, "Resisting short-term thinking: Rationalizing investments in Enterprise Architecture during recession." We haven't begun to start discussing this, but thank you very much indeed.

I thank the panelists again. Henry Peyret from Forrester. Phil Pavitt from Transport for London. Thomas Obitz from Infosys. Mike Turner from Capgemini. Terry Blevins from MITRE. Thank you all.

Brown: And our thanks to Kevin White for moderating so beautifully.

Announcer: Thanks to you Allen Brown, president and CEO of The Open Group. You've been enjoying a special BriefingsDirect podcast discussion coming to you from the Open Group's 22nd annual EA practitioner's conference in London. This production was underwritten and supported by The Open Group. Thanks for listening and come back next time.

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

Transcript of a BriefingsDirect podcast on enterprise architecture and its role and value in the face of the current economic downturn. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

Sunday, May 03, 2009

BriefingsDirect Analysts Unpack Platform as a Service and Measure Future Impact on Enterprises

Edited transcript of BriefingsDirect Analyst Insights Edition podcast, Vol. 40 on the promises of platform as a service and its apparent lack of traction among enterprise managers.

Listen to the podcast. Download the podcast. Find it on iTunes and Charter Sponsor: Active Endpoints. Sponsor: TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at

Dana Gardner: Hello, and welcome to the latest BriefingsDirect Analyst Insights Edition, Volume 40. I'm your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions.

This periodic discussion and dissection of IT infrastructure-related news and events -- with a panel of industry analysts and guests -- comes to you with the help of our charter sponsor, Active Endpoints, maker of the ActiveVOS, visual orchestration system. We also come to you through the support of TIBCO Software.

Our topic this week on BriefingsDirect Analyst Insights Edition, and it is the week of April 13, 2009, centers on platform as a service (PaaS). This is the part of the cloud taxonomy that pertains to software and services development over the Internet.

Developers can use tools and testing apparatus as a service on someone else's data center, building and refining their applications and services, and even putting them through some real world performance testing, before going into production and use.

Where these services finally find a home or a runtime platform of some kind can come in a number of ways. Perhaps they run on the same cloud they were developed on. Perhaps they move to other clouds, on-premises servers or data center, or even other kinds of hosting models -- or maybe all of the above options in some form.

We've seen a great deal of interest by the developers in using Amazon's Web services for PaaS. We've also seen a lot of action and interest from the likes of Google, Microsoft, and even IBM. Of course, there are quite a few ecology players that have been out there for sometime as well.

PaaS is not passé. Yet a lot of enterprise operators and mangers that I speak to don't even see PaaS on their radar. They're much more interested in the infrastructure-as-a-service (IaaS) components of cloud computing and software as a service (SaaS) to a certain degree, but they're not quite sure about PaaS.

So, what is PaaS good for and how will it impact enterprises? That's the question we're here to help you understand. What is the reality and where will we end up in regard to PaaS? We're joined by a panel of guests and analysts to help dig into the enterprise role of PaaS.

Please join me in welcoming our analyst guests this week, Jim Kobielus, senior analyst at Forrester Research. Hey, Jim.

Jim Kobielus: Hi, everybody.

Gardner: David A. Kelly, president of Upside Research.

David A. Kelly: Hey, Dana. Glad to be here.

Gardner: And Mike Meehan, senior analyst at Current Analysis.

Mike Meehan: How you're doing, Dana?

Gardner: I'm doing well. I also have several guests I'd like to introduce. Joining us today is Jonathan Bryce, co-founder of Mosso at Rackspace. Welcome to the show, Jonathan.

Jonathan Bryce: Thanks for having me, Dana.

Gardner: And Rourke McNamara, product marketing director at TIBCO Software. Welcome.

Rourke McNamara: Good morning, Dana.

Gardner: Let's start with Jonathan Bryce at Mosso. You saw what was possible in terms of development of websites and web applications quite sometime ago. Tell us something about Mosso, what you do, how you developed the notion of PaaS, and where you think it's heading.

Bryce: I started Mosso with a co-worker, Todd Morey, and we started developing it in 2005. We were working at Rackspace hosting, which is a large traditional managed hosting company, and they agreed to fund this idea and help us get it off the ground. We started Mosso out of a need that we had. I'm a developer. Todd is a designer and a marketer. We realized that what we really enjoyed working on, and where we really felt like we could add value, was in building applications.

If you built an application of any complexity or significance at all, then you ended up having to take on the hosting burden as well. That required server and network administration, and making sure that you were on top of the security, the patching, the backup, and all those things that come along with it.

We really wanted to find a way to create a technology offering that took care of all of the headaches around hosting an application, so that developers could focus just on writing the code. That was the premise that we started Mosso with.

Gardner: That seems to have attracted developers, but is this something that you see a wider embrace of, or understanding of, the inside of enterprises?

Bryce: When we started out, we definitely were targeting people who were similar to us, who were independent or small development and design shops. Over time, we found that this is a more general-purpose tool that did appeal to a broader audience.

We also realized that when you're working at the PaaS layer, you have to productize. So, you have to standardize on technology and on what's

We also realized that when you're working at the PaaS layer, you have to productize.

possible to do in the environment. Within the last year, we've expanded our product portfolio to include a couple of IaaS offerings as well.

One is called Cloud Files, and it's cloud storage. Another is Cloud Servers, and it's virtual computing. Within the enterprise -- it may be a marketing site for major a sporting event that's doing some special promotion -- we're seeing people who don't want to have to run all that infrastructure. They don't know how popular it's going to be, so they'll use it for a small piece.

We're not seeing a lot of enterprises moving wholesale their SAP systems and all of these big enterprise software packages to the platform. We do see them using PaaS to augment their existing technology for new projects that they're working on.

Signs of movement?

Gardner: These new projects, are they typically a certain type of development environment -- a scripting environment, for example -- or are you seeing more movement out towards some of the more major development frameworks?

Bryce: It varies. It depends on which company it is. Some of them want to build it themselves from scratch, and they will write it in .NET and start without any type of a framework. But, we've also seen a lot of pickup in the open-source content management frameworks like Drupal. Wordpress is now used for a lot more than just blogging. We've seen a lot of times where people have started with a framework like that and then gone from there.

Gardner: Okay. Let's go to Jim Kobielus. Jim, we've seen this many times in the past, where developers grasp something quickly and early and end up driving it into much more mainstream adoption. Do you expect that that's going to also be the case with PaaS?

Kobielus: I think so. It's the early adopters who are looking for
a platform where, first of all, they don't have the internal resources to go out and acquire the hardware and all the infrastructure, and license the application servers, the tools and everything they need to get up and running out a new project.

Just as important, from the very start they want 24x7 reliability from whatever platform they plan to execute this code on. So, they're looking for a strategic partner who can handle all the hosting and, to a great degree, can also provide them with the tooling they need, both for the development and ongoing management of the code.

The early adopters have big plans, but small resources. The public-cloud hosting of these applications is important for those applications, where, as a previous speaker indicated, there might be a strong orientation toward business-to-business (B2B) applications, or delivering it out to the broader Internet as a service. They want something that's already out there on the cloud that will be immediately available and accessible worldwide, and with the reliability to back it up.

Gardner: Do you see an opportunity for these tools and services to play a role in how data warehouses are being utilized, perhaps some mining or some additional tooling that you might use across different domains -- a data set within your organization, perhaps something you've leased or rented for a period of time, maybe some publicly available metadata. Wouldn't PaaS make sense, when you're doing these data chores that involve multiple data sources?

Kobielus: Very much so. In fact, a lot of data mining projects are like that. First and foremost, data mining projects depend on discovering sources of data, both internal and external -- customer data, market intelligence data -- and then being able to extract, transform, load, cleanse, and consolidate the data into an analytical data mart.

I am using that term in a logical sense. The analytical data mart then can be mined to do rational analysis and scoring. So, the analytical data mart

All that clickstream mining is happening. That's a core of the Web 2.0 business model

for data mining projects can become fairly large fairly quickly, with all of the different sources of data being brought into it.

With the whole Web 2.0 phenomenon, more and more organizations and businesses are making their entire business model dependent on their Web presence and on their ability as a business to continue to mine the clickstream data user sessions to be able to identify patterns related to the customer experience and preferences, so that they can then up-sell customers, or hold onto the customers.

All that clickstream mining is happening. That's a core of the Web 2.0 business model, and that depends on a big, old clickstream data mart being maintained. As I indicated earlier, small businesses that are going down this road are looking increasingly for a clickstream data mart in the cloud that can be managed -- and it might be hundreds of terabytes or even petabytes -- that can be provided to them fairly inexpensively, and fairly quickly through the cloud model.

That's an example where PaaS is the underlying platform for the analytical data mart in the cloud for clickstream analysis for the whole Web 2.0 business model.

Gardner: Interesting. Let's go to David A. Kelly. David, you look at business process management (BPM) quite a bit. Are there any aspects of business process, putting them together processes that are going to hop across multiple services with multiple sources? Does PaaS relate to that?

Role for process automation

Kelly: Absolutely. There's a big role for business process, process management, and process automation that will be able to cross boundaries here and access different processes across cloud. So, there is an opportunity for PaaS to incorporate those types of capabilities. We're just seeing the beginning of that in terms of what's out there, and over the next couple of years, we're going to see more focus on that, as organizations start to deploy more applications, and develop more cloud-focused and cloud-based applications.

The need will be to manage and automate those processes across different boundaries. Just as Jim said on the data warehouse, business-intelligence side, we have the same thing on the process side. We're going to see development of more tools in that area and capabilities and services that allow organizations to do that.

Gardner: What's interesting about what you're saying and what Jim said is that these aren't necessarily cost-saving measures. We think about cloud as being a way to reduce cost and waste, increase utilization, take advantage of virtualized fabric of infrastructure services, and so on.

You've got to talk about being able to do something quite different that hadn't been able to be done before, because you have elevated yourself to the cloud. Doesn't this whole development in the cloud smack of that as well -- not just cost savings, but being able to do things that hadn't been possible before?

Kobielus: It's rapid, cheap provisioning in the cloud. It's the bubble phenomena, and quickly the bubble grows large like a data mart, because it can grow quickly in the cloud, and then it quickly gets de-provisioned.

Gardner: Dave?

Kelly: I agree with that. Dana, what you bring up is this idea of more nimble processes, and more nimble response -- faster, more agile response to changes. In that regard, from the process standpoint, it's like you're looking at more nimble process management or nimble BPM solutions that we're going to see down the road in order to be able to respond more quickly to business changes.

Gardner: What about that Mike Meehan -- this idea of nimble activities as a result of moving some or significant portion of what you are doing to the cloud? Does that make sense to you?

Meehan: It does, but it depends on what you are talking about as what you want to enable the nimbleness for. We're really talking about business processes that involve third parties and outside parties here. When you're still behind the firewall, it's not going to have as much of immediate impact. What we're really talking about is that we've got a cloud-based runtime out there.

Now, we're talking about taking the functions that we do in-house -- development, business process management, business intelligence (BI) -- and moving those out into that cloud, where we can interact with the rest of the world, which is where companies make their money. You don't make money by selling your own bellybutton. You make money by going out and interacting with the rest of the world. That's where the opportunities are.

We're defining those right now, but it's what can I develop that I can push out to other people and what sort of process can I create to incorporate business partners? That's where the exciting stuff is, and we're really just wrapping a rope around that right now, and trying to tighten it up. There's a big loop right now, and we're still trying to squeeze value out of it.

Bifurcation in the market

Gardner: Do you see this bifurcation in the market, as I do, that developers grok this, and are into it, particularly the ones who are doing green-field and Web development, but that behind that partition, where operations and runtime environments are being closely monitored, they don't quite get this or not interested?

Meehan: Oh, absolutely. First, developers are always interested in doing new stuff. They're naturally curious that way. It's one of the good things about developers. They'll go out and try new things. Operations people are type A. They're not going to be into adding chaos to the mix.

That's always the natural tension you've got there. A lot of the PaaS vendors -- I'll mention one that's not on this call, but I know the folks at WaveMaker -- constantly talk about how you've got to have management tools.

That's being done to throw something back to those operations folks saying, "Okay, we can manage it. If we go in there, we use this platform, and it's not just pure chaos for you." Whether or not that's an essential part of the platform, there's an argument to be made that maybe it isn't, but it's being done as a sop to the people who are going to be naturally nervous about this.

Bryce: One thing I would add is that we've definitely seen with some of our enterprise customers is that development teams have come to us, because they are looking for that provisioning flexibility that we were talking about earlier. Their IT department can't get them the equipment that they need fast enough.

For example, last year we had a customer that had an application they were running that ended up needing a lot of capacity really quickly. In

The interesting thing is that once we've been able to build a relationship with a company's development department, we're starting to see IT departments embracing this

about a week, it went from running on a couple of servers to having 10x the amount of load and traffic that they were handling a week before. They said there was no way they could have gotten this many servers up and configured from the IT department.

The interesting thing is that once we've been able to build a relationship with a company's development department, we're starting to see IT departments embracing this, not as something to fear outside their walled garden, but actually a tool that's helpful for them.

There are a lot of things that we have to go through. We have to engage with them and, as Mike was saying, we have to help them feel comfortable about how the system is set up, how it's managed, what the process is all around, deployment, security and all of those kinds of things. Then, they can look at it as another resource, not something that's dangerous.

Gardner: So, comfort with resources. Let's go to Rourke McNamara at TIBCO. This is yet another element to integrate into the larger apparatus of the enterprise, something that the middleware vendors are designed to do. Do you at TIBCO view PaaS as an important new component that needs to be brought into a managed integration process of some kind?

Managed integration

McNamara: We absolutely do. Given that one of our strengths and a lot of our history is in integration software and large-scale platforms for developing distributed systems, TIBCO has a lot of experience with very large companies, and very large companies that develop a huge number of internal facing applications.

I'd totally agree that, up until this point, almost all of the work done in the cloud by enterprises has been Internet-facing, outwardly facing, or partner- or customer-facing applications. There's a huge interest in leveraging this technology and making use of the cloud for internal-facing applications.

And that said, the issue with the purely public cloud is that it's very complex and difficult to set up the security required to bring online an internal-facing application. You need a secure connection to your internal resources to integrate this with the rest of your infrastructure. You need a secure connection for your users to be able to access this. You need integration with directories and things like that, and all of that presents something of a barrier to entry.

We still know customers that have experimented with infrastructure as a service and PaaS for those types of applications, because they've heard all this hype. They've heard everything people said about cloud, and they want to make sure they understand what's going on. They're planning appropriately around these new developments. There's a lot of talk about some of the things that folks can use to mitigate those concerns.

"Private cloud" is a term that's been tossed around, but not clearly defined. There's a lot of confusion around it, because it's not clear.

. . . the issue with the purely public cloud is that it's very complex and difficult to set up the security required to bring online an internal-facing application.

Some folks just use it to mean a virtualization technology, and some use it more to refer to a full-on utility model for delivering compute power and computing resources.

Then there's the term that I think was first used about a year ago by a blogger -- "virtual private cloud" -- the notion that the resources exist outside your enterprise, but when you provision them, when you generate use for them, they are your resources. They're not connected to the public Internet. They're connected via some, sort of virtual private network connection to your internal network.

As you add to that collection of machines, those virtual resources are yours, and yours alone, fully secured, and effectively behind your firewall. Right now, it's just something folks are talking about. When that becomes a reality, it's going to be a huge influence in the way large enterprises look at cloud computing.

Gardner: Now, Rourke, wouldn't it be possible with this vision that you might create applications in the cloud and then you might want to host them in different places, depending upon how you would use that application.

Perhaps the application would be internal facing -- say, a business-to-employee (B2E) application, which you might put on one of those virtual private clouds. Or, you might have the same application that you use in the context of an ecology of business processes that we discussed with David Kelly.

You might want to have that in some respects in a cloud, but controlled with access, governance, and privilege policies and so forth. Then you might even want a very similar or a version of that application to be wide open, customer facing, the more the merrier. This all also sounds like a need for management policy governance and integration.

Exciting and scary

McNamara: Absolutely. That notion of a hybrid cloud, made up of all those different pieces and ones we haven't even thought of yet, is something that's both very exciting and very scary for large IT organizations.

It gives them an enormous range of flexibility, and it gives them an enormous range of power, but at the same time they're all worried about how they're going to be able to control. They worried about how they'll make sure that all of the stuff deployed in those environments is in compliance and talks together, make sure the right people can get into those different environments to change the appropriate applications and adjust the business logic, and that corporate standards are adhered too.

That's one of the things that we're looking very deeply at TIBCO Software. That's cloud governance, how we can expand the technology and experience we already have in service governance out to cloud governance, and to really take a look at that holistic hybrid cloud picture. We're trying to figure out how we can tie it all together for IT organizations, take away some of the complexity, and make it so that they can be very productive with those technologies.

Gardner: Mike Meehan, just as the world is becoming, apparently to some people, unsafe for service-oriented architecture (SOA), suddenly it's safer

Well, to knock a recent public fear on its backside, SOA is not dead.

for cloud governance. Are we talking about the same capabilities? Where companies may have been leery about horizontally applying SOA internally, they're going to have to resort to it anyway, because they are going to have to deal with these hybrid cloud issues.

Meehan: Well, to knock a recent public fear on its backside, SOA is not dead. All the things that we were doing inside of service orientation are still going on. I don't think you can move out to the cloud unless you service orient. One doesn't exist without the other. Of course, you're going to have to govern what comes in through the cloud, and that's a whole new layer of governance. We're seeing companies that are putting tools out there to help you do that.

Just recently, Vordel has an edge-networking device to help you govern your consumption of cloud-based resources. Appistry also has created some management tools along those lines.

We're seeing these companies taking what we were calling SOA management software and devices and pushing them out to the cloud. It's a fairly natural progression. TIBCO is absolutely right to be thinking in terms of this is the infrastructure you have to manage. You can't just suddenly grab things from outside and let them run wild internally. There has to be some adult supervision, and there's a huge business opportunity that comes with that.

As you use SaaS, as you bring in infrastructure and as you have your applications get infrastructure from cloud vendors, those are all going to be things that you're going to have to monitor and take care of as a business. You can't just say, "Well, that touches somebody else. Therefore, I can't care about it." This is your business. You have to care about it.

'Rogue' activities

Gardner: Let's take this to Jonathan Bryce. If you have developers that are perhaps doing rogue activities vis-à-vis your services, you would want to be a good partner with that enterprise in terms of its more official -- for lack of a better word -- IT activities. How do you bridge the gap, or do you leave that to somebody else?

Bryce: Developers come to us from larger companies. It's completely automated to get started. So, sometimes they come, and we don't even realize that they're using the system, until they're well into it.

Even these “rogue developers” are pretty diligent about making sure they inform us what they are doing. If they have special compliance requirements or governance needs, a lot of times they'll have questionnaires, security questionnaires, or operational questionnaires. We engage with different groups within our organization to complete those and help them get all that that information filled out.

Generally, the developers come here because they're trying to get some flexibility, speed, and capacity that they're not able to get internally. Most of them are fairly professional and straightforward about their organization. That's definitely what we prefer, because we want to build relationships with all of these enterprises over the long term, so that we can help them with more and more of their needs.

Gardner: What about the pace of this in the market? It seems to me that Amazon is moving very quickly. In fact, when they came up

Generally, the developers come here because they're trying to get some flexibility, speed, and capacity that they're not able to get internally.

with Amazon Web services, I don't think they anticipated that their test and dev portion of the business would become predominant. But that's okay, because where developers go the runtime usually follows.

We're starting to hear more about Java in this cloud. We're hearing more about .NET at Microsoft with Azure. We're hearing more about data crunching, vis-à-vis MapReduce-type technologies. What's your sense, Jonathan, given that you're a vendor in the business? Is Amazon in a sort of a mad dash to get out in front on this, and in a sense of dragging the other players along, and, as a result, they have to be there too?

Bryce: Amazon has created a great set of products. They've created infrastructure products that really are very similar to what people are already used to running. They also are kind of at a lower level. The lower level you go to, the more flexibility you have to customize it, and the more responsibility you have as well.

You can set up Amazon infrastructure and lock down network access. You can remove software from the system. You can have a lot of control over it. That's been a big part of their rapid growth. It's something that that's pretty similar to what people are already used to working with, but you can get it a lot faster and you can pay in a more utility manner.

Now, Microsoft is coming out with Azure, which is built around .NET. App Engine announced Java support. Our products have already been built around standard frameworks. To move that rapid adoption from infrastructure up to the higher levels, one of the keys is to try to work within the frameworks and the technology stacks that people are used to working with.

App Engine will see more rapid adoption of Java where they have implemented a lot of Java standards, the data API, the messaging API. Some of those things that they are adopting are official parts of the Java stack. I think that there will be more rapid adoption of that, versus the Python offering, which was a little bit nonstandard and a little bit out of the norm of what companies were used to dealing with.

This is what you see in every part of technology. Operating systems over time have standardized even desktop processing applications. You have a word processer, a spreadsheet, and presentation software. These things all standardize in technology, and that's when the adoption really spreads. That's what we're seeing right now as the PaaS offerings mature across the board.

Java in the cloud

Gardner: Now, Rourke McNamara, more Java in the cloud -- whether it's at Google or somewhere else -- means more enterprise-caliber, more transactional applications, and perhaps baseline business services coming across the cloud, all of which is probably good news for an integration vendor.

McNamara: Definitely. We've gotten a lot of interest from our customers in standards-based or normal frameworks and normal technologies in the cloud. The big barrier that we've seen with a lot of our customers to adopting PaaS has been that, up until very recently, just about none of them were standards based. They were a completely new and proprietary language or technology that was visual, something like Python with a custom API for Google App Engine or some sort of JavaScript for the other folks out there.

Our customers are scared enough of moving to this brand-new technology and taking that leap, but to do so in a way that they are building an application that can never run anywhere but in the cloud doesn't make sense for them. Dana, as you mentioned a couple of times, folks are more and more trying to build stuff that is reusable. If they build it for one particular application, they can re-purpose it for another application, or reuse parts of it for yet another application.

By using standards-based technologies -- Java or Spring, for example -- folks are able to build applications that are a bit more portable, a bit more reusable, and that aren't a giant leap into the cloud with something that they're not going to be able to bring back in house if the cloud thing doesn't work out for them.

Gardner: To this issue of cloud portability or cloud neutrality, we recently saw something called the Open Cloud Manifesto. I believe TIBCO was a signatory in support of that. Weren't they?

McNamara: No, we were not.

Gardner: You are not. How come?

McNamara: We got notice of that a little bit late in the game, and we just didn't have enough time to evaluate whether or not it makes sense.

By using standards-based technologies -- Java or Spring, for example -- folks are able to build applications that are a bit more portable, a bit more reusable

We didn't want to just rubber-stamp it, without really understanding what was going on, and there was a bit of a blowup there between, I think, Microsoft and Google over that.

Gardner: Right. But the general concepts of openness, neutrality, and portability, these are all important aspects from where you stand?

McNamara: They absolutely are, and as long as there is some sort of a manifesto, or some sort of set of standards and principles that are developed in an open fashion with everyone working together, we would definitely support that.

Gardner: Let's go around our group of analysts. Jim Kobielus, how do you feel about open standards? I guess it's like mom and apple pie, but how important is it for the total cloud ecology thing to develop and become a productivity and value to enterprise?

Kobielus: Very important. People often refer to "the cloud" by that phrase, as if this is a one unified platform, and it's the exact opposite. Every public cloud is essentially its own silo or stovepipe right now with its own standards and interfaces.

Gardner: Like the early Unix days, right?

Against the grain of SOA

Kobielus: Yup. As I pointed out in a recent article I wrote, right now the current state of cloud computing sort of goes against the grain of SOA. SOA is all about platform agnosticity and be able to port services flexibly and transparently from one operating platform to another, because they are all implementing these common SOA standards.

Then, when you talk about exporting them to the so-called cloud or the atmosphere full of clouds that's out there right now, the turbulent atmosphere, it becomes kind of absurd. Even a vendor like Microsoft who's both in the SOA world, and now increasingly with Azure in the cloud world, would have a disconnect between those two platforms.

They haven't really done a good job of closing the gap. If you've written applications to .NET and to their whole SOA platform, are they portable as is to Azure? No. Just by itself, a single vendor not getting its full SOA act together between the premises-based, and the cloud strategies should set off warning bells in every IT shop that has standardized with Microsoft, for example.

Gardner: It must be tempting though. If you could really lock up and create the "de-facto industry standard for cloud implementation and runtime, wow, that would be a really nice place to be. Just like it is if you can rack up the "de-facto standard" in on-premises runtime.

Kobielus: Right.

Gardner: Shall we expect them to try?

Kobielus: Of course they're going to try to dominate the cloud, just like they try to dominate the whole application server world, and they are not going to succeed.

Gardner: Jonathan Bryce, are you guys Baskin-Robbins when it comes to clouds -- 31 flavors, anybody's cloud will host it for you? What's your position on this openness?

Bryce: We mentioned earlier the Open Cloud Manifesto, which we were a signatory to. It was interesting the way that evolved. It was an idea among just a small group of people. It wasn't ever intended to really be, "This is the mandate." Then, a few of other companies started talking about it. The goal was really to put something out there that says there should be some sort of a real effort to standardize all these things.

Ironically, the process was not as open as it should have been, but the idea behind it is pretty valid. We definitely support the idea of standards, interoperability, and portability.

Rackspace has always been a supporter of various technologies. We always supported Windows, we always supported different distributions of Linux. We want to add value on top of the technology, versus being a technology vendor. So, we are not always going to be the cheapest option. We are not always going to be the commodity provider for something.

In terms of vendor lock-in, and requiring a specific deployment steps or development languages, that's not the stance that we take, because we would prefer to allow people to be able to run different applications in the environment that works best for them. Sometimes, that may not be us, but a lot of times we can add extra value on top of just the technology.

Part of the issue right now with all of these standards is that the providers and the vendors are all still developing our basic products lines. We're still developing what our niche is going to be and what our special sauce is? So, there hasn't been a lot time stick our heads up and say, "Okay, this is what they're doing, and this is what we're doing, and it makes sense for us to tie these together."

Picking one flavor

Gardner: Mike Meehan, do you think there is a temptation for enterprises to say, "We're a Java shop," or "We're a .NET shop? We only need to pick one flavor of cloud. As long as their services are loosely coupled, and we can interoperate, then maybe we're not too concerned about the underlying runtime. We'll look for the best synergy between the tools and the platform, the automation, and the plumbing." Does that make sense, and do you expect that we're going to see a rerun of the platform wars, but now at the cloud abstraction?

Meehan: Some shops will initially do what you just described. I don't think it makes sense. They'll do that because they haven't really thought it through. Openness is going to overrun that sort of thought. Hopefully, enough users have figured out that you need to be so far beyond Java vs .NET at this point in your life that this really shouldn't be the discussion that’s front of mind anymore.

Obviously, there are programmers who know one versus the other, but it's not what's driving your business, and there are larger concerns. The cloud allows you to get to different layers of abstraction and larger concerns, and you shouldn't just necessarily be Java and .NET.

So, this whole notion that somebody has to roll this whole thing up is wrong -- I'm just going to go right to Microsoft and get it from them. I

What we've seen from Microsoft to date hasn’t made a lot of sense. That's why Google hasn't really taken off yet, because it hasn't done something quite elastic enough yet.

agree with Jim. If they try that, they are going to fail, and they're going to fail hard. I hope they have a sense of that, and I hope they're looking at this as a more inclusive universe, rather than a more exclusive universe. Amazon is doing really well right now with EC2, because it is most generic. For example, Sun can put Rails 2 on top of Solaris, and put that up in EC2.

Gardner: We also have Red Hat Enterprise Linux available is a runtime environment?

Meehan: Exactly, and that's all just in there. You can throw anything in there. It really is elastic. Elasticity is what's got traction for Amazon right now. It's not that Amazon has the most unified, elegant platform offering out there. What we've seen from Microsoft to date hasn’t made a lot of sense. That's why Google hasn't really taken off yet, because it hasn't done something quite elastic enough yet.

Gardner: We haven't mentioned, but they came from the SaaS side, and they have an interesting balance between proprietary and open. They've tried to create an ecology, but they also certainly want to be a destination that makes more sense to stay than go. “How do you view what Salesforce has done, and is that the model that we will see -- that "cloud of clouds" model.

Meehan: What's interesting about Salesforce is that, as you said, they just started doing stuff, and it gained traction. Now, you're thinking of them as platform. You're not going to go pick and grade various pieces of SaaS.

Gardner: More than just one application as a service.

Meehan: Exactly. There's something to just getting out there and doing stuff. I don't think they've bottled the way they to do it, but they have come up with a nifty process for getting there, which is, get involved, start getting stuff out there, and you'll find out what sticks. We're all theorizing about what's going to happen? Salesforce is an example. What's going to happen is going to be a function of what we do, and we are just not going to know until we do it. So let's start getting working.

The pain of transition

Gardner: Dave Kelly, it's a little easier for someone like Amazon that's got a retail business to draw on and to monetize on its investment for infrastructure. It's another thing for Google that come in with its advertising base to create these services. They can make these services in the business models that they have dovetail, with this new cloud model.

For somebody like Microsoft, coming from an older licensed software business and trying to re-orient and re-factor that into a pay-as-you-go service, doesn't that involve some significant pain making that transition?

Kelly: It should. This a real challenge for Microsoft. It's like the open systems discussion we had a little while ago. It makes more sense for players that actually earn their revenue in a different form than traditional operators, because someone like Amazon has a core business.

Someone like Microsoft is kind of painted into the corner at the moment. That's a challenge not just for Microsoft, but for other traditional vendors.

They can expand into this new area by offering low-cost services that take away from competitors, but don't hurt their core business.

Someone like Microsoft is kind of painted into the corner at the moment. That's a challenge not just for Microsoft, but for other traditional vendors. I think there are opportunities. With Salesforce, you can make that same kind of argument. That's more an environment for that sort of solution specific type scenarios related to Salesforce. I don't see it growing into a broader, more common application platform. It could, but I don't see that.

Gardner: Okay, we're just about out of time. Let's go to Jonathan. Is that what we were seeing now -- a bunch of barbarians at the gate in the form Salesforce, Google, and perhaps Mosso as well?

Bryce: Perhaps. Maybe it's something friendlier than barbarians, but there's one thing that's important to add to the discussion of openness, standards, and the point about Amazon being very flexible and something that you can adapt in a lot of ways. We aren't seeing the potential of cloud yet. We're going to see the real potential of cloud, when there's some interoperability and portability that allows just amazing applications and systems of systems to be built on top of all of these clouds.

That's when we're going to see how this shift in computing is going to change the world. When you can develop against multiple clouds, when you can get storage in multiple occasions, when you can get as much compute as you need to run a simulation or a model, and have thousand of servers, and all of these kinds of things together, that's when it's really going to be amazing.

To do that, you will see vendors building businesses on top of the cloud. We're not going to build every feature that's going to be implemented on our infrastructure. There are ecosystems that have developed around Amazon, us, and the other providers. And we know that ecosystems will start to join together, and we'll come up with some really great tools, some really great new technologies, that harness all this power. That's when this is going to be a very exciting space.

Gardner: Okay, Rourke, last comment to you. How do you view these cloud, permutations, particularly PaaS? Are they barbarians at the gate or liberators?

PaaS as 'liberator'

McNamara: I definitely view PaaS and some of these other permutations of cloud service as liberators. If you look at what PaaS really does for developers and IT organizations, it frees them from having to worry about a bunch of details that have nothing to do with their core business and don't even have anything to do with the application that they are writing.

It frees them from having to install platform software on a bunch of machines, putting those machines into racks, connecting them up to the management and monitoring infrastructure, and getting everything set-up so that those machines are fault-tolerant and the loads distributing appropriately. It frees them from making sure that they have the right machines to handle the load, and making sure that they are predicting load increases and capacity increase or requirement increases, and far enough in advance that they're able to buy new machines.

All that stuff has nothing to do with delivering new functionality to their business users. That's really what their job is, delivering new functionality to their business users. PaaS lets them focus ideally on delivering new functionality, and lets someone else worry about all of those of details.

Gardner: Picks and shovels, to the liberators, right?

McNamara: Exactly.

Kobielus: I second that. It's liberation, because, to carry forward the scenario that I described a little while ago, you should be able to develop your analytical data mart and test it inside an Amazon cloud. But, if the Google cloud gives you a cheaper hosting, then you should be able to flexibly migrate that entire analytical data mart after production to the Google cloud where it is hosted for X number of months and years, until you're ready to deploy your premises-based data warehousing cloud, a petabyte-scale cloud.

It should be migrated from Google to your premises, and back and forth, depending on your changing operational and performance needs. For this kind of a project, a data mart for data mining, the PaaS model should give you that flexibility and freedom of not having to worry excessively about the hosting issues.

Gardner: Well, we'll have to leave it there for today. Please allow me to thank our guests. Jim Kobielus, senior analyst at Forrester. I appreciate your time, Jim.

Kobielus: Sure.

Gardner: David A Kelly, president of Upside Research. I appreciate it, Dave.

Kelly: Always fun to be here.

Gardner: Mike Meehan, senior analyst at Current Analysis. Always a pleasure Mike.

Meehan: Thank you, Dana. I just want to add that Paas, is, as far as I know, a maker of Easter egg color dyes.

Gardner: It's rubbing off this time of year. There's another pun for you.

Bryce: It's full of PaaS-abilities.

Gardner: Jonathan, PaaS is not passé either. Jonathan Bryce, co-founder of Mosso at Rackspace. Thanks for joining us.

Bryce: Thanks for having me.

Gardner: And, Rourke McNamara, product marketing director at TIBCO Software. Thank you, Rourke.

McNamara: Thank you, Dana.

Gardner: I also want to thank our charter sponsor for the BriefingsDirect Analyst Insights Edition Podcast series, Active Endpoints, maker of the ActiveVos visual orchestration system, as well as continued underwriting from TIBCO Software.

This is Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening and come back next time.

Listen to the podcast. Download the podcast. Find it on iTunes and Charter Sponsor: Active Endpoints. Sponsor: TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at

Edited transcript of BriefingsDirect Analyst Insights Edition podcast, Vol. 40 on the promises of platform as a service and its apparent lack of traction among enterprise managers. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.