Thursday, August 06, 2009

BriefingsDirect Analysts Debate the 'Imminent Death' of Enterprise IT as Cloud Models Ascend

Edited transcript of BriefingsDirect Analyst Insights Edition podcast, Vol. 43 on the health of corporate IT and whether reports of its demise are premature.

Download the transcript. Read the summary blog post. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.

Dana Gardner: Hello and welcome to the latest BriefingsDirect Analyst Insights Edition, Volume 43. 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, and through the support of TIBCO Software.

Our topic this week on BriefingsDirect Analyst Insights Edition, and it is the week of June 8, 2009, centers on the pending purported death of corporate IT, and perhaps the unplugging of the last on-premises Web server any day now.

You may recall that in the early 1990s, IT pundits, and my former boss Stewart Alsop, glibly predicted at InfoWorld that the plug would be pulled on the last mainframe in 1996. It didn't happen.

Stewart apologized, sort of, and the mainframe continues to support many significant portions of corporate IT functions. But Stewart's sentiments are newly rekindled and expanded these days through the mounting expectations that cloud computing and software-as-a-service (SaaS) will hasten the death of on-premises enterprise IT.

Some of the analyst reports these days indicate that hundreds of billions of dollars in IT spending will soon pass through the doors of corporate IT and into the arms of various cloud-service providers. We might conclude that IT is indeed about to expire. Not all of us, however, subscribe to this extent in the pace of the demise of on-premises systems, their ongoing upkeep, maintenance, and support.

To help us better understand the actual future role of IT on the actual floors inside of actual companies, we're joined by our guests and analysts this week. First, Jim Kobielus, senior analyst at Forrester Research. Hey Jim.

Jim Kobielus: Hey, Dana. Hey, everybody.

Gardner: Tony Baer, senior analyst at Ovum.

Tony Baer: Hey, Dana. How are you doing?

Gardner: Brad Shimmin, principal analyst at Current Analysis.

Brad Shimmin: Hi, Dana.

Gardner: Ron Schmelzer, senior analyst, ZapThink.

Ron Schmelzer: Hi, guys, just unplugging my mainframe, as we speak.

Gardner: And, for the first time on our show, Sandy Rogers, former program director at IDC, and now independent IT analyst and consultant. Welcome, Sandy.

Sandy Rogers: Thanks, Dana. Great to be here.

Gardner: And, as our guest this week, welcome Alex Neihaus, vice president of marketing at Active Endpoints. Hey, Alex.

Alex Neihaus: Hi, Dana. Hi, everyone.

Gardner: Well, let's start with you, Jim Kobielus, if you don't mind.

Kobielus: I don't mind.

Gardner: We've heard this before, the same story, new trend, new paradigm shift, money to be saved, pull out the plug, you'll get it off the wire, or you'll get it from much lower cost approaches to IT.

I do believe that cloud computing is going to have a pretty significant impact and we've discussed that quite a bit on our show so far. What's your take? Do we have a sense of the mix? Is there any way to predict what's going to happen in, say, five years?

Death notice premature

Kobielus: There are plenty of ways to predict what's going to happen in five years. I need to buy a dartboard. That's one of the ways. I can predict right now, based on my conversations with Forrester customers, and specifically my career in data warehousing and business intelligence (BI). This notion of the death of IT is way too premature, along the lines of the famous Mark Twain quote.

If you look at a vast majority of enterprise data warehousing in BI environment, there is a bit of a movement toward outsourcing of the date warehouse into the cloud. There is a bit of a movement toward moving more of the report and dashboard and analytic application development to the end user or to the power user or subject matter expert and away from the priesthood of mathematicians, statisticians, professional data modelers, and data-mining specialists that many large companies have.

There is a bit of a movement in both directions. But it's only movement. In other words, there aren't a substantial number of enterprises that have outsourced their data warehouse or their marts. Probably there aren't that many commercial options yet that are fit to do so. Only a handful of data warehousing vendors offer a hosted solution, a SaaS, or cloud solution. I've been telling people that 2009 is not the year of the cloud in data warehousing, nor is 2010. I think 2011 will see a substantial number of data warehouses deployed into the cloud.

Gardner: Well, Jim, will that be taking them off of the corporate network and putting them in the cloud or will they just be new ones on the cloud?

Kobielus: The component of your data-warehousing environment that will be outsourced to public cloud, initially, in many cases, will not be your whole data warehouse. Rather it will be a staging layer, where you're staging a lot of data that's structured and unstructured and that you're pulling from both internal systems, blogs, RSS feeds, and the whole social networking world -- clickstream data and the like.

They will be brought into cloud storage services that will operate as a staging layer

First is security. You need strong control and you need to also be able to monitor it 24/7, because it's the most fundamental thing that you run your business on.

where transforms, cleansing, match and merge, and all those functions will be performed on massive amounts of data. We're talking about petabytes where it makes more sense, from a dollars-and-cents standpoint to use a subscription service in a multi-tenant environment.

Gardner: We're still going to see data growing on-premises as well.

Kobielus: Yeah, we're definitely going to see data growing a lot on-premises. The core data-warehousing hub where your master data is stored -- for most companies of most sizes -- will remain on-premises for lots of reasons. First is security. You need strong control and you need to also be able to monitor it 24/7, because it's the most fundamental thing that you run your business on.

There are lots of reasons why the centerpiece of your data-warehousing environment, the master tables, were made on-premises. For the foreseeable future, I sense strong reluctance from corporate IT to outsource that. As to the whole front-end mash-up side of these all sort of developments, I'm doing a report that will be published in about a month on the uptake of that approach. But, that's several years down the road, before we see that come to fruition. So, I don't think IT is dying anytime soon.

Gardner: Tony Baer, what about applications?

Cloud is transformational

Baer: Well, I just completed actually a similar study in application lifecycle management (ALM), and I did find that that cloud certainly is transforming the market. It's still at the very early stages, but it's not going to be basically a one single, monolithic, silver-bullet approach. And, not all pieces in the app lifecycle are as well suited for the cloud as others.

I found that two areas really stuck out. One is anything collaborative in nature, where you need to communicate -- especially as development teams go more global and more distributed, and of course, as the pace of business changes the business climate and accelerates -- it's more important than ever to get everybody on the same page, almost literally. So, what I found was that planning, budgeting, asset management, project portfolio management, and all those collaborative functions did very well.

At the other end of the scale, another side that did very well was something that I think Jim was sort of hinting at, which is anything that had very dynamic resource needs,

When you're developing code, you don't want to have to deal with any type of network latencies that are going to come up when you deal with cloud.

where today you need a lot of resource, tomorrow you don't. A good example of that is testing -- if you are a corporate IT department, which has periodic releases, where you have peaks and valleys in terms of when you need to test and do regression test.

Gardner: Platform as a service (PaaS)?

Baer: Yeah. What I found though that did not map well to the cloud was anything that related to source code. There were a number of reasons for that. One is, basically, that developers like to have the stuff on their own local machines.

There is a degree of control that you like, but there are some tactical reasons. When you're developing code, you don't want to have to deal with any type of network latencies that are going to come up when you deal with cloud. No matter how good the bandwidth, there are always going to be times when there are going to be some speed bumps.

But, the other part was also related to IP, which is source code before it's compiled in the binaries. It's basically pretty naked and it's pretty ripe for stealing. This is your intellectual property. Today, if you're doing development, it's because there aren't packages that are available to supply a generic need. It's something that's a process that's unique to your organization.

So, I got a lot of reluctance out there to do anything regarding coding in the cloud. There is the Bespin project on Mozilla, but that's the exception to the rule. So, in terms of IT being dead, well, at least with regard to cloud and on-premise, that's hardly the case in ALM.

Gardner: Brad Shimmin, why do we see these reports, some of them coming out of Wall Street? They're supposed to be smart money saying $120 billion of IT is going to be in the cloud in the matter of two or three years. Is it that they don't understand what cloud is, or are they dead wrong?

Shimmin: I don't think they're dead wrong. As Tony was saying, it depends on what you're putting in the cloud. Because I follow the collaboration area, I see that happening much, much more quickly, and, frankly, much sooner than even the discussion we've been having recently about cloud computing.

Way back in the late 90s, and early "0-dots," Microsoft and IBM were making big money out of their managed hosting services for Exchange and Notes, and they are pushing that downstream a little bit more now to get to the channel and the long tail.

Gardner: So there is not a lot of intellectual property in a messaging transfer agent?

Bothersome IT functions

Shimmin: That's just it. Those are the functions that IT would love to get rid of. It's like a diseased appendix. I would just love to get rid of having to manage Exchange servers. Any of us who have touched any of those beasts can attest to that.

So, even though I'm a recovering cynic and I kind of bounce between "the cloud is just all hype" and "yes, the cloud is going to be our savior," for some things like collaboration, where it already had a lot of acceptance, it's going to drive a lot of costs. If that's what Wall Street is talking about, then, yeah, I think they're pretty much accurate.

Gardner: Ron Schmelzer, we certainly heard a lot about cost reduction. It's certainly top of mind in a recession. I also think that cloud computing can offer some significant cost savings, but to what degree are we talking about disrupting the status quo in most IT departments?

Schmelzer: It's really interesting. If you look at when most of the major IT shifts happen, it's almost always during period of economic recession. The last time was in 2000-2001, when we first started really talking about service-oriented architecture (SOA). In the mid- '90s was when we really started pushing out the Web. In the early part of the '80s, when recession was kind of bad, that's when personal computers started coming about.

You kind of go back into this package every time. Companies are like, "I hate the systems I have. I'm trying to deal with inefficiency. There must be something wrong we're doing. Let's find some other way to do it." Then, we go ahead and find some new way to do it. Of course, it doesn't really solve all of our problems. We spend the next couple of years trying to make it work, and then we find something new.

The cost-saving benefit of cloud is clearly there. That's part of the reason there is so much attention on it. People don't want to be investing their own money in their own infrastructure. They want to be leveraging economies of scale, and one of the great things that clouds do is provide that economy of scale.

From my perspective on the whole question of IT, the investments, and what's going to happen with corporate enterprise IT, I think we're going to see much bigger changes on the organizational side than the technological side. It’s hard for companies to get rid of stuff they have invested billions of dollars in.

Gardner: Wait a minute. So, this is like a neutron bomb. The people die, but the machines keep running?

Schmelzer: Actually vice versa. The machines might change and the machines might move, but IT organizations will become a lot smaller. I don't really believe in 4,000-person IT organization, whose primary job is to keep the machines running. That's very industrial revolution, isn't it?

Gardner: Sandy Rogers, the theory is good, the vision is good, but so was the theory in 1995 that you'd pull out the last mainframe in a year. What's your perspective, given that you've been tracking enterprise infrastructure software for quite some time?

The cost of change

Rogers: Well, it's interesting. Many organizations have avoided legacy modernization projects due to the cost of change. It's not just about the technology replacement. It's a loss of capabilities. It's the change in human workflow and knowledge base. All that is a critical consideration. I see enterprises all the time that are caught between a rock and a hard place, where they have specialized technologies that were built out in the client-server era. They haven't been able to find any replacements.

So the idea of software-as-a-service (SaaS), that one-to-many model, means the kinds of replacements that are available will be very generic in nature, for the most part. There will be some niche capabilities, moving way out in the time horizon. But, the ability to take a legacy system that may be very specialized, far reaching, have a lot of integrations and dependencies with two other systems is a very difficult change. A company has to get to a very specific point within their business to take on that level of risk from change.

Gardner: It's one thing to change from a legacy system to a more modern standard-based hardware and operating system platform environment and to frameworks

It's not to say it won't be done, but it certainly has a big learning curve that the whole industry will be engaging in.

for development. That's not quite the same, though, as making a transition to cloud. Do you think they go hand-in-hand?

Rogers: One thing to think about is there are so many different layers of the stack that we're talking about. When we're talking about cloud and SaaS, it's going to impact different layers. So, there may be some changes in the types of deployments that go on, the target locations.

It reminds me of the film, Pretty Woman. That's "just geography," and that's the way I envision the first wave moving out. We may want to think about leveraging other systems and infrastructure, more of the server, more of the data center layer, but there is going to be a huge number of implications as you move up the stack, especially in the middle-ware and integration space, and pick and choose different applications and their capabilities.

There are a lot of systems out there that are not designed to be run in this kind of capacity. We're still at the very beginning stages of leveraging services and SOA, when you look at the mass market. What I've been discovering in speaking with enterprises that are either doing SaaS as a business or as an enterprise is that the first thing they're thinking about is that the architecture has to able to support this kind of dynamic access and the ability to scale.

So, there's a lot of work that needs to be done to just think about turning something off, turning something on, and thinking that you are going to be able to rely on it the same way that you've relied on the systems that have been developed internally. It's not to say it won't be done, but it certainly has a big learning curve that the whole industry will be engaging in.

Gardner: Not about just pulling a plug at all.

Rogers: Yeah.

Gardner: Alex Neihaus, you're someone who's actually in the software business -- unlike the rest of us. And, by the way, thanks very much for sponsoring the show. We really appreciate it.

Neihaus: Our pleasure,

Gardner: Tell me a little bit about your perspective as someone who is delivering software, productivity, and value to enterprises. Why not go up on someone else's cloud and deliver this strictly as a service?

Borg-like question

Neihaus: We think that this is a Borg-like question -- who assimilates whom? Ron was exactly correct that cloud and the associated technologies that we describe today is today's shining new toy. What we find more interesting is not the question of whether the cloud will subsume IT or IT will subsume the cloud, but who should be creating applications?

And, there is a meta question, or an even larger question, today of whether or not end users can use these technologies to completely go around IT and create their own applications themselves? For us, that seems to be the ultimate disingenuousness, the ultimate inability for all the reasons that everyone discussed. I mean, no one wants to manage an Exchange server, and I was glad to hear Brad include Notes Server in that list, but, in fact, IT is still doing it.

So for us, the question really is whether the combination of these technologies can be made to foster a new level of collaboration in enterprises where, frankly, IT isn't going to go away. The most rapid adoption of these technologies, we think, is in improving the way IT responds in new ways, and in more clever ways, with lot more end-user input, into creating and deploying applications.

You hear a lot of people talk about the generational shift in business people. I agree that there is a lot more familiarity with IT among business end users, but we don't

For us, the cosmic question is whether we are really at the point where end users can take elements that exist in the cloud and their own data centers and create processes and applications that run their business themselves.

hear from our customers that business end users even want to be in the business of creating or manipulating applications in IT, in the cloud, or anywhere else.

Gardner: What I hear you saying is that you see the IT department as your customer, but also, at some level, the end user is your customer. You need to make them both happy, but can you make that end user happy without the IT department?

Neihaus: Our answer is no, simply because of some of the things that Sandy was talking about. There are legacy systems -- there are plenty of things lying about, would be the right way to put it -- that need to be integrated, using technologies that are modern and appropriate.

For us, the cosmic question is whether we are really at the point where end users can take elements that exist in the cloud and their own data centers and create processes and applications that run their business themselves. And our response is that that's probably not the case, and it's probably not going to be the case anytime soon. If, in fact, it were the case, it would still be the wrong thing to do in enterprises, because I am not sure many CEOs want their business end users being IT.

Gardner: Now, your product is something that's designed to make crafting and managing business processes easier and more visual. You're trying to elevate this from a code-based or tool-based process to more of a visual, something that an analyst level person could do, but not necessarily a line-of-business person. So, you've already tested the waters here and your conclusion is that IT can't go away.

Model-based environment

Neihaus: Correct. We're a model-based execution environment, and you're exactly right that we try and expose those processes to the business. But, there are what I call "pretty pictures" kinds of approaches to this, and they can exist in the cloud and they can exist in IT. But, for most people, those are customizations of existing applications.

You might go buy a call-center application and allow end users to modify the workflow. But, once you get beyond the pure human workflow, and you begin to integrate the kinds of systems that Sandy was talking about, and I think Ron was talking about, you're beyond the skill, desire, or capability of an end user.

Now, can these things be composed from elements that exist in the cloud? They could be and they probably should be. But, whether the cloud represents something that can enable business users to eliminate IT is a huge stretch for us, based on what we experience in the marketplace.

Gardner: We haven't really explored that dimension where the cloud fits. Does the cloud get between the end user and IT, or is the cloud behind IT and IT gets between the cloud and the corporate user and perhaps even their customers out in the public domain?

Brad Shimmin, recently we saw some inkling about Google Wave. What that's going to represent? I found the demo and the implications very interesting.

We've all been end users at some point and still are in many ways, for what we do day-in and day-out. I think all of us here will attest to the fact that we can be incredibly stupid.

Google seems to think that they can go directly to the end user, at least for some elements of collaboration for bringing different assets together in a common view -- maybe some check-in, check-out benefits, using a spectrum of different communication modalities and synchronicities.

What's your take? Is Alex right that we're not going to get too much out to the end user directly, that IT is going to be part of that? Or, are we perhaps being a little bit too cautious about what end users are capable of?

Shimmin: We've all been end users at some point and still are in many ways, for what we do day-in and day-out. I think all of us here will attest to the fact that we can be incredibly stupid. Yesterday, when I was sitting on Microsoft's Virtual Analyst Summit, I heard them say that what they'd like to accomplish is for users to be able to open up an Excel spreadsheet and create a BI report that would normally take IT two weeks to do.

I thought, "Hey, that's terrific, but, oh dear Lord, you don't want anyone to do that, because they're going to use the wrong datasets, they're going to perhaps have the wrong transitions and transformations for data."

It's not as simple as the picture is being painted. With Goggle Wave, as we've said before, when they are talking about certain types of collaborative applications, that sort of mashability -- as Jim put it earlier -- is something users are capable of and comfortable with. It's within the bounds of something they know how to manage, and they know that what they get out of the application is right.

When I hear about customers being able to mash-up their own BI reports, for example, I think, "How would they know? How on earth would they know that what they've gotten out of it is correct?"

Gardner: And, would the security and regulatory compliance issues be maintained?

Loss of control

Shimmin: Sure, that's the other horn on the bull. The more you move into the cloud, the less control you have over the data. The vendors that I talk to realize that fact, but they still haven't come to a point in which you can control which data resides where and what happens to that data. This is even in the collaboration space, mind you, which is I've said is really getting out there ahead of a lot other ventures,

A lot of companies that say they are pure SaaS are really still using shared data resources on the back-end, which is not a good thing, if you really need to lock down that data.

Gardner: It's not really cloud. Is it?

Shimmin: No.

Gardner: Jim Kobielus, I'm sorry I cut you off earlier, but I wanted to get across the spectrum of our analysts, before we dug down too deeply. But, now is the time to dig deeply to this point that end users, even sophisticated power users in a corporate environment, are probably not going to be in a position of doing SQL queries or even queries that have been visually abstracted for them. We need a sort of intermediary group or capability between the consumers of data and the actual production of data. Isn't that right?

Kobielus: The intermediary group is the governance group. Alex, Brad, Sandy, and the others are talking about how, as you allow the end users or encourage them or require them to mash up the hone applications in their own data, in their own presentation layer, that becomes chaos unless you have strong governance.

As Brad said, when users are given a sandbox of their own, they should know that the whole sandbox, in fact, was built and is being monitored by IT, so that you're taking the right data, doing the right transforms, and applying the right presentation components, the right data model, the right calculation, as defined by your company, its policies, and its rules. You need strong governance to keep this massive cloud sandbox from just becoming absolute chaos.

So, it's the IT group, of course, doing what they do best, or what they prefer to be doing, which is architecture, planning, best practices, templates, governance control, oversight support, and the whole nine yards to make sure that, as you deal in new platforms for process and data, such as the cloud, those platforms are wrapped with strong governance.

Gardner: Tony Baer, perhaps what we are seeing is not the demise of IT, but the transformation and elevation in the role and importance of IT.

The other part is technical. If you're going to provide them the capabilities to mash up things, which is certainly valuable, you want to do this in a protected sandbox

Instead of doing support, maintenance, patches, and keeping the red lights out and the green lights on, they're going to be involved with the governance, provisioning, security, and more innovation in terms of getting closer to the productivity benefit than simply keeping the cycles going and the hard-drive spinning.

Baer: There's no question about that. It reminds me of some of the notion that to make things simple underneath the plumbing is very complex, so make things simple on top. As Jim is saying, you can't provide users the ability to mash-up assets and start creating reports without putting some sort of boundary around it.

This is process-related, which is basically instituting strong governance and having policies that say, "Okay, you can use these types of assets or data under these scenarios, and these roles can access this and share this."

The other part is technical. If you're going to provide them the capabilities to mash up things, which is certainly valuable, you want to do this in a protected sandbox. That's where I see technical innovations that could go to cloud, which would be like enterprise mash-up hubs -- probably a good example -- or like a report center.

I could use those Excel spreadsheets to generate those reports, but they're coming from a protected set of data for which there are very stringent access controls and governance. So, it's a combination of both process and technology.

The same cloud?

Gardner: Ron Schmelzer, I'm a neat person. I like things that follow in nice little neat packages that line up, and are not crooked. What I am starting to see now in this cloud evolution is one part of a cloud being something that end users would use, inside of companies or consumers at home through their mobile devices.

I'm also seeing the cloud providing these back-end infrastructure services, automation and lower cost, and building blocks for IT. And, IT has a value-added role on top of that. But, is it the same cloud? Is it a different cloud, and how would we manage this border between, "I want to use the cloud as an end user" and "I want to use the service from the cloud through the IT department control."

Schmelzer: It sounds like you have a future in interior decoration to put things in neat boxes, but that's why we call it a cloud, right? The reason we call these things cloud is because they're kind of amorphous. They don't have well-defined boundaries.

The whole reason for the metaphor "cloud" is that in network diagrams you want to show something outside the boundaries of the IT organization, but you don't know exactly how it's configured. You just represent it visually as a cloud, right? So, that's the conceptual model we are computing here, where you don't necessarily have all the details of the implementation.

Now, the question is: is the cloud boundary at the firewall or is the cloud boundary necessarily outside of the organization? Not necessarily. There maybe internal processes in IT or the IT organization that are leveraging aspects and elements that you don't have complete control over, in which case they are very cloud-like. They have all the same features and benefits of the cloud.

What we have to be aware is that there are a lot of different things that are wrapped up in the cloud. There's SaaS and application service provider stuff that we've been doing since late '90s. There's utility computing, grid computing, elastic computing, compute on demand, and all this sort of stuff.

The question is what benefits do we want? That's what differentiates cloud.

There's an increasing need to compose and integrate silos within organizations. That has a huge implication on governance activities.

It really is a third-party provider that we're paying for on a transactional model and leveraging infrastructure we have no visibility over, rather than a model that we have ownership of. We have cost visibility, but we have elastic consumption capability. So, we're using more of the implementations of the cloud.

Gardner: Sandy Rogers, you've been tracking governance capabilities, and is it the role of IT to further govern this amorphous boundary between what a cloud, off-the-wire set of services might bring to an organization in addition to governing the IT that goes on inside of their SOA activity. Is IT going to rise up to this or you are going to say, hey, that's outside of our purview and we are not interested.

Rogers: It's certainly within the purview of both IT and business, as partners, to address governance, whether it's internal to an organization or it's leveraging facilities that are external or outside the firewall. IT is still responsible for ensuring that whatever systems are used, how and where the technologies and being used, they accomplish the business goals.

It's off-loaded for support overall. They're going to have to be responsible to ensure that it fits in line with their governance policies in their meeting to set goal. I think the availability and maturity of technologies will evolve, and it will evolve in different spaces to be one-for-one able to be replaced.

The sophistication of the solution interfaces and the management in the administrative capabilities to enable governance, are very nascent in the cloud offerings. That's an opportunity for vendors to approach this. There's an increasing need to compose and integrate silos within organizations. That has a huge implication on governance activities.

Gardner: And, that doesn't even include these outside silos.

Step back and do the basics

Rogers: Yes. It's just being exaggerated with these cloud-based environments. What I've seen in looking at SOA governance is that for those companies that don't have good governance policies, programs, and procedures to start with really are in a situation where they have to step back and do the basics. Every time you end up with some type of distributed, federated environment, you have to look at all of those issues that relate to governance, whether it's compliance, security, management, or anything like that.

SOA, or any distributed environment, exaggerates this. Cloud will exaggerate it even further. Managing contracts and legal arrangements will be a growing emphasis within IT. What's interesting in the cloud space is that we're seeing a lot of packaged services, where one company may be engaging with a service provider, and that service provider is dependent on another service provider for, say, providing some compute infrastructure services.

Gardner: An ecology approach to this.

Rogers: Yes, having the visibility, having access to the right information to perform governance is going to be an area that needs to be worked on. It will have to be worked on sooner, rather than later, to win over those C-level executives who are very nervous about relinquishing control.

Gardner: Another area that I'd like to get into, before we run out of time, is the ability for the vendors, the software providers, to make a decent living. If they're only going to deliver what they do through a cloud model and they have a subscription they are going to charge per user per month, or some similar model, can they, in fact, cover their cost and make a profit?

JP Morgenthal, who has been on our show, has been critical and says that even open source is a threat, because of the same issue. The innovative, quality software won't get developed in the future, if the models don't support it. I'll take that to Alex as a software developer and provider of value. Is there a case here that the subscription model undercuts the viability of your business?

Neihaus: I don't think so, and I'll tell you why. Like any other vendor of any product in any marketplace, we'll sell our services or our products the way customers want to buy them.

The software market is very big. The market we exist in, the business-process management system marketplace, is very big. Companies like ours and others will adapt to what customers ask for

As of yet, at least in our case, we've had no substantive demand for subscription, which is closely associated with the open-source model. It turned out to be fairly expensive over a longer period of time, or per user per month hosted Exchange or Notes mailbox pricing. -- at least for the category in which we exist.

The software market is very big. The market we exist in, the business-process management system marketplace, is very big. Companies like ours and others will adapt to what customers ask for. We can be more nimble than some of the bigger players in this marketplace to responding to that, and that's the key point.

The very large, leviathan players in the space have the most to lose from any kind of change in pricing or distribution business models. So, there's a huge lethargy in the marketplace towards changing buying behavior.

Even if we wanted to promulgate and distribute a new business model, customers are so used to buying the way they have been buying from companies for such a long time that their internal processes from decision-making to contracting are wrapped around those models. It's something we would adapt to, but I think the market is going to change relatively slowly.

Gardner: Brad Shimmin, to Alex's point that the big players, the leviathans, have the most to lose from the wholesale move to cloud, that's in semi-agreement with this concept that moving to a services provisioning subscription model has its risks compared to a license on-premises, per processor type of model. Where do you come down on that?

Vendors will adapt

Shimmin: Well, I stand firmly on the side of broader ecosystems and the power to the people. So, my feeling is that the vendors will adapt to this, just as Alex was saying, but they're doing it slowly. When I look at Microsoft, Cisco, and IBM, for example, I see three very different approaches to that.

With Microsoft, they were pretty quick to roll out their Microsoft online services and firmly undercut the pricing that their partners could give their customers on hosted Exchange, for example. But, they set it up so that those partners could then build value-add on top of it to increase their revenues. As we've been talking about here, when it comes down to just a numbers game, it's hard to make money on just a pure services contract -- unless you have a huge scale to work with.

When Microsoft rolled out Azure -- last October, I think it was -- the plan was to allow their ecosystem, their channel partners, to build applications for vertical markets. These are the things they are good at and the things that Microsoft is not good, and they can make money on those by building into the cloud.

It's these channel partners that are going to benefit the most from these standardized interfaces and the mashability component that's built into these cloud services. It's not the end users who are going to be putting things together. It's the channel partners who are going to be assembling value that they can then deliver to customers.

Gardner: Tony Baer, it seems to me that the open source rollouts of the past 10 years may be harbingers of things to come into cloud.

A lot of customers have said, "Look, just handle the infrastructure for an extra fee, and we'll to continue to pay our perpetual license."

If a large vendor wants things to go slowly, they could perhaps time things. At the same time, they might offer certain elements of their services as a service for free in order to undercut competitors and/or to entice the use of a larger solution, rather than an application or feature set. Do you expect they will see that?

Baer: To a certain extent, where you will see it is in the commodity areas. Microsoft is obviously the poster child there, because they have the most to gain and the most to lose. Actually, it's more that they have the most to lose, not so much to gain. They are really in a defensive position there.

But, when you look at enterprise software or more specialized software, I don't think that's really the case. One of the notes I was jotting down here was that I thought this may actually be very particular to my market, to the software tools market, and that it may march to a different drummer, compared to customer relationship management (CRM) or Exchange.

IBM is struggling with the pricing for how it's going to price its cloud. Hewlett-Packard's (HP's) experience so far, at least from the Mercury side which has offered testing services going back a long ways, is that in many cases, the pricing is not on the subscription model. A lot of customers have said, "Look, just handle the infrastructure for an extra fee, and we'll to continue to pay our perpetual license."

The move to the cloud and subscription pricing are two different things. One does not necessarily follow the other. That's a finding that actually surprised me.

Gardner: Ron Schmelzer, Tony Baer made a point that you could be a victim of cloud, before you could be a beneficiary of it, if you are a provider and a vendor. That's a tough transition to go through.

All transitions are similar

Schmelzer: Maybe, and I think all these transitions are like that. If you look at what happened to the Web. I was on the CRM side of things back in the mid '90s, and we thought that the Web was going to kill client-server CRM applications, and, to a certain extent, it kind of did. It just took a lot longer than we thought. I remember Siebel's dominance and they're saying, "We are not going to move to the Web."

Obviously, Salesforce put the impetus behind it, but even before Salesforce was out there in the late '90s, we were asking, "Why are we using this in-house enterprise application software system with all this great Web stuff happening over there? Why can't we put this stuff online?" The same thing is going here.

We talked about this a couple of podcasts ago, this IT divide between the IT experience at work and the IT experience at home. The home IT experience is just so much richer than what we've got at work. So, it's the same question. Why are we still using these systems in the enterprise and we have all this cloud-based mash-up stuff when we go home?

The writing is on the wall. The smart vendors will learn how to transition themselves in a way that doesn't cannibalize their existing business model. The stupid ones will be pushed to the model anyways, They can't resist it, and they will, of course, suffer.

Gardner: I think this has been a very good and interesting discussion. I'd like to go around the table before we close out, because I haven't heard too much about the death of IT in these permutations of the subject that we've gone through here.

Jim Kobielus, first to you. On a scale of 1 to 10, with 1 being IT dead and 10 being

Much of the actual guts of IT within an organization will migrate to hosted environments, and much of the development will be done by end users and power users.

IT alive, robust, and growing vibrantly, where do you think we're going to see the IT department's role in say three years?

Kobielus: Okay, in three years. I'll be really wishy-washy and give it a 5. It's almost like Schrodinger's cat. You know it's in the box, but you don't know if it's dead or alive yet. It depends on how the quark falls. But, I think that in three years time, IT will be alive, kicking, robust, and migrating toward more of a pure planning, architecture, and best practices function.

Much of the actual guts of IT within an organization will migrate to hosted environments, and much of the development will be done by end users and power users. I think that's writing on the wall.

Gardner: So, the role and impact of IT will be about the same in three years?

Kobielus: Yeah.

Gardner: Tony Baer, how do you come down -- 1 to 10?

Baer: I was really confused about Jim's answer, because I thought he said at one point that IT's role is going to change as we go to hosted services.

Gardner: We may change his mind on the show.

Doing the cool stuff

Kobielus: Actually, 20 years ago I worked as a contractor for a government agency that outsourced a vast majority of their IT to contractors. I remember that the folks who remained as the government's employees running the shop were all procurement, planning, architecture, and all the high-level, cool stuff. They didn't get their fingernails dirty.

Baer: I don't subscribe to the death of IT, because I remember 20 years ago hearing about the death of IT, when Yankee Group did the announcement of that Kodak did a big outsourcing contract, because they decided that, as a company, they were not really in the business of IT. They were in business of photography. A few years later, they realized that the business of photography really did involve IT, and they very quietly backtracked on those contracts.

Gardner: JP Morgan Chase did the same thing about five or six years ago, right?

Baer: Exactly. As Sandy was saying before, there is a lot of complexity, even if you outsource. Outsource means that you need more management. Even if you use the cloud, that requires more governance.

So, I don't see IT's role diminishing. There may be a lower headcount, but that can just as much be attributed to a new technology that provides certain capabilities to end users and also using some external services. But, that's independent of whether there's a role for IT, and I think it pretty much still has a role.

Gardner: If you have 1 to 10, give me a number.

Baer: And 10 being that it does have a role?

Gardner: Vibrant, alive, thriving, and growing like crazy.

Baer: I am going to give it an 8.

Gardner: Excellent. Brad Shimmin?

Shimmin: I'm giving it a 7 for similar reasons, I think that it's going to scale back in size little bit, but it's not going to diminish in value.

IT is not going to go away. I don't think IT is going to be suffering. IT is just a continuously changing thing.

Back to what Sandy was saying, I think it's going to be very much alive, but the value is going to be more of a managerial role working with partners. Also, the role is changing to be more of business analysts, if you will, working with their end users too. Those end users are both customers and developers, in some ways, rather than these guys just running around, rebooting Exchange servers to keep the green lights blinking.

Gardner: So, more architects, fewer admins.

Shimmin: Yup.

Gardner: Ron Schmelzer?

Schmelzer: I'm going to be your lemming here. I think it's 10. IT is not going to go away. I don't think IT is going to be suffering. IT is just a continuously changing thing. Look, IT is only 60 years old. The whole life of the entire IT-as-an-organization department within the enterprise is only 60 years.

So, IT is going to be thriving in three years. It's going to be completely different than anything we may know today or maybe it'll be mostly similar. But, I guarantee that whatever it looks like, it will be still as important as an IT organization.

Now, of course, my information tells me that the world is coming to an end at three years, my Mayan Calendar. That was a good choice on time horizon, because if you had said four years, that would mean the world is not going to exist in four years. So what kind of trick question is that?

Gardner: Well, that's why I bring it down. Sandy Rogers -- 1 to 10?

Some IT is in deep trouble

Rogers: Probably in the 7 to 8 range. I agree with everything that's been said here. I think it's up to the individual enterprises. In some enterprises, IT is in deep trouble if they do not embrace new technologies and new opportunities and become an adviser to the business. So it comes down to the transition of IT in understanding all the tools and capabilities that they have at their disposal to get accomplished what they need to.

Some enterprises will be in rough shape. The biggest changeover is the vendor community. They are in the midst of changing over from being technology purveyors to solution and service purveyors. That's where the big shift is going to happen in three years.

Gardner: Alex Neihaus, how about your choice here? 1 to 10?

Neihaus: Our self-interest is in a thriving a segment of IT, because that's who we serve. So, I rate it as a 10 for all of the reasons that the much-more-distinguished-than-I panel has articulated. I wish to say one thing, though. The role of IT is always changing and impacted by the technologies around it, but I don't think that that could be used as an argument that it's going to diminish its importance or its capabilities really inside organizations.

Gardner: Well, I'll go last and I'll of course cheat, because I'm going to break it into two questions. I think their importance will be as high or higher, so 8 to 10, but their budget, the percent of spend that they're able to derive from the total revenues of the organization, will be going down. The pressure will be on, and it will be going down.

So, from a price and monetary budgeting perspective, the role of IT will probably be down around 4. That's my take.

Thanks very much for all of your input. I also want to thank the sponsors for the BriefingsDirect Analyst Insights podcast series, Active Endpoints and TIBCO Software.

And I also want to thank our guests this week. Jim Kobielus, senior analyst at Forrester Research. Thanks Jim.

Kobielus: Always a pleasure.

Gardner: Tony Baer, senior analyst at Ovum.

Baer: Great discussion as usual.

Gardner: Brad Shimmin, principal analyst at Current Analysis.

Shimmin: Thank you, Dana. It was great today.

Gardner: Ron Schmelzer? What's your name again? Brawn? No, Ron Schmelzer, senior analyst at ZapThink.

Schmelzer: Glad to be here, and I think my mainframe is taking about three years to turn off. I'll let you know in three years.

Gardner: Thank you also Sandy Rogers, now an independent IT analyst and consultant.

Rogers: It was great to participate and be here.

Gardner: And also a special thanks to Alex Neihaus, vice president of marketing at Active Endpoints.

Neihaus: It was a thrill to join you guys today.

Gardner: Thanks for listening to BriefingsDirect. Come back next time.

Download the transcript. Read the summary blog post. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.

Edited transcript of BriefingsDirect Analyst Insights Edition podcast, Vol. 42 on on the health of corporate IT and whether reports of its demise are premature. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

Cloud Pushes Enterprise Architects' Scope Beyond IT into Business Process Optimization Role

Transcript of a sponsored BriefingsDirect podcast on the role of architecture within the enterprise. Recorded live 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 welcome our listeners to a special sponsored podcast discussion, coming to you from The Open Group’s 23rd Enterprise Architecture Practitioners Conference in Toronto. This podcast, part of a series of events and live discussions here the week of July 20, 2009, centers on the fast changing role and expanding impact of enterprise architecture (EA).

The EA role is in flux, especially as we consider the heightening interest in cloud computing and in the fluid sourcing options for IT applications, data services and infrastructure, not to mention business processes that fall outside of IT entirely.

The down economy has clearly focused IT spending and analysis on priorities and doing cost-benefit types of activities, with an eager eye to seek out faster, better, and cheaper means to acquire and manage IT functions and business processes.

We've already seen a great deal of interest and activity around platform as a service (PaaS) and the application development and testing phases of an application's lifecycle. Many of us expect to see a great deal more of the application lifecycle, from design time and long-term production and integration across different aspects of processes inside and outside of the organization to become more part of a mixture of services.

These will become internal, external, and hybrid, and a lot of different sourcing innovations are yet to come. Soon many of these will skirt IT altogether.

So, as these service components shift in their origins and delivery models, the task of meeting or exceeding business requirements based on these services becomes all the more complicated. The new services era calls for powerful architects who can define, govern, and adjust all of the necessary ingredients that they must creatively support and improve upon during a lifecycle over many years.

Who or what will step into this gulf between the traditional means of IT and the new cloud ecology of services? These demands will be extended, of course, across different organizations and the requirements that they have.

The architect's role, still a work in progress at many enterprises even today, may well become the key office where the buck stops in this era. What then should be the role and therefore the new opportunity for enterprise architects?

Here to help us lead the way in understanding that complex and dynamic issue set, we're joined by Tim Westbrock, managing director of EAdirections. Welcome, Tim.

Tim Westbrock: Thank you.

Gardner: We're also joined by Sandy Kemsley, an independent IT analyst and architect herself. Welcome.

We're also joined by John Gotze, international president for the Association of Enterprise Architects. Thank you, John.

Let me go to Tim first. What are you seeing as a general set of what we would now consider architects? What are they doing?

Two different kinds

Westbrock: On average, you have two different kinds of enterprise architects. One is a very solution-oriented enterprise architect. They're ones that do try to keep the breadth of the enterprise in focus, but they are focused on individual solutions. They're focused on it holistically, meaning they're not just looking at a specific technology or a specific application.

They're bringing that holistic advantage, but they tend to be less transformational. They tend to be driven by operational goals. They tend to be driven by immediacy. That is one of the biggest reasons that we don't have a lot of reuse, because of the lack of breadth at the solution layer.

The other one is still not in the main. The more strategic enterprise architects depend on the strategic nature of the executives of the organization. If we're going to bring it into layers of abstraction, they don't go more than a layer or two down from strategy. They tend to be the ones that do develop a community of practice that has solution architects involved in it. Their takeaway from that is the EA's perspective, and they have to take that down to the solution layer. That's what I see in the main today.

Gardner: Does that mean we're primarily dealing with tactical issues?

Westbrock: In the large, enterprise architects are still more tactically oriented.

Gardner: Sandy?

Sandy Kemsley: I absolutely agree, I see that a lot. I work a lot with companies to help them implement business process management (BPM) solution, so I get involved in architecture things, because you're touching all parts of the organization then. As you say, Tim, a lot of very tactical solution architects are working on a particular project, but they're not thinking about the bigger picture.

Gardner: John, it seems that the economy has focused people's attention at looking at the bigger picture. If you stay tactical, you can control and manage costs. You can manage complexity. You can't transform very well. How, in your perception, is this down economy and these new pressures, shifting this role?

John Gotze: Actually, it's helping to change the focus in EA from the more tactical to the more strategical issues. I've seen this downturn in the economy before. It's reinforcing the changes in the discipline, and EA is becoming more and more of a strategic effort in the enterprise.

There are some who call us enterprise architects by profession, and this group at The Open Group conference is primarily people who are practitioners as enterprise architects. But, the role of EA is widening, and, by and large, I would say the chief executive is also an enterprise architect, especially with the downturn.

Gardner: We saw some indications earlier that there is potentially a growth opportunity for these architects to report to the COO perhaps, rather than the CIO, the information officer. Tim, does that present to you sort of a harbinger of what you would expect?

Less technology-only focus

Westbrock: I was a little surprised to see that, quite honestly. Maybe it's because a lot of CIOs and CTOs report up through a CFO or COO. If you looked at that wording, it was "Ultimately, where does the EA report?" But, I don't see that a lot.

Combining this with a little of the answers to the last question, one of the good transformations, or evolutionary steps that I have seen in enterprise architects is less of a technology-only focus. Enterprise architect used to be synonymous with some kind of a technology architect, a platform architect, or a network architect, and now you are seeing broader enterprise architects.

I still don't think business architecture is within the domain of most IT enterprise architects. I think the economy, maybe -- external service providers, maybe. There are some different drivers that are getting some organizations to think more holistically about how the business operates.

That leads to modeling. Modeling means we need architects. We're getting involved in some of these more transformational elements, and because of that, need to look at the business. As that evolves more, you might see more business ownership of enterprise architects. I don't see it a lot right now.

Gardner: Okay. Sandy, we talked a little bit about the economic pressures, but this is

You also have to look at the authority. Who has responsibility for keeping the lights on -- for running the systems once they are in there?

happening in tandem with some other large technology trends: a greater emphasis on services orientation, more emphasis on governance, and trying to bring in services from a variety of sources.

Looking at what should be core and internal and what might be outsourced or provisioned from a cloud environment, whether it's yours or someone else's or some combination, where does the authority shift from an IT department when we start bringing in these larger external organizations?

Kemsley: That's an interesting question. We do see a shift in terms of who has authority for making the architecture decisions. You also have to look at the authority. Who has responsibility for keeping the lights on -- for running the systems once they are in there?

In many of the companies that I work with -- and maybe this is just a Canadian perspective -- architecture, in many cases, means mostly IT architecture. There is this struggle between the IT architects and or the enterprise architects, who are really IT architects, looking at, how we need to bring things in from the cloud and how we need to make use of services outside.

But, as they speak to the IT masters, of course, they're vowing to have all of that come through IT, through the technology side. This puts a huge amount of overhead on it, both from a governance standpoint, but also from an operational standpoint. That's causing a lot of issues. If you don't get EA out of IT, you're going to have those issues as you start going outside the organization.

Gardner: So the authority, the governance, the managing, the decisions about which sourcing option should be ultimately pursued, does that just get shoehorned into IT? That doesn't sound like it's going to scale. John, where does this new office reside? Is it something that grows out of IT, or is it something that comes down from some other aspect of the organization at large?

IT won't disappear

Gotze: More the latter, I think, but the IT department will not disappear, of course. It's naive to say that IT doesn't matter, as Nicholas Carr said many years ago. It's not the point that IT is irrelevant or anything, but it's the emphasis on the strategic benefits for the enterprise.

The whole notion of business-IT alignment, as we saw in the survey here, is still the predominant emphasis and concern. I actually think that it's yesterday's concern, in the sense that business-IT alignment is really about capturing business needs and designing better IT. We've done that for 20, 30, 40 years now, and it's time to move on.

It's more about thinking about the coherent enterprise that everything should fit together. It's not just alignment. You can have perfectly well aligned systems and processes, without having a coherent enterprise. So, the focus basically must be on coherency in the enterprise.

Westbrock: I don't think that this is a new problem. If you look back to the late '80s and '90s, when there was a big boom in large outsourcing, the organizations that did well were ones that didn't make IT decisions about their outsourcers. They were ones that took what we were calling then "value chains" and said, "What are the parts of our value chain where we get a lot of value out? We need to invest internal resources more heavily." -- versus -- "What are more the commodity elements of our chain? That may be a place that we can have an outsourcer to take over."

The difference between '80s and '90s and now is that it's not a chain with seven big links. It's an intricate network with hundreds, if not thousands of pieces. Instead of there being 10 or 12 big, targeted vendors to help us, there is an infinite number of vendors. That adds complexity an element of governance that we need to mature towards.

Organizationally, we're probably okay. We're probably positioned okay to handle it. Where is

You're still going to do due diligence around who you're connecting to, but you don't have as many concerns about that as you do in the bad, old days of outsourcing.

that expertise going to come from? How are we going to capture which vendors that popped up this week are still going to be around next week? The longevity of these organizations is measured more in months than it is years.

Kemsley: That's frightening for a lot of IT groups in large organizations. All of a sudden, they have all of these new vendors to deal with. They don't really know which ones are going to be around and which ones are not going to be around, and they don't know how to create the appropriate separation between the internal and the external.

If you get some governance in place, so that you can say, "Well, I can snap out this service and snap in another one, if that vendor goes out of business," then you don't worry as much.

You're still going to do due diligence around who you're connecting to, but you don't have as many concerns about that as you do in the bad, old days of outsourcing. This is still going on, where all of a sudden the whole business process goes out to somewhere else, or a huge piece of your infrastructure goes out somewhere else.

Gardner: Let's go back to the start of our discussion. There are so many different flavors of architects now -- different descriptions, different roles, different budgeting, and authority patterns.

When those architects start interfacing with architects at other organizations, if they have very different roles, are they going to be in that position of pulling this together? Does that really call for the need of a more general definition of this new-age architect? Anyone?

Levels of experience

Westbrock: This is an issue that we've been dealing with since the term EA started being used. I don't think that's changing any time soon. Right now, that's the nature of our "profession." I use the quotes on profession because there are several, very valid efforts to standardize the profession of enterprise architect. There are several certification efforts. There are several different levels of experience. There is not a common and consistent and unified approach to doing this.

We're going to have more standardization, more commonality, but right now, what I do, what I make a living at, is helping organizations figure out how they can be effective as enterprise architects. The reason I make a good living is because company A has to do different things to be effective as enterprise architects than company B does, than company C does, than company D does.

Gardner: Well then, will it not be architects that help combine the ways in which these organizations interface at a services level, or are we going to look for someone else to do that? John?

Gotze: Absolutely. There will be a lot of innovation in the discipline. There will also be a

If you're just consuming a service, as long as that service works the way it's supposed to and is there when you need it, you don't really get the architects to talk to each other.

standardization and certification, and so on. That will not go away. I hope not. I'm also certifying architecture. But, the strategic level of architecture is one where you must have an emphasis on innovation and diversity to make it work.

Kemsley: I'm not sure I agree, because if you're looking in a cloud-services paradigm, you don't necessarily care about the architecture of the service provider. You care about the interfaces and the functionality of that service.

So, it really depends on whether you're talking about a partnership between two companies, where they are getting very much involved with each other, or whether you're really talking about consuming a service from someone. If you're just consuming a service, as long as that service works the way it's supposed to and is there when you need it, you don't really get the architects to talk to each other.

Gardner: We're getting quite a bit of additional role and responsibility thrown in, I suppose, when we think about the architect as starting to foster business transformation above and beyond the IT roles and some of the communication and collaboration issues.

But, if we talk about the more horizontal architecting of entire business processes among a variety of different service options, this is where we get caught between the organic "each company has to have its own definition for its business transformation," and then that more strategic, methodological standardized approach.

Are we going to look at this as a hybrid model, and there is no other way around it? John?

A hybrid model

Gotze: It will be some kind of hybrid model. Look at how government is working with it. They are enterprises after all -- it's not just a private sector. There's much more emphasis in government about getting all the agencies and departments to work together and to understand each other.

We just heard here from the Canadian government about the reference models and the excellent work they've done with the GSL, the strategic reference model.

That's really important. We have the same language and we understand each other across agencies. Who knows? There might be a new election tomorrow, and they'll reshape, reform, and reshuffle the agencies. So, you have to be agile also in that sense.

Westbrock: Since we're at a framework event, I'm going to relate it to frameworks a little bit. One of the steps that we need to take as a profession, from a framework standpoint, is to look at all four of the levels.

Traditionally, we have a business and information or data and an application or solutions and a

We're still decades away from any kind of maturity in the business architecture space, whether that be method, process, or organization.

technology or infrastructure layer. I think there is a lot of maturity and a lot of standardization in the technical frameworks that exist. If you look at different models, they might use different words, but they're all covering the same thing. The specific maturity that we need now is in the applications and the data spaces.

We're still decades away from any kind of maturity in the business architecture space, whether that be method, process, or organization. But, we're now at the point where more standardization in the applications or solutions and the data or information layers is going to help us with this particular challenge that's facing enterprise architects.

Gardner: Let's take a question from the audience. The questioner asked, "I'm seeing companies getting lost in the complexities that you're describing. What are the attributes of people and organizations that are more successful at managing this?"

As you say, we've been through this before. It's sort of the peeling-the-onion approach, even as the external issues and variables change. Do we have any poster children to look at and say, "Aha, that’s how you do it?" Sandy?

Handling a complex world

Kemsley: I certainly see some characteristics with companies that I work with, some that work well and some that don’t work well. I don’t know if I've got any poster children to bring forward.

The ones that can handle this new world of complexity well are ones that can bring some of the older aspects of governance, because you still have to worry about the legacy systems and all of the things that you have internally. You're not going to throw that stuff away tomorrow and bring in some completely new architecture. But, you need to start bringing in these new ideas.

It's the ones who are starting to regenerate their architect community internally -- both with business architects and with architects on the IT side -- who can bring these ideas about cloud computing, different kinds of models, things like using business process modeling notation (BPMN) that can be done by the business architects and even business people, as opposed to having all of that type of work done in the IT area.

Gardner: John, any radical instances of success?

Gotze: I see some in the European context, because that’s the one I know the best. By and large, I agree with Sandy. It’s really how pervasive and embedded the architecture work is in the organization. The more you have enterprise architects and other architects living in ivory towers, the less success you have.

Some in the financial sector in Europe are doing quite well, even though the financial sector is

. . . we get a lot of energy, instantiate the processes, put the governance in place, build the models, do the transformations, and then we fall back on old habits.

not doing well as such. But, the survival strategies brought froward by the strategists and the architects are actually very valuable to the companies.

Westbrock: People are looking for names, right? Prudential has done a really good job. National City Bank did a tremendous job right around the turn of the century. They were engaged in a very, wide-reaching transformational effort called The Bank of the 21st Century. They actually endorsed at a shareholder's meeting the role that EA would play in enabling the transformation to the banks of the 21st Century -- DuPont, Bank of America.

Here’s the funny thing, though. I've seen a lot of organizations that have reached a tremendous level of maturity and effectiveness with EA, due to a large SAP implementation or a strategic initiative like the transformation to The Bank of the 21st Century, but it doesn’t sustain. I can’t point to somebody who, on a consistent basis over 20 years, has done this well.

What happens is that we get a lot of energy, instantiate the processes, put the governance in place, build the models, do the transformations, and then we fall back on old habits. We don’t update the documentation. We forget the strategic imperatives. We get back down into the nitty-gritty. We're fixing bugs, and we lose sight of the big picture again.

Gardner: John, you wanted to add something?

Gotze: Just by way of example, I'd mention the Swiss-based Syngenta, which is in the field of producing seeds and stuff. So, for every tomato, or every fifth tomato, that you eat, they've made the seeds.

EA supporting science

It's an atypical business to be in for EA, but they're doing extraordinarily good work. There’s a lot of science in this, and how do you support science and research through architecture? They actually managed to do that by having very well functioning communities internally and a special way to get people to get the title of architect. They have about 2,000 architects, but not by title.

Gardner: From your responses, it sounds as if these are more the exception than the rule, and that even when they are the rule they can be fleeting.

Westbrock: I think this goes back to the expectations that the organization has of EA. I don’t think that the expectations for most enterprise architects are to enable business transformation. In most organizations that I deal with it’s to help with better solutions here and there. It’s to do some technology research and mash it up against business capabilities. It’s not this grand vision that I think most of us have as enterprise architects in the profession of what we can accomplish.

Kemsley: That’s right. They're there to bless the designs of a solution, but not to really do the big architectural picture.

Gardner: Here’s another question from our audience that addresses that. As we get towards that goal of business transformation, don’t you think that executives, as they become more aware that these opportunities exist, will want to then move in and take their role within that larger role. The technologists who come up as architects might get overtaken or usurped by more general business leadership or politics? Sandy?

Kemsley: I don’t see the business leadership clamoring to take over architecture anytime soon.

I think the executive leadership will want to take over the work that the strategic EA is doing. They might not call it EA, but they will be the ultimate architect.

In large part, it’s seen as being mostly an IT role. They just see it as part of IT. When you look at those survey results, it said that 60-70 percent of the architecture groups reported through to the CIO or the CTO. That’s how people think about it. It’s a piece of the IT department. So, you're not going to get the CEO coming in and saying on day one, "Oh, I want to takeover that architecture stuff."

Gotze: I agree, but that’s also because we in the profession have managed to create a vocabulary that's nearly impossible-to-understand for people outside the profession.

I think the executive leadership will want to take over the work that the strategic EA is doing. They might not call it EA, but they will be the ultimate architect. The CEO is the ultimate chief architect for a forward-looking and an innovative enterprise.

Westbrock: I thought that question was going someplace else completely. I thought that question was going to say, "Once they realize what enterprise architects can do, are they going to be interested in taking advantage of it?" When I mentioned some of those examples of companies that have done this well, that’s what has happened. There’s been real relationship that exists between the EA teams -- it's not a person -- and the board.

The board members know the EA team at these organizations, because there is a relationship of partnering there. It didn’t start out that way. It started out with the EA team becoming aware of the vision, and they did that in interactions, but it was a one-way. It was, "What can we take from you, Board of Directors?

Two-way conversation

But, as they evolved their sets of artifacts and positioned those sets of artifacts to be communicable to executives rather than developers, they were able to communicate the strategic nature of what they're doing as enterprise architects. Then it became a two-way conversation.

Gardner: Well, whoever fills this role and from wherever they come within the organization, it’s going to be an extremely powerful role, if we follow through with what we've seen with globalization, outsourcing, business process issues, outsourcing an entire department, perhaps to an overseas organization.

What’s left of the enterprise but the architecture, the rules, the governance, the policies, if there are in fact all sorts of other organizations supporting the underlying services? So, doesn’t this role become something that should be board level role?

Kemsley: It should. We have to learn to use EA power for good, rather than evil, though. In a lot of cases, it’s just about implementation. It’s sort of downward looking. Enterprise architects tend to look down into the layers rather than, as Tim was saying, feed it back up to the layers above that.

How EA is perceived within the enterprise and how it presents itself needs a total makeover. It’s

When we talk to folks about the kinds of capabilities, skills, and credentials that they're looking for in enterprise architects, deep technical ability is nowhere on the list.

just so that people, especially the executives at the high level, the board members, and so on, can see the value and what this brings to them.

Gardner: Well, saying they need a makeover is another way of saying there is a tremendous opportunity for an innovative promoter, to get involved and to pull some of these threads together, because there is a gulf or a vacuum.

Westbrock: When we talk to folks about the kinds of capabilities, skills, and credentials that they're looking for in enterprise architects, deep technical ability is nowhere on the list. It's not because that deep technical ability is not useful. It's because generally people that are performing those deep technical task lack the breadth of experience that make enterprise architects good.

They have that deep technical knowledge, because they've done that a long time. They've become experts in that silo. That's very, very much needed, which is why EA is a collaborative forum. The folks that are going to be called to function as enterprise architects are folks that need a much broader set of skills and experience.

Gotze: I agree. The deep technical skills will come way down the list. Communication is very high on the list -- understanding, contracting, and so on, because we have the cloud and similar stuff also very high on the list.

Career promotion path

Kemsley: But, it's being used as a career promotion path for people who start out in technology. It used to be, if you were like a programmer and you got to a certain level, it was like, "Well, we'll promote you. We'll make you project manager." Somebody who has no ability, no skills, and no experience to do that was given that as a title, because that was in the career path.

That's happening to some degree with architecture as well. You get to a certain level as a very deep technical person within an organization, and one of your career options is, "Well, you can move into architecture." It doesn't mean that somebody has the skills or even the inclination to do that, but that's the only way they can move up the chain.

Gotze: Then, if they're not competent, they move into management.

Gardner: Here's another question from the audience that says, "There are quite a number of anti-architecture forces in play, for perhaps a variety of reasons. Are they going to run out of gas?" Is there so much complexity with the economy, with source options, with this shift towards business transformation and efficiency of processes, when the organization does architecture well and receives the rewards and bears the fruit of that do the anti-architecture forces finally collapse? Any prophecies?

Kemsley: Well, they will, but it's dependent on that statement you said, "When architecture is done well." In many organizations, architecture is not done all that well. It's done on an ad hoc basis. It's done at more of the deep technical level. I can understand why the anti-architecture people get frustrated with that type of architecture, because it's not really EA.

Gardner: We see the need. We have the vision. They have the technical understanding of what

The folks that have been successful are the ones that take the time to do two things. They build artifacts and processes that work down, they build artifacts and processes that work up, and they realize that they're different.

IT is capable of. Are we talking about a lack of power and budget? What needs to happen?

Westbrock: Quite honestly, it's our own fault. It's the way we talk about EA in the main. We don't talk about EA as a strategic enabler or as a translation of strategy into activities. We say alignment, but what does that mean?

The folks that have been successful are the ones that take the time to do two things. They build artifacts and processes that work down, they build artifacts and processes that work up, and they realize that they're different. You don't build an artifact for a developer and take that to a member of the board. You don't build project design review processes and then say, "Okay, we're going to apply that same process at the portfolio level or at the department level."

We don't have communication strategies that are going to facilitate the broadcast of results to the people that use the standards, and then use the same strategy and modes of communication for attaining strategic understanding of business drivers. It's really been a separation, knowing that there's a whole different set of languages and models and artifacts that we need here and a whole different set here.

Gardner: Here is another very interesting question from our audience. Is it too pessimistic to expect that cloud vendors will offer architecture as a service? In the past, we've seen that when there is a vacuum in a business, a consulting or outside opportunity for filling that comes in. Should we expect architecture to go in the same direction?

Not effective as a service

Kemsley: I'm not sure that's something you can really do effectively as a service. It's one thing to talk about a consulting service that helps you with architecture, offering it as a service in the way that a cloud vendor offers a service, I'm not sure that fits.

Gardner: First is the problem with the acronym.

Kemsley: That's true.

Gardner: John, you can't outsource it?

Gotze: I would never outsource my architecture. When I helped the Danish government in launching the national EA program, the top mantra was "Take home your architecture," the responsibility for the architecture. If Google, MSN, or whichever cloud vendors come out now and say, "Well, you don't have to bother with this architecture tricky stuff. Let us take care of it," we're back to a model from the '70s and the '80s, where we outsource everything and give the power to the vendor.

I strongly believe in architecture as a service, but that's an internal service, rather than ivory tower architecture or whatever. It's a service offered in the enterprise whenever it's needed.

Gardner: Tim, an alternative view?

Westbrock: I don't disagree with our esteemed colleagues here, but the question was whether

It's been proven time and again that it's not a great idea, but absolutely, there will continue to be architecture-as-a-service offerings.

we should expect it to be offered, and I think it already is.

Gardner: How so?

Westbrock: It always has been. I used to work for a Big Six. I won't mention them by name, but I was, at one time, called an Android. It's not uncommon to find the architecture from the consulting group, from the vendor, a three-inch binder sitting on somebody's shelf. That was an attempt for an external service provider to do architecture for you. It's been proven time and again that it's not a great idea, but absolutely, there will continue to be architecture-as-a-service offerings.

Gardner: Do you want to respond to that -- perhaps not a service from the cloud, but a professional service capability?

Kemsley: Certainly, that will be done as a professional service. I don't know if that's the best way to do it. If you're really doing EA at the levels that it should be done, it's corporate strategy, and you don't outsource your corporate strategy.

Gotze: But, you can buy consultants that can help you in that. So, of course yes, it will be a service in the market.

Looking to the future

Gardner: Why don't we begin to wind down a little bit and take an opportunity to look to the future? I'm primarily interested in this opportunity that we're seeing with cloud. There's a tremendous amount of interest.

The business side of the house is wondering if this is going to cause them to be able to cut budgets, reduce the total cost as a percentage that they devote to IT, and, at the same time, give them what's generally referred to as better agility.

Sandy, this cloud thing, what's the impact, from your perspective, on the role and position of the enterprise architect?

Kemsley: There are a lot of different ways you can implement the cloud. The role of the enterprise architect is to look at how it comes in. One is to do something that totally bypasses IT. Salesforce.com is sort of ideal, where the business goes out and works directly with a cloud provider to give them a service that use to be provided by IT.

EA is certainly in a position to say, "Well, this is the best way to handle this sort of thing, to

EA is certainly in a position to say, "Well, this is the best way to handle this sort of thing, to outsource this particular functionality."

outsource this particular functionality."

The second choice is, when you're looking at orchestrating business processes of various sorts, you need to call services. So, you've got a service-oriented architecture (SOA) together with some BPM. You want to look at calling services from the cloud. Then, it's almost like you're calling out to Google Maps, or you're calling to a variety of other services that might provide a discrete function within a piece of functionality there. That's pretty common and is going on. It doesn't even need to be addressed necessarily at an architectural level, but certainly the one where the business goes out.

What does happen, though, in many cases is that, this will still be done. It might start out as, "Let's look at doing things in the cloud and reducing our cost and so on." It ends up being a big IT outsourcing operation.

IT is still there and all they're doing is taking some big severs and moving them from one building to another building. It doesn't provide the kind of benefits that can be there. Again, that's something that's probably below, or could be below, the radar of what the architects are doing, except for network architects or solution architects, who are concerned with how all this gets wired together.

Gardner: John, impact of the cloud?

Incoherency and chaos

Gotze: There will be a huge impact, of course, and hopefully more than we see already. But, it has to be in the hands of someone, and that's a real tricky one. If it's just that line-of-business units go out and one contracts Salesforce and another contracts "whatever force," then we'll have incoherency and chaos.

My best bet or suggestion is to control the contracting and have the architects do the filtering on contracts. Of course, with free services, you cannot avoid people just choosing all of these services, but as long as it's something that cost money, you can control the budget. That's one way to sit on the decisions, but allow for innovation.

So, apart from the contracting, try to get the principles of the architecture as embedded as possible in the organization, so that people really understand that it's bloody stupid, if you are in government, to put personal, private data out in the cloud, if it's an insecure cloud. So, yeah, it's a challenge.

Gardner: Something to keep us busy for a while.

Gotze: Yeah.

Gardner: Tim?

Westbrock: There is a huge opportunity for enterprise architects relative to not just the cloud.

The cloud is just one more of the enablers of service orientation, not SOA, service orientation. Somebody needs to own the services portfolio.

The cloud is just one more of the enablers of service orientation, not SOA, service orientation. Somebody needs to own the services portfolio. Maybe we're going to call them the "Chief Services Architect." I don't know. But, what I see in so many organizations is service oriented infrastructure being controlled by one group, doing a good job of putting in place the kinds of foundational elements that we need to be able to do service orientation.

Then, we see application development teams and groups figuring out which frameworks to use, where are we going to put the library, and they're building services and they're integrating services. What's missing is somebody with this portfolio, meaning holistic, enterprise-wide view of what services we need, what services we have, where we can go get other services -- basically the services portfolio. Enterprise architects are uniquely positioned to do that justice.

Gardner: Well, great. I want to thank our panelist for their tremendous and insightful input. We've been joined by Tim Westbrock, managing director of EAdirections. Thank you.

Westbrock: Thank you, Dana.

Gardner: Sandy Kemsley, independent IT analyst and architect. Thank you so much.

Kemsley: Thank you.

Gardner: And John Gotze, the international president of the Association for Enterprise Architects.

I also want to thank the audience for some really great questions.

I'm Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to a BriefingsDirect special presentation from The Open Group's 23rd Enterprise Architecture Practitioners Conference in Toronto. 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 of architecture within the enterprise. Recorded live at The Open Group's 23rd Enterprise Architecture Practitioners Conference in Toronto. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.