SOA Provides Needed Support for Enterprise Architecture in Cloud, Mobile, Big Data, Says Open Group Panel

Transcript of a BriefingsDirect panel discussion on how SOA principles are becoming cheaper and easier to implement as enterprises move to the cloud.

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

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

Today, we present a sponsored podcast discussion on the resurgent role of service-oriented architecture (SOA) and how its benefits are being revisited as practical and relevant in the cloud, mobile, and big-data era.

We've gathered an international panel of experts to explore the concept of "architecture is destiny," especially when it comes to hybrid services delivery and management. We'll see how SOA is proving instrumental in allowing the needed advancements over highly distributed services and data, when it comes to scale, heterogeneity support, and governance.

Here to share his insights on the back-to-the-future role and practicality of SOA is Chris Harding, Director of Interoperability at The Open Group. He's based in the UK. Welcome, Chris. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

Chris Harding: Hi, Dana. It's great to be on this panel.

Gardner: We're also here with Nikhil Kumar, President of Applied Technology Solutions and Co-Chair of the SOA Reference Architecture Projects within The Open Group, and he is based in Michigan.

Nikhil Kumar: Hello, Dana. I'm looking forward to being on the panel and participating.

Gardner: We're also here with Mats Gejnevall, Enterprise Architect at Capgemini and Co-Chair of The Open Group SOA Work Group, and he's based in Sweden. Thanks for joining us, Mats.

Mats Gejnevall: Thanks, Dana.

Gardner: All right, Chris, tell me little bit about this resurgence that we've all been noticing in the interest around SOA.

Harding: My observation is from a slightly indirect perspective. My role in The Open Group is to support the work of our members on SOA, cloud computing, and other topics. We formed the SOA Work Group back in 2005, when SOA was a real emerging hot topic, and we set up a number of activities and projects. They're all completed.

I was thinking that the SOA Work Group would wind down, move into maintenance mode, and meet once every few months or so, but we still get a fair attendance at our regular web meetings. In fact, we've started two new projects and we're about to start a third one. So from that, as I said, indirect observation, it's very clear that there is still an interest, and indeed a renewed interest, in SOA from the IT community within The Open Group.

Larger trends

Gardner: Nikhil, do you believe that this has to do with some of the larger trends we're seeing in the field, like cloud Software as a Service (SaaS), and hybrid services? From your perspective, is this what's driving this renewal?

Kumar: What I see driving it is three things. One is the advent of the cloud and mobile, which requires a lot of cross-platform delivery of consistent services. The second is emerging technologies, mobile, big data, and the need to be able to look at data across multiple contexts.


The third thing that’s driving it is legacy modernization. A lot of organizations are now a lot more comfortable with SOA concepts. I see it in a number of our customers. I've just been running a large enterprise architecture initiative in a Fortune 500 customer.

At each stage, and at almost every point in that, they're now comfortable. They feel that SOA can provide the ability to rationalize multiple platforms. They're restructuring organizational structures, delivery organizations, as well as targeting their goals around a service-based platform capability.

So legacy modernization is a back-to-the-future kind of thing that has come back and is getting adoption. The way it's being implemented is using RESTful services, as well as SOAP services, which is different from traditional SOA, say from the last version, which was mostly SOAP-driven.

Gardner: Mats, do you think that what's happened is that the marketplace and the requirements have changed and that’s made SOA more relevant? Or has SOA changed to better fit the market? Or perhaps some combination?

Gejnevall: I think that the cloud is really a service delivery platform. Companies discover that to be able to use the cloud services, the SaaS things, they need to look at SOA as their internal development way of doing things as well. They understand they need to do the architecture internally, and if they're going to use lots of external cloud services, you might as well use SOA to do that.

Also, if you look at the cloud suppliers, they also need to do their architecture in some way and SOA probably is a good vehicle for them. They can use that paradigm and also deliver what the customer wants in a well-designed SOA environment.

Gardner: Let's drill down on the requirements around the cloud and some of the key components of SOA. We're certainly seeing, as you mentioned, the need for cross support for legacy, cloud types of services, and using a variety of protocol, transports, and integration types. We already heard about REST for lightweight approaches and, of course, there will still be the need for object brokering and some of the more traditional enterprise integration approaches.

This really does sound like the job for an Enterprise Service Bus (ESB). So let's go around the panel and look at this notion of an ESB. Some people, a few years back, didn’t think it was necessary or a requirement for SOA, but it certainly sounds like it's the right type of functionality for the job. Do you agree with that, Chris?

Loosely coupled

Harding: I believe so, but maybe we ought to consider that in the cloud context, you're not just talking about within a single enterprise. You're talking about a much more loosely coupled, distributed environment, and the ESB concept needs to take account of that in the cloud context.

Gardner: Nikhil, any thoughts about how to manage this integration requirement around the modern SOA environment and whether ESBs are more or less relevant as a result?

Kumar: In the context of a cloud we really see SOA and the concept of service contracts coming to the fore. In that scenario, ESBs play a role as a broker within the enterprise. When we talk about the interaction across cloud-service providers and cloud consumers, what we're seeing is that the service provider has his own concept of an ESB within its own internal context.

If you want your cloud services to be really reusable, the concept of the ESB then becomes more for the routing and the mediation of those services, once they're provided to the consumer. There's a kind of separation of concerns between the concept of a traditional ESB and a cloud ESB, if you want to call it that.

The cloud context involves more of the need to be able to support, enforce, and apply governance concepts and audit concepts, the capabilities to ensure that the interaction meets quality of service guarantees. That's a little different from the concept that drove traditional ESBs.

That’s why you're seeing API management platforms like Layer 7, Mashery, or Apigee and other kind of product lines. They're also coming into the picture, driven by the need to be able to support the way cloud providers are provisioning their services. As Chris put it, you're looking beyond the enterprise. Who owns it? That’s where the role of the ESB is different from the traditional concept.

Gardner: Do you think there is a security angle to that as well or at least access and privilege types of controls?

Kumar: Absolutely. Most cloud platforms have cost factors associated with locality. If you have truly global enterprises and services, you need to factor in the ability to deal with safe harbor issues and you need to factor in variations and law in terms of security governance.

The platforms that are evolving are starting to provide this out of the box. The service consumer or a service provider needs to be able to support those. That's going to become the role of their ESB in the future, to be able to consume a service, to be able to assert this quality-of-service guarantee, and manage constraints or data-in-flight and data-at-rest.

Gardner: Mats, it sounds as if the ESB, as Nikhil is describing it, would be more of an intermediary between the internal organization and external services. Does that jibe with what you're seeing in the market, or are there other aspects of the concept of ESB that are now relevant to the cloud?

Entire stack

Gejnevall: One of the reasons SOA didn’t really take off in many organizations three, four, or five years ago was the need to buy the entire stack of SOA products that all the consultancies were asking companies to buy, wanting them to buy an ESB, governance tools, business process management tools, and a lot of sort of quite large investments to just get your foot into the door of doing SOA.

These days you can buy that kind of stuff. You can buy the entire stack in the cloud and start playing with it. I did some searches on it today and I found a company that you can play with the entire stack, including business tools and everything like that, for zero dollars. Then you can grow and use more and more of it in your business, but you can start to see if this is something for you.

In the past, the suppliers or the consultants told you that you could do it. You couldn’t really try it out yourself. You needed both the software and the hardware in place. The money to get started is much lower today. That's another reason people might be thinking about it these days.

Gardner: It sounds as if there's a new type of on-ramp to SOA values, and the componentry that supports SOA is still being delivered as a service. On top of that, you're also able to consume it in a pay-as-you-go manner. Do you agree, Chris Harding, that there's a new type of on-ramp to SOA now that might be part of this resurgence?

Harding: That's a very good point, but there are two contradictory trends we are seeing here. One is the kind of trend that Mats is describing, where the technology you need to handle a complex stack is becoming readily available in the cloud.

One of the reasons SOA didn’t really take off in many organizations three, four, or five years ago was the need to buy the entire stack of SOA products

And the other is the trend that Nikhil mentioned: to go for a simpler style, which a lot of people term REST, for accessing services. It will be interesting to see how those two tendencies play out against each other.

Kumar: I'd like to make a comment on that. The approach for the on-ramp is really one of the key differentiators of the cloud, because you have the agility and the lack of capital investment (CAPEX) required to test things out.

But as we are evolving with cloud platforms, I'm also seeing with a lot of Platform-as-a-Service (PaaS) vendor scenarios that they're trying the ESB in the stack itself. They're providing it in their cloud fabric. A couple of large players have already done that.

Gardner: I guess we could rethink that as Integration as a Service. Does that make sense?

Kumar: Yes. For example, Azure provides that in the forward-looking vision. I am sure IBM and Oracle have already started down that path. A lot of the players are going to provide it as a core capability.

Pre-integrated environment

Gejnevall: Another interesting thing is that they could get a whole environment that's pre-integrated. Usually, when you buy these things from a vendor, a lot of times they don't fit together that well. Now, there’s an effort to make them work together.

But some people put these open-source tools together. Some people have done that and put them out on the cloud, which gives them a pretty cheap platform for themselves. Then, they can sell it at a reasonable price, because of the integration of all these things.

Gardner: There seem to be a couple of different approaches in the market. One would be the à-la-carte approach, perhaps most popularized by Amazon Web Services (AWS), where you can just get discrete Infrastructure-as-a-Service (IaaS) componentry or granular approaches.

There's also the move toward a fuller stack of integrated services that would work in total, perhaps even across a lifecycle of software, from development, to deployment, to advancement, into integration and process.

Any thoughts from the panel on these two approaches? Will there be more à la carte or more integration? I guess it depends on the organization how they want to consume this. Chris?

Harding: There are two different approaches for the architect to choose between. You can go for the basic IaaS from Amazon. You can put stack onto it. Maybe you can get open-source products and put them onto that stack. That will give you the kind of platform on which you're going to deploy your services.

You need to make sure that the stuff that you're using out there are things that you can actually bring home and use at home as well.

Or you can go for PaaS with a platform ready there and integrate it. If you go for the PaaS already there and integrate it, then you should watch out for how far you're locked into that particular cloud provider, because you're using special services in that platform.

Gejnevall: It's an important issue there, because what happens if you buy the whole stack in the cloud somewhere? It's done by very specific tools that you can't move into your own environment later on, and that cloud supplier goes under, and suddenly you're in a pretty bad shape. You need to make sure that the stuff that you're using out there are things that you can actually bring home and use at home as well.

Gardner: Nikhil, it sounds as if the cloud model might be evolving toward what is all-inclusive, at least a lot of people would like to provide that. But SOA, I think by its nature and its definition, advances an ocean of interoperability, and being able to plug and play across existing, current, and then future sets of service possibilities. Are we talking about SOA being an important element of keeping clouds dynamic and flexible?

Kumar: We can think about the OSI 7 Layer Model. We're evolving in terms of complexity, right? So from an interoperability perspective, we may talk SOAP or REST, for example, but the interaction with AWS, Salesforce, SmartCloud, or Azure would involve using APIs that each of these platforms provide for interaction.

Lock-in

So you could have an AMI, which is an image on the Amazon Web Services environment, for example, and that could support a lab stack or an open source stack. How you interact with it, how you monitor it, how you cluster it, all of those aspects now start factoring in specific APIs, and so that's the lock-in.

From an architect’s perspective, I look at it as we need to support proper separation of concerns, and that's part of [The Open Group] SOA Reference Architecture. That's what we tried to do, to be able to support implementation architectures that support that separation of concerns.

There's another factor that we need to understand from the context of the cloud, especially for mid-to-large sized organizations, and that is that the cloud service providers, especially the large ones -- Amazon, Microsoft, IBM -- encapsulate infrastructure.

If you were to go to Amazon, Microsoft, or IBM and use their IaaS networking capabilities, you'd have one of the largest WAN networks in the world, and you wouldn’t have to pay a dime to establish that infrastructure. Not in terms of the cost of the infrastructure, not in terms of the capabilities required, nothing. So that's an advantage that the cloud is bringing, which I think is going to be very compelling.

The other thing is that, from an SOA context, you're now able to look at it and say, "Well, I'm dealing with the cloud, and what all these providers are doing is make it seamless, whether you're dealing with the cloud or on-premise." That's an important concept.

From an SOA perspective, the cloud has become very compelling.

Now, each of these providers and different aspects of their stacks are at significantly different levels of maturity. Many of these providers may find that their stacks do not interoperate with themselves either, within their own stacks, just because they're using different run times, different implementations, etc. That's another factor to take in.

From an SOA perspective, the cloud has become very compelling, because I'm dealing, let's say, with a Salesforce.com and I want to use that same service within the enterprise, let's say, an insurance capability for Microsoft Dynamics or for SugarCRM. If that capability is exposed to one source of truth in the enterprise, you've now reduced the complexity and have the ability to adopt different cloud platforms.

What we are going to start seeing is that the cloud is going to shift from being just one à-la-carte solution for everybody. It's going to become something similar to what we used to deal with in the enterprise context. You had multiple applications, which you service-enabled to reduce complexity and provide one service-based capability, instead of an application-centered approach.

You're now going to move the context to the cloud, to your multiple cloud solutions, and maybe many implementations in a nontrivial environment for the same business capability, but they are now exposed to services in the enterprise SOA. You could have Salesforce. You could have Amazon. You could have an IBM implementation. And you could pick and choose the source of truth and share it.

So a lot of the core SOA concepts will still apply and are still applying.

Gardner: Mats, it sounds that with this vision of a cloud of clouds and increasingly services being how you manage that diversity, getting competency at SOA now will put you in a much better position to be able to exploit and leverage these cloud services as we go forward. Does that make sense?

Governance issue

Gejnevall: Absolutely, but the governance issue pops up here all the time as well, because if you are going to use lots of services out there, you want to have some kind of control. You might want to have a control over your cloud suppliers. You don't want to start up a lot of shadow IT all over your enterprise. You still want to have some kind of control.

An idea that is popping up now is that, instead of giving the business direct access to all these cloud suppliers, you probably have to govern those services and look at governance features. You can measure the usage of all these external SaaS things, and then if you don't like the supplier and you can't negotiate the right price, you just move to another supplier that supplies a similar type of service.

This works fine in SOA and SaaS context, but it's much harder to do that from a PaaS or IaaS. From the SaaS point of view, you really need to get control over those services, because otherwise the business is going to go wild. Then, you buy new stuff all over the place, and suddenly they die out and then the business stops working, and there is no control over that.

Gardner: Chris Harding, another pillar of SOA traditionally has been the use of registry and repositories to help manage some of that chaos that Mats was referring to. We've also seen a lot of interest in the concept of the app store, popularized by Apple with its iOS interfaces and its application buying and managing. Are we seeing a need for app stores in the enterprise that are, in a sense, the registry and repository of SOA?

Harding: The app store concept is coming in, in several forms and it seems to be meeting a number of different needs.

From the SaaS point of view, you really need to get control over those services, because otherwise the business is going to go wild.

Yes, you have the app stores that cloud vendors have to let people pick from their product. You have the government app stores organized to enable government departments to get a good choice of cloud services. In some ways, they're taking over from the idea of the registry and the repository, or doing some of the functions.

In particular, the idea that you used to have of service discovery, of automatically going out and discovering services, is being replaced by the concept of selecting services from app stores. But, of course, there is a fundamental difference between the app store, which is something that you get your service from, and the registry that you keep, which is the registry of the services that you have got from wherever.

Gardner: It does seem important for the governance.

Gejnevall: I also think that the concept of the app stores has taught a lot of business people to use this kind of thinking. I have this huge list of things that I can do within my business. Now with the smartphones, they used to go and search for that and see what kind of stuff can I do with the IP I've got in my business. By providing similar kinds of things to the business people, they can go and search and see that these are other things I can do within my business. You can download them on your laptop, your phone, or whatnot.

That will change the relationship a bit between the business side and the IT side of things.

Another on-ramp

Gardner: Perhaps yet another on-ramp to the use of SOA types of models and thinking, the app store allowing for discovery, socialization of services, but at the same time, providing governance and control, because the organization can decide what app store you use, what apps get in the store, or what app stores are available.

Kumar: I have a few comments on that, because we're seeing that with a lot of our customers, typically the vendors who support PaaS solution associate app store models along with their platform as a mechanism to gain market share.

The issue that you run into with that is, it's okay if it's on your cellphone or on your iPad, your tablet PC, or whatever, but once you start having managed apps, for example Salesforce, or if you have applications which are being deployed on an Azure or on a SmartCloud context, you have high risk scenario. You don't know how well architected that application is. It's just like going and buying an enterprise application.

When you deploy it in the cloud, you really need to understand the cloud PaaS platform for that particular platform to understand the implications in terms of dependencies and cross-dependencies across apps that you have installed. They have real practical implications in terms of maintainability and performance. We've seen that with at least two platforms in the last six months.

Governance becomes extremely important. Because of the low CAPEX implications to the business, the business is very comfortable with going and buying these applications and saying, "We can install X, Y, or Z and it will cost us two months and a few million dollars and we are all set." Or maybe it's a few hundred thousand dollars.

When you deploy it in the cloud, you really need to understand the cloud PaaS platform for that particular platform.

They don't realize the implications in terms of interoperability, performance, and standard architectural quality attributes that can occur. There is a governance aspect from the context of the cloud provisioning of these applications.

There is another aspect to it, which is governance in terms of the run-time, more classic SOA governance, to measure, assert, and to view the cost of these applications in terms of performance to your infrastructural resources, to your security constraints. Also, are there scenarios where the application itself has a dependency on a daisy chain, multiple external applications, to trace the data?

In terms of the context of app stores, they're almost like SaaS with a particular platform in mind. They provide the buyer with certain commitments from the platform manager or the platform provider, such as security. When you buy an app from Apple, there is at least a reputational expectation of security from the vendor.

What you do not always know is if that security is really being provided. There's a risk there for organizations who are exposing mission-critical data to that.

The second thing is there is still very much a place for the classic SOA registries and repositories in the cloud. Only the place is for a different purpose. Those registries and repositories are used either by service providers or by consumers to maintain the list of services they're using internally.

Different paradigms

There are two different paradigms. The app store is a place where I can go and I know that the gas I am going to get is 85 percent ethanol, versus I also have to maintain some basic set of goods at home to make that I have my dinner on time. These are different kind of roles and different kind of purposes they're serving.

Above all, I think the thing that's going to become more and more important in the context of the cloud is that the functionality will be provided by the cloud platform or the app you buy, but the governance will be a major IT responsibility, right from the time of picking the app, to the time of delivering it, to the time of monitoring it.

Gardner: It's a very interesting topic. Chris Harding, tell me a little bit about how The Open Group is allowing architects to better exercise SOA principles, as they're grappling with some of these issues around governance, hybrid services delivery and management, and the use and demand in their organizations to start consuming more cloud services?

Harding: The architect’s primary concern, of course, has to be to meet the needs of the client and to do so in a way that is most effective and that is cost-effective. Cloud gives the architect a usability to go out and get different components much more easily than hitherto.

There is a problem, of course, with integrating them and putting them together. SOA can provide part of the solution to that problem, in that it gives a principle of loosely coupled services. If you didn’t have that when you were trying to integrate different functionality from different places, you would be in a real mess.

The Open Group’s real role is to support the architect and help the architect to better meet the needs of the architect client.

What The Open Group contributes is a set of artifacts that enable the architect to think through how to meet the client’s needs in the best way when working with SOA and cloud.

For example, the SOA Reference Architecture helps the architect understand what components might be brought into the solution. We have the SOA TOGAF Practical Guide, which helps the architect understand how to use TOGAF in the SOA context.

We're working further on artifacts in the cloud space, the Cloud Computing Reference Architecture, a notational language for enabling people to describe cloud ecosystems on recommendations for cloud interoperability and portability. We're also working on recommendations for cloud governance to complement the recommendations for SOA governance, the SOA Governance Framework Standards that we have already produced, and a number of other artifacts.

The Open Group’s real role is to support the architect and help the architect to better meet the needs of the architect client.

Gardner: Very good. And perhaps just quickly Chris, you could fill us in as a recap of some of the SOA activities at your recent Washington D.C. Conference.

New SOA activities

Harding: We're looking at some new SOA activities. In fact, we've started an activity to look at SOA for business technology. From the very early days, SOA was seen as bringing a closer connection between the business and technology. A lot of those promises that were made about SOA seven or eight years ago are only now becoming possible to fulfill, and that business front is what that project is looking at.

We're also producing an update to the SOA Reference Architectures. We have input the SOA Reference Architecture for consideration by the ISO Group that is looking at an International Standard Reference Architecture for SOA and also to the IEEE Group that is looking at an IEEE Standard Reference Architecture.

We hope that both of those groups will want to work along the principles of our SOA Reference Architecture and we intend to produce a new version that incorporates the kind of ideas that they want to bring into the picture.

We're also thinking of setting up an SOA project to look specifically at assistance to architects building SOA into enterprise solutions.

So those are three new initiatives that should result in new Open Group standards and guides to complement, as I have described already, the SOA Reference Architecture, the SOA Governance Framework, the Practical Guides to using TOGAF for SOA.

We're also thinking of setting up an SOA project to look specifically at assistance to architects building SOA into enterprise solutions.

We also have the Service Integration Maturity Model that we need to assess the SOA maturity. We have a standard on service orientation applied to cloud infrastructure, and we have a formal SOA Ontology.

Those are the things The Open Group has in place at present to assist the architect, and we are and will be working on three new things: version 2 of the Reference Architecture for SOA, SOA for business technology, and I believe shortly we'll start on assistance to architects in developing SOA solutions.

Gardner: Very good. I'm afraid we'll have to leave it there. We're about out of time. We've been talking about how SOA is proving instrumental in allowing the needed advancements over highly distributed services and data, especially when it comes to the scale, heterogeneity support, and governance requirements of cloud computing.

Please join me now in thanking our panel. Chris Harding, Director of Interoperability for The Open Group. Thanks so much, Chris.

Harding: Thank you very much, Dana.

Gardner: We're also here with Nikhil Kumar, President of Applied Technology Solutions and Co-Chair of the SOA Reference Architecture Project within The Open Group. Thank you so much.

Kumar: Thank you, Dana.

Gardner: And Mats Gejnevall, Enterprise Architect at Capgemini and Co-Chair of The Open Group SOA Work Group. Thanks, Mats.

Gejnevall: Thanks, Dana. It was an interesting discussion.

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

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

Transcript of a BriefingsDirect panel discussion on how SOA principles are becoming cheaper and easier to implement as enterprises move to the cloud. Copyright The Open Group and Interarbor Solutions, LLC, 2005-2012. All rights reserved.

You may also be interested in:

• The Open Group Trusted Technology Forum is Leading the Way to Securing Global Supply Chains
• Corporate Data, Supply Chains Remain Vulnerable to Cyber Crime Attacks Says Open Group Conference Speaker
• Open Group Conference Speakers Discuss the Cloud: Higher Risk or Better Security?
• Capgemini's CTO on Why Cloud Computing Exposes the Duality Between IT and Business
• San Francisco Conference observations: Enterprise transformation, enterprise architecture, SOA and a splash of cloud computing
• MIT's Ross on how enterprise architecture and IT more than ever lead to business transformation
• Overlapping criminal and state threats pose growing cyber security threat to global Internet commerce, says Open Group speaker

Capgemini's CTO on Why Cloud Computing Exposes the Duality Between IT and Business

Transcript of a BriefingsDirect podcast in conjunction with latest The Open Group Conference in San Francisco. Capgemini CTO Andy Mulholland discusses the transformed enterprise.

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

Register for The Open Group Conference
Jan. 30 - Feb. 3 in San Francisco.

Dana Gardner: Hello, and welcome to a special BriefingsDirect thought leadership interview series coming to you in conjunction with The Open Group Conference this January in San Francisco. I'm Dana Gardner, Principal Analyst at Interarbor Solutions and I will be your host throughout these discussions.

The conference will focus on how IT and enterprise architecture support enterprise transformation. Speakers in conference events will also explore the latest in service oriented architecture (SOA), cloud computing, and security.

We’re here now with one of the main speakers of the conference, Andy Mulholland, the Global Chief Technology Officer and Corporate Vice President at Capgemini. In 2009, Andy was voted one of the top 25 most influential CTOs in the world by InfoWorld. And in 2010, his CTO Blog was voted best blog for business managers and CIOs for the third year running by Computer Weekly.

As a lead-in to his Open Group conference presentation on the transformed enterprise, Andy and I drill down on one of the year’s hottest technology and business trends: cloud computing.

Capgemini has published a white paper on cloud computing. It draws distinctions between what cloud means to IT, and what it means to business -- while examining the complex dual relationship between the two.

To find out more about these two cloud imperatives, please join me now in welcoming Andy Mulholland, Global Chief Technology Officer at Capgemini. Welcome back to BriefingsDirect, Andy. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

Andy Mulholland: Hi, and thank you very much for inviting me.

Gardner: My pleasure. I really enjoyed reading a preview of this white paper. I read it with great interest, and what jumps out at me this duality. Why do business people think they have a revolution on their hands, and yet IT people look at as an evolution, something about efficiency of infrastructure?

Mulholland: Well, that’s because we define the role of IT and give it the responsibility and the accountability in the business in a way that is quite strongly related to internal practice. It’s all about how we manage the company’s transactions, how we reduce the cost, how we automate business process, and generally try to make our company a more efficient internal operator.

When you look at cloud computing through that set of lenses, what you’re going to see is how I can use it in that model. Some of the technologies from cloud computing, principally virtualization, give you ways to improve how you deliver the current cloud server-centric, application-centric environment.

So you see there’s an evolution, and you start asking questions about how far can we go: Would I go outside and put enterprise applications on the cloud? Would I maybe run a private cloud internally? Etc.

However, when the business people want to talk about that subject, they tend to talk about it and reflect on it in terms of the change in society and the business world, which we all ought to recognize because that is our world, around the way we choose what we buy, how we choose to do business with people, how we search more, and how we’ve even changed that attitude.

Changed our ways

There's a whole list of things that we simply just don’t do anymore because we’ve changed the way we choose to buy a book, the way we choose and listen to music and lots of other things.

So we see this as a revolution in the market or, more particularly, a revolution in how cloud can serve in the market, because everybody uses some form of technology.

So then the question is not the role of the IT department and the enterprise -- it’s the role technology should be playing in their extended enterprise in doing business.

Gardner: In the paper, it describes the IT view of cloud as "inside-out" -- so their IT-centric world, their legacy, their requirements, what they view as their mission, and how to project that outward. And then the term it uses for the business side that you just described is "outside-in." That is to say, beyond the perimeter of IT, beyond the perimeter of the business.

How is it these seemingly disjointed and confusing approaches can come together? Is there a need for them to somehow mesh and be aligned?

Mulholland: Most businesses ought to be aligned in their operations or it becomes quickly quite a problem. But if we just pick up the terms, which we used as ways to define the first word, the function inside is the primary function, and out is the secondary function, and the other way around.

Most businesses ought to be aligned in their operations or it becomes quickly quite a problem.

IT is clearly internally focused. When we look at what we do outside the firewall, we define it on the governance, security, and the risk structure of inside IT. In other words, we're worried about the exported information. We're worried about who comes through the firewall and under what circumstance. And we’re worried that when you go out with your corporate machine in the big wide world, someone might steal it with data on it.

Alternatively, you might be unfortunate enough on the Internet to pick up some nasty malware that could have some bad effects. For all of those reasons, we put very heavy governance and restrictions on PCs. They usually lock down more than only one control, but when we go outside, we’d like to hear there’s a virtual private network (VPN) to reincorporate inside the firewall for safety.

By definition, we have a way around outside-in. People are saying, well no, actually, I require very little about the internal world. I'm very focused on the external world. Obviously, that serves people, service engineers, but actually it’s quite a lot of people.

The small joke there is that people don’t buy iPads in order to get better use of enterprise IT. They buy iPads to escape the limitations of enterprise IT, because that's fundamentally working on the web outside, with very limited internal links.

When I’m out on the road, there are four services I use from Capgemini. All of them are web-mounted. I simply don’t use a VPN connection, and I don’t use a lock-down machine during the day. I tend to do it in the evenings or in the early mornings, when I have to do things that are about the more sensitive side of our operations.

The rest of the day, web-based, push email works really well on my iPad. Not to give particularly advert for that, but I also use a Windows phone. I also use social networking system, and I use a knowledge management system, and I use time and expenses recording systems.

The outside world

All of them enable me to function in the outside world without a number of restrictions. Why? Because the primary task I have is to work with industry partners, clients, and various teams based on other people’s sites. All of that is about how I function in the outside world.

Now when we take an interesting example of that: customer relationship management (CRM). You can see very clearly CRM has meant how the company keeps its sales funnel, its clients, and other things inside its IT, transacts it, secures it, and grinds it into business information so it knows where it is.

Today, we talk about social CRM and when we talk about social CRM, we mean it's outside-in. We mean it's sales people using packages that can look at the person they’re selling to, find all the information about them by looking at various social sites. They can exchange through collaboration and knowledge, and share in social networks with their colleagues, any information about the account that's known or whatever is happening. In other words, it becomes an external task.

Now the two sides clearly exist together because you must keep your funnel up. You must know what’s happening. You must keep the internal clients. The other way around, the sales people want to exploit insights of what’s happening that they can gain from very different directions than classic internal structured information.

Gardner: So there are some significant advantages to users like yourself to pursue outside services, recognizing that they can get process innovation, data sharing or transference. There's an opportunity to engage with partners. At the same time, IT still needs to be mindful of its mission around security and protection.

They slowly, but surely, destroyed the business integrity of the data by all having different versions.

So I'm wondering again, not so much alignment, but somebody has to bend. Does IT need to go thinking more "outside," or do the folks who are doing these outside activities need to think more about IT? How can they meet up in the middle somewhere?

Mulholland: Now we’re back to your point about enterprise transformation and what that really means. I'm always very conscious of the fact that the phrase has been used for a long time in a variety of ways, as have many of the other buzzwords that go with it.

But this time, what we actually mean is that -- as with the last wave of where the big technology changed in late 80s and early '90s, when we brought in the PC, there is almost a direct correlation between the two [trends]. Business people brought in PCs, because they could use spreadsheet and could be more insightful in their use of information, such as it was at that time.

But what happened was that they slowly, but surely, destroyed the business integrity of the data by all having different versions. Where we went to with that was two things. We went to enterprise resource planning (ERP), which was one version of the truth. But the really important point was that we started to redesign around business process reengineering to flow all the process across the organization. Not that we had separate isolated departments, but the question was how do we flow across.

That was quite difficult at that time because it presented a lot of command and control problems. In fact, email was brought in as the answer, because you needed the names of the people along the process and you could do command and communication along the process, even if in the previous structure, department organization hadn’t fit.

Business transformation

That was a business transformation at that time. It was a transformation around the way we organized our business to do business. From that, we organized our business model to be based on that.

So we use phrases like "do more with less," "concentrate on one or two or three lines where you're the number one or two in the market," etc. That was a very clear business transformation in the way we do business, the way we organize our business, and our business models.

Two of the most popular books recently, include Seizing the White Space, which argues that in the past, it was difficult to transfer your business model too far. I use an example, Amazon. If they sold books, they could sell DVDs, because fundamentally the same business process supported both. But in Seizing the White Space, a popular book on Harvard Business Press, it defines for a lot of people 19 new business models that their enterprise could adopt.

It defined the idea that actually they could do something like Amazon Web Services, where how they service the market was distinctly different from how they ran their business process and created an invoice.

A more popular book more recently has been The Power of Pull, and in all of these, the idea is that we’re really seeing a decentralization of the front office in order to respond to and follow the market and the opportunities and the events in very different ways.

That was a very clear business transformation in the way we do business, the way we organize our business, and our business models.

The Power of Pull says that I do what my market is asking me and I design business process or capabilities to be rapidly orchestrated through the front office around where things want to go, and I have linkage points, application programming interface (API) points, where I take anything significant and transfer it back.

Most of the major technology players in the software industry are pretty advanced with this in the way that they're supporting their current application-centric IT environment, developing a new environment in front of that, and offering middleware and mix the two together.

But the real challenge is -- and it was put to me today in a client discussion -- that their business was designed around 1970 computer systems, augmented slowly around that, and they still felt that. Today, their market and their expectations of the industry that they're in were that they would be designed around the way people were using their products and services and the events and that they had to make that change.

To do that, they're transformed in the organization, and that's where we start to spot the difference. We start to spot the idea that your own staff, your customers, and other suppliers are all working externally in information, process, and services accessible to all on an Internet market or architecture.

So when we talk about business architecture, it’s as relevant today as it ever was in terms of interpreting a business.

Set of methodologies

But when we start talking about architecture, The Open Group Architectural Framework (TOGAF) is a set of methodologies on the IT side -- the closed-coupled state for a designed set of principles to client-server type systems. In this new model, when we talk about clouds, mobility, and people traveling around and connecting by wireless, etc., we have a stateless loosely coupled environment.

The whole purpose of The Open Group is, in fact, to help devise new ways for being able to architect methods to deliver that. That's what stands behind the phrase, "a transformed enterprise."

Gardner: All right. So we certainly have a strong case for transformation being necessary and pressing, especially as organizations try to react to their very dynamic markets, accommodate them, and then to try to tool the means of orchestrating the processes and supporting those new market requirements.

At the same time, Andy, there's some added complexity in that, the external landscape has shifted when we think about things like mobility, which means any connection, any device, any service. Also, when we think about cloud, which is compute and development resources, as well as past and present IT resources on demand, and then we think about big data -- so real-time information and intelligence as well as greatly improved efficiencies around storage and search.

Then, I suppose, the last big variable to consider in this mix is the external economic environment. The timing is that most organizations are still facing reduced spending. They have also expectations from the customers that are more demanding.

Most organizations are still facing reduced spending. They have also expectations from the customers that are more demanding.

So, given the fact that we’ve identified the need, how can we leverage these changes in the market -- things like mobility, cloud, big data, and the requirements around efficiency and productivity -- to spur the enterprise forward?

What do we need to start doing differently that was not the same as in the early 90s with business process reengineering?

Mulholland: Let’s go back again to the conversation this morning with a client. It’s always interesting to touch reality. This particular client is looking at the front end of a complex ecosystem around travel, and was asked this standard question by our account director: Do you have a business case for the work we’re discussing?

The reply from the CEO is very interesting. He fixed him with a very cold glare and he said, "If you were able to have 20 percent more billable hours without increasing your cost structure, would you be bothered to even think about the business case?"

The answer in that particular case was they were talking about 10,000 more travel instances or more a year -- with no increase in their cost structure. In other words, their whole idea was there was nothing to do with cost in it. Their argument was in revenue increase, market share increase, and they thought that they would make better margins, because it would actually decrease their cost base or spread it more widely.

That's the whole purpose of this revolution and that's the purpose the business schools are always pushing, when they talk about innovative business models. It means innovate your business model to look at the market again from the perspective of getting into new markets, getting increased revenue, and maybe designing things that make more money.

Using technology externally

We're always hooked on this idea that we’ve used technology very successfully internally, but now we should be asking the question about how we’re using technology externally when the population as a whole uses that as their primary method of deciding what they’re going to buy, how they’re going to buy it, when they’re going to buy it, and lots of other questions.

If we go back to the basic mission of The Open Group, which is boundarylessness of this information flow, the boundary has previously been defined by a computer system updating another computer system in another company around traditional IT type procedural business flow.

Now, we’re talking about the idea that the information flow is around an ecosystem in an unstructured way. Not a structured file-to-file type transfer, not a structured architecture of who does what, when, and how, but the whole change model in this is unstructured.

It’s a model around big data, saying that there is information everywhere. How do I get the insight I want from it? And when I’ve got the insight I want from it, which is more driven by search than ever was driven by queries in the old landscape, how and where do I use it? In other words, how do I start to evoke a process between different companies?

Let’s just reiterate this whole theme about clouds, mobility, and so on, in a very simple way. It is actually the fourth generation of the Internet. Some people will talk about it being the third because they will miss out one of the stages. I would say it’s the fourth for the following reason.

Web 2 is quite important, because it showed us that actually we are focused upon people making insightful decisions, as much or more than we've ever been focused previously around the computer.

The first generation was universal connectivity. That’s what underpins mobility. The second generation was universal shared content. We could read and look at content, the beginnings of the big data model that we know today, the beginnings of the shift to the search engine model, and the way we used the big data model of the web.

The third one is sometimes not included by one or two other people. One or two of my colleagues, friends, and companies don’t always include Web 2. I think Web 2 is quite important, because it showed us that actually we are focused upon people making insightful decisions, as much or more than we've ever been focused previously around the computer.

The fourth one is that if I can connect to you, if I can see the content, if I can interact to find out that, that really is what I want to do. I ought to be able to trigger shared process. I ought to be able to trigger something that the process is from the various parties in that model. Travel, as I just said this morning, are actually able to come together to give me my version of what I want, and that includes other comments people hear about open data, etc.

If you want to see a classic example of this it's from Apple. I appreciate that I'm using Apple a lot, but I'm using it because this is relatively mature at the moment and it's pretty easy to demonstrate. Go to the Apple App Store and load iFly. If you're a frequent airline flyer, you're going to thank me a lot for this.

It takes the information which is published all the time in an open data format by various airports, airlines, etc., and consolidates it to give it a polarized view for you of the travel you're about to do. It tells you about the airport you're going to go through, you can find out what restaurants are by the gate you're going to travel from. It tells you whether the aircraft is on time/off time, how it synchronizes with the next flight you're going to make, etc.

Register for The Open Group Conference
Jan. 30 - Feb. 3 in San Francisco.

Transformation model

That is a transformation. When we talk about these elements, if we recombine them around this loose structured coupling to give different polarizations to the person, the situation, or the event, by combining those four factors, that’s what’s leading to the business transformation model.

Gardner: I guess it's important to point out here, Andy, that the stakes are relatively high. If you look at these issues and you think that it's a perfect storm that these are things that are too complicated, difficult to manage, you're just going to hunker down, reinforce your firewall, then this could be an existential decision.

On the other hand, like the CEO that you mentioned this morning, if you look at this as a game changing opportunity, 20 percent improvement in revenue and share, but at no additional cost, well, then this could be a game-changing beneficial approach.

How do organizations make sure they're the latter, and not the former? Who in the organization can be the change agent that can make that leap between the duality view of cloud that IT has, and these business opportunists?

Mulholland: Frankly, it's happening in most organizations already in much the same way as I said earlier. There's a direct correlation with what happened with the PC. If you go into many organizations today, and the advice I usually offer is go through the corporate credit cards and find out who is spending money with places like Amazon or Google or something like that, the answer is usually pretty shocking. It's much more than people realize.

CEOs are quite noticeably reading the right articles, hearing the right information from business schools, etc., and they're getting this picture that they're going to have new business models and new capabilities.

My point about that exercise is that the business managers on these systems -- which are relatively easy to do something quick around, like a quick spreadsheet was -- are actually already implementing and getting good results.

The other way around, the CEOs are quite noticeably reading the right articles, hearing the right information from business schools, etc., and they're getting this picture that they're going to have new business models and new capabilities. So the drive end is not hard. The problem that is usually encountered is that the IT department’s definition and role interferes with them being able to play the role they want.

What we're actually looking for is the idea that IT, as we define it today, is some place else. You have to accept that it exists, it will exist, and it’s hugely important. So please don’t take those principles and try to apply them outside.

The real question here is when you find those people who are doing the work outside -- and I've yet to find any company where it hasn’t been the case -- and the question should be how can we actually encourage and manage that innovation sensibly and successfully?

What I mean by that is that if everybody goes off and does their own thing, once again, we'll end up with a broken company. Why? Because their whole purpose as an enterprises is to leverage success rapidly. If someone is very successful over there, you really need to know, and you need to leverage that again as rapidly as you can to run the rest of the organization. If it doesn’t work, you need to stop it quickly.

Changing roles

In models of the capabilities of that, the question is where is the government structure? So we hear titles like Chief Innovation Officer, again, slightly surprising how it may come up. But we see the model coming both ways. There are reforming CIOs for sure, who have recognized this and are changing their role and position accordingly, sometimes formally, sometimes informally.

The other way around, there are people coming from other parts of the business, taking the title and driving them. I’ve seen Chief Strategy Officers taking the role. I’ve seen the head of sales and marketing taking the role.

I recognize also that there are a lot of companies where they have actually formed a whole new business division to behave differently. Again, the real example is a global company in desking systems recognizing the number of people in offices at desks is finite at best, and possibly going down, starting a division around virtual offices and supporting their employees to work away from a fixed office.

It's the same clients they're dealing with, the same customers, the same core competences. They're just reinventing a new business model to get them new revenue as there are uncertainties about the other one.

Now the question behind that was that it's clearly a business strategic decision, but there was the possibility of recognizing that it could be done, the technology existed, and the customers were changing their mind.

They're just reinventing a new business model to get them new revenue as there are uncertainties about the other one.

Certainly, recognizing the technology possibilities should be coming from the direction of the technology capabilities within the current IT department. The capability of what that means might be coming differently. So it’s a very interesting balance at the moment, and we don’t know quite the right answer.

We had CIOs who were not sure what was the right answer. Some of them came in with the PCs themselves, and some of them were business managers who took over the role and started to look to see what they could do.

So right now, I don’t know that there is a single, fixed answer. What I do know is that it’s happening and the quick-witted CIOs are understanding that it’s a huge opportunity for them to fix their role and embrace a new area, and a new sense of value that they can bring to their organization.

Gardner: So perhaps it’s going to be some organic or combination of organic and structured approaches. It could be any number of people that are the drivers in these different companies and in different verticals. I suppose what’s really important then is identifying successes, and then making them repeatable.

How do the roles, the traditional roles of the enterprise architect and the business architect come to bear on this ability to recognize successes -- the inside-out, the outside-in successes, some combination? Make them repeatable and perhaps move toward this cloud opportunity, rather than cloud as a handicap, to your company’s success?

Issuing invoices

Mulholland: Well, this goes prominently about the new world and the transformed environment, but we should never forget that all sorts of business are actually about the issuing of an invoice and proving that it was a valid invoice to an auditor.

So, that puts us firmly back in the old world. What we're really talking about is how do you move through three different recognizable layers in an organization, while remaining compliant -- the world that says we have to able to show to an auditor procedures and processes and data and methods that are all clean and good.

Then if we look above that, we have our core competencies. What is the industry we're in, and, if I put it in business jargon, what is the value that the shareholders are buying from us.

Motorcars might be an example. We have factories, skilled staff, and every detail. But in that layer, we see a very rich set of applications that enable us to, if we stick to automotives, design CAD, do things with them, etc. All we're talking about is in front of that is a new layer that asks how we differentiate.

Classic differentiation has been around brand. There's Volkswagen, Audi, Fiat and Škoda. If we take a European respective of a very successful car company, each of those brands reaches a different marketplace, and that gives them more reach than if they only had one brand.

At the back, it's very focused on the procedure, application, and data. At the front, it's very focused on orchestration of clusters of different services to seek different environments.

But that differentiation is built on the same chassis in each one of those cars. So their core competency actually gives them a core base ordered to express differentiation. Beyond that, how do the people map to the layers?

If you start looking at the business that way, you actually start this top-down. You ask where we differentiate, how do we engage with a market in a different way, or is our new business model where you look bottom up? You ask how we make sure we're issuing valid invoices?

If you check that through, that use of thread in a process that runs through from the front to the back, always has to be. At the back, it's very focused on the procedure, application, and data. At the front, it's very focused on orchestration of clusters of different services to seek different environments.

Each of those services is a definable entity with a definable task. Success starts from SOA, which frankly we didn’t do very well as an industry. It starts from the idea that we know and define each web services properly, and we define the rules in terms of how the orchestration of those can work. That’s why there is a lot of interest at the moment in business process management.

Redesigning process

What we’ve eventually done is say at the back we’ve bolted the clusters together in a monolithic application and how we integrate those together, whereas at the front, our task is actually to identify spectacular small business service elements in a very well-defined manner, so that they can be clicked together to give us the freedom to redesign process on the fly in order to adjust to this new market.

So the clarity of thinking about business, the transition of that into technology architecture has not decreased at all. In fact, if anything, it’s gotten more complicated and more interesting as we now add this new layer of business to technology architecture.

Gardner: Returning to the upcoming Capgemini white paper, it adds a sense of urgency at the end on how to get started. It suggests that you appoint a leader, but a leader first for the inside-out element of cloud and transformation and then a second leader, a separate leader perhaps, for that outside-in or reflecting the business transformation and the opportunity for what’s going on in the external business and markets. It also suggests a strategic road map that involves both business and technology, and then it suggests getting a pilot going.

We're about out of time Andy, but on this sense of urgency in getting started, as you say, a lot of these things are happening already. How does it become something that you can manage, something that you can measure that becomes something that is lower risk and more comfortable for the leadership in these organizations?

Mulholland: I usually reply to most challenges I'm given about the complexity of trying to keep everybody going in the same direction in Capgemini with one very simple answer. The question is do you know who is responsible. If you don’t, you'd better figure out how you're going to make someone responsible, because in any situation, someone has to be deciding what we're going to do and how we're going to do it.

No business can survive by going off in half-a-dozen directions at once. You won't have the money. You won't have the brand. You won't have anything you’d like.

Having defined that, there are very different business drivers, as well as different technology drivers, between the two. Clearly, whoever takes those roles will reflect a very different way that they will have to run that element. So a duality is recognized in that comment.

On the other hand, no business can survive by going off in half-a-dozen directions at once. You won't have the money. You won't have the brand. You won't have anything you’d like. It's simply not feasible.

So, the object of the strategic roadmap is to reaffirm the idea of what kind of business we're trying to be and do. That’s the glimpse of what we want to achieve. In other words, do we want to go from books into DVDs or do we want to go from DVDs into web services -- the example I gave earlier.

There has to be a strategy. Otherwise, you’ll end up with way too much decentralization and people making up their own version of the strategy, which they can fairly easily do and fairly easily mount from someone else’s cloud to go and do it today.

So the purpose of the duality is to make sure that the two roles, the two different groups of technology, the two different capabilities they reflect to the organization, are properly addressed, properly managed, and properly have a key authority figure in charge of them.

Enablement model

The business strategy is to make sure that the business knows how the enablement model that these two offer them is capable of being directed to where the shareholders will make money out of the business, because that is ultimately that success factor they're looking for to drive them forward.

Gardner: Very good. We’ve been talking with Andy Mulholland, the global chief technology officer at Capgemini. As a lead-in to his opening group presentation on the transformed enterprise, Andy and I have been exploring some of the major concepts from an upcoming Capgemini white paper on the intriguing dualities of cloud computing.

This special BriefingsDirect discussion comes to you in conjunction with The Open Group conference from January 30 to February 3 in San Francisco. You’ll hear more from Andy and many other global leaders on the ways that IT and enterprise architecture support enterprise transformation.

So thank you very much, Andy, for joining us. It's been a fascinating discussion.

Mulholland: Thank you, very much indeed. I’ve enjoyed it.

Gardner: And I look forward to your presentation in San Francisco. I also encourage our readers and listeners to register, explore, and attend the conference.

This is Dana Gardner, Principal Analyst and Interarbor Solutions, your host and moderator throughout these series of thought leadership interviews in association with the conference. Thanks to you for listening, and come back next time.

Register for The Open Group Conference
Jan. 30 - Feb. 3 in San Francisco.

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

Transcript of a BriefingsDirect podcast in conjunction with latest The Open Group Conference in San Francisco. Capgemini CTO Andy Mulholland discusses the transformed enterprise. Copyright Interarbor Solutions, LLC, 2005-2012. All rights reserved.

You may also be interested in:

• MIT's Ross on how enterprise architecture and IT more than ever lead to business transformation
• Overlapping criminal and state threats pose growing cyber security threat to global Internet commerce, says Open Group speaker
  
• Exploring Business-IT Alignment: A 20-Year Struggle Culminating in the Role and Impact of Business Architecture
• The Open Group's Cloud Work Group Advances Understanding of Cloud-Use Benefits for Enterprises
• Exploring the Role and Impact of the Open Trusted Technology Forum to Ensure Secure IT Products in Global Supply Chains

MIT's Ross on How Enterprise Architecture and IT More Than Ever Lead to Business Transformation

Transcript of a BriefingsDirect podcast in conjunction with The Open Group Conference in San Francisco on how enterprise architecture can lead to greater efficiency and agility.

Register for The Open Group Conference
Jan. 30 - Feb. 3 in San Francisco.

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

Dana Gardner: Hello, and welcome to a special BriefingsDirect thought leadership interview series coming to you in conjunction with The Open Group Conference this month in San Francisco. I'm Dana Gardner, Principal Analyst at Interarbor Solutions and I will be your host throughout these discussions.

The conference will focus on how IT and enterprise architecture support enterprise transformation. Speakers in conference events will also explore the latest in service oriented architecture (SOA), cloud computing, and security.

Today, we're here with one of the main speakers at the conference, Jeanne Ross, Director and Principal Research Scientist at the MIT Center for Information Systems Research. Jeanne studies how firms develop competitive advantage through the implementation and reuse of digitized platforms.

She is also the co-author of three books: IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Enterprise Architecture As Strategy: Creating a Foundation for Business Execution, and IT Savvy: What Top Executives Must Know to Go from Pain to Gain.

As a lead-in to her Open Group presentation on how adoption of enterprise architecture (EA) leads to greater efficiencies and better business agility, Jeanne and I will now explore how enterprise architects have helped lead the way to successful business transformations.

Please join me now in welcoming Jeanne Ross, Director and Principal Research Scientist at the MIT Center for Information Systems Research. Welcome back to BriefingsDirect, Jeanne. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

Jeanne Ross: Thank you, Dana. Nice to be here.

Gardner: Your upcoming presentation will describe how enterprise architecture has contributed to success for such companies as Campbell Soup and Southwest Airlines, but before we go into that, it has been typically difficult to concretely link things like IT productivity and general business success. I wonder, then, how you measure or determine that enterprise architects and their practices are intrinsic to successful business transformations? How do we link the two?

Ross: That’s a great question. Today, there remains kind of a leap of faith in recognizing that companies that are well-architected will, in fact, perform better, partly because you can be well-architected and perform badly. Or if we look at companies that are very young and have no competitors, they can be very poorly architected and achieve quite remarkably in the marketplace.

But what we can ascribe to architecture is that when companies have competition, then they can establish any kind of performance target they want, whether it’s faster revenue growth or better profitability, and then architect themselves so they can achieve their goals. Then, we can monitor that.

We do have evidence in repeated case studies of companies that set goals, defined an architecture, started to build the capabilities associated with that architecture, and did indeed improve their performance. We have wonderful case study results that should be very reaffirming. I accept that they are not conclusive.

Architectural maturity

We also have statistical support in some of the work we've done that shows that high performers in our sample of 102 companies, in fact, had greater architecture maturity. They had deployed a number of practices associated with good architecture.

So we do have evidence. It’s just that if you really don’t want to believe it, you could poke holes in it. There still is a certain amount of faith attached to the link between performance and architecture.

Gardner: I certainly get your point that repeatability would be a chief indicator, that if you intend to do something repeatedly, you can point to the ways in which you would carry that out. How about the intent from the perspective of wanting to transform in a certain way that you haven’t done before? Is there something that being an architect allows that’s different from the past? Is there something that’s new about this, rather than just trying to reengineer something?

Ross: Yes, the thing we're learning about enterprise architecture is that there's a cultural shift that takes place in an organization, when it commits to doing business in a new way, and that cultural shift starts with abandoning a culture of heroes and accepting a culture of discipline.

Nobody wants to get rid of the heroes in their company. Heroes are people who see a problem and solve it. But we do want to get past heroes sub-optimizing. What companies traditionally did before they started thinking about what architecture would mean, is they relied on individuals to do what seemed best and that clearly can sub-optimize in an environment that increasingly is global and requires things like a single face to the customer.

Nobody wants to get rid of the heroes in their company. Heroes are people who see a problem and solve it.

What we're trying to do is adopt a culture of discipline, where there are certain things that people throughout an enterprise understand are the way things need to be done, so that we actually can operate as an enterprise, not as individuals all trying to do the best thing based on our own experience.

The fundamental difference of being an architected firm is that there is some underlying discipline. I'll caution you that what tends to happen is great architects really embrace the discipline. They love the discipline. They understand the discipline, and there is a reluctance to accept that that’s not the only thing we need in our organization. There are times when ad hoc behaviors enable us to be much more innovative and much more responsive and they are exactly what we need to be doing.

So there is a cultural shift that is critical to understanding what it is to be architected. That’s the difference between a successful firm that’s successful because it hasn’t gotten into a world of really tough competition or restrictions on spending and things like that and an organization that is trying to compete in a global economy.

Gardner: It’s interesting to me that we're focusing not so much on the individual, the enterprise architect, but more the office of the enterprise architect.

Ross: Right. Would you like me to speak to an architect instead? Would that help?

Cultural phenomenon

Gardner: No, the point is that the champion that is important is not just an individual. It’s that putting into place a repeatable office of the enterprise architect that is a cultural phenomenon, rather than a charismatic one.

Ross: Yes.

Gardner: What then is the role of the architect, if this isn’t just about a champion, but really about change that’s repeatable and that’s culturally inculcated? What, then, is the role and what should they do?

Ross: The architect plays a really critical role in representing the need for this discipline, for some standards in the organization, and for understanding the importance of shared definitions for data. The architect should be able to create a very constructive tension in the organization, and that’s the tension between individuality, innovativeness, local responsiveness, and the need for enterprise thinking, standardization, and discipline.

Normally, in most companies, the architect’s role will be the enforcer of discipline, standardization and enterprise thinking. The tension will be created by all kinds of people who are saying, "Wait, I'm different. I need this. My customer insists on that." When the tension is working effectively, you get just enough architecture.

One thing we've learned over the years, as we've studied architecture, is that’s actually what we want. We don’t want to be a tightly architected organization, because tomorrow we're going to wake up and the world is going to change, and we have to be ready for that. We want to be architected enough to be efficient, to be able to reuse those things we need to reuse, to be agile, but we don’t want to start embracing architecture for architecture’s sake or discipline for discipline’s sake.

We don’t want to be a tightly architected organization, because tomorrow we're going to wake up and the world is going to change, and we have to be ready for that.

We really just need architecture to pull out unnecessary cost and to enable desirable reusability. And the architect is typically going to be the person representing that enterprise view and helping everyone understand the benefits of understanding that enterprise view, so that everybody who can easily or more easily see the local view is constantly working with architects to balance those two requirements.

Gardner: Let’s take a contextual view here. It’s 2012 already and there's a lot happening in IT with disruption in the form of cloud computing trends, an emphasis on mobile computing, big data, and the ability to harness analytics in new and interesting ways, all sort of churning together. We're also still faced with a difficult environment, when it comes to the economy. Is this a particularly good time, from your vantage point, to undertake enterprise architecture, or is this perhaps not the best time?

Ross: It’s a great time for most companies. There will be exceptions that I'll talk about in a minute. One thing we learned early on in the research is that companies who were best at adopting architecture and implementing it effectively had cost pressures. What happens when you have cost pressures is that you're forced to make tough decisions.

If you have all the money in the world, you're not forced to make tough decisions. Architecture is all about making tough decisions, understanding your tradeoffs, and recognizing that you're going to get some things that you want and you are going to sacrifice others.

If you don't see that, if you just say, "We're going to solve that by spending more money," it becomes nearly impossible to become architected. This is why investment banks are invariably very badly architected, and most people in investment banks are very aware of that. It’s just very hard to do anything other than say, "If that’s important to us, let’s spend more money and let’s get it." One thing you can't get by spending more money is discipline, and architecture is very tightly related to discipline.

Register for The Open Group Conference
Jan. 30 - Feb. 3 in San Francisco.

Tough decisions

In a tough economy, when competition is increasingly global and marketplaces are shifting, this ability to make tough decisions is going to be essential. Opportunities to save costs are going to be really valued, and architecture invariably helps companies save money. The ability to reuse, and thus rapidly seize the next related business opportunity, is also going to be highly valued.

The thing you have to be careful of is that if you see your markets disappearing, if your product is outdated, or your whole industry is being redefined, as we have seen in things like media, you have to be ready to innovate. Architecture can restrict your innovative gene, by saying, "Wait, wait, wait. We want to slow down. We want to do things on our platform." That can be very dangerous, if you are really facing disruptive technology or market changes.

So you always have to have that eye out there that says, "When is what we built that’s stable actually constraining us too much? When is it preventing important innovation?" For a lot of architects, that’s going to be tough, because you start to love the architecture, the standards, and the discipline. You love what you've created, but if it isn’t right for the market you're facing, you have to be ready to let it go and go seize the next opportunity.

Gardner: Perhaps this environment is the best of all worlds, because we have that discipline on the costs which forces hard decisions, as you say. We also have a lot of these innovative IT trends that would almost force you to look at doing things differently. I'm thinking again of cloud, mobile, the big data issues, and even social-media types of effects. So is that the case from your perspective?

Ross: Absolutely. We should all look at it that way and say, "What a wonderful world we live in." One of the companies that I find quite remarkable in their ability to, on the one hand, embrace discipline and architecture, and on the other hand, constantly innovate, is USAA. I'm sure I'll talk about them a little bit at the conference.

This is a company that just totally understands the importance of discipline around customer service. They're off the charts in their customer satisfaction.

This is a company that just totally understands the importance of discipline around customer service. They're off the charts in their customer satisfaction.

They're a financial services institution. Most financial services institutions just drool over USAA’s customer satisfaction ratings, but they've done this by combining this idea of discipline around the customer. We have a single customer file. We have an enterprise view of that customer. We constantly standardize those practices and processes that will ensure that we understand the customer and we deliver the products and services they need. They have enormous discipline around these things.

Simultaneously, they have people working constantly around innovation. They were the first company to see the need for this deposit with your iPhone. Take a picture of your check and it’s automatically deposited into your account. They were nearly a year ahead of the next company that came up with that service.

The way they see it is that for any new technology that comes out, our customer will want to use it. We've got to be there the day after the technology comes out. They obviously haven't been able to achieve that, but that’s their goal. If they can make deals with R&D companies that are coming up with new technologies, they're going to make them, so that they can be ready with their product when the thing actually becomes commercial.

So it's certainly possible for a company to be both innovative and responsive to what’s going on in the technology world and disciplined and cost effective around customer service, order-to-cash, and those other underlying critical requirements in your organization. But it's not easy, and that's why USAA is quite remarkable. They've pulled it off and they are a lesson for many other companies.

Gardner: And as you pointed out, being able to repeat this is really essential. So that gets back to that discipline. But you've mentioned that you've got ongoing research, and you've mentioned a company, USAA that you're working with and you're familiar with. I suppose this gives us a chance then to step back and take a look at what the MIT Center for Information Systems Research is and does and your role there.

Value from IT

Ross: The Center for Information Systems Research is part of the Sloan School of Management. We were formed in 1974 to study how companies get value from information technology.

In 1974, we were studying mainframes and IT directors. There was no such thing as a CIO yet, but we have certainly gone through the stages of the increasing importance of IT in organizations. We went through the end-user computing. We went through enterprise resource planning (ERP) and e-business. We've followed, and hopefully led, thinking around how IT adds value in organizations.

You mentioned this is a good time to be introducing architecture. This is a good time to be at the Center for Information Systems Research, because IT is so central now to business success, and many companies that didn't start as digital companies are really struggling to understand what it means to transform for the digital economy, and that's exactly what we study.

Gardner: You've mentioned one company, USAA. Let’s take a look at a number of companies. I know you're going to be mentioning several during your presentation. Are there any salient lessons that are common among them? Are they all different and therefore you can't draw such common denominators, or are there a couple that jump out?

Ross: Well, our established research on this, and this is the work that appeared in the Enterprise Architecture as Strategy book. We find that the things we learned as we prepared that book are still very true. Companies indeed go through stages, and they're very predictable -- we've not yet seen an exception to this -- and they're hard.

You have to respond to the marketplace. You have to do whatever it takes.

Stage one is the stage of, don't worry about the discipline, just have fun, learn how to use IT, apply it to any strategic need where it makes sense, and go out there and do your thing, but eventually all of that will lead to a fairly messy legacy environment.

We saw, when we studied these stages, that as companies understood these stages, they would avoid stage one, but it turns out that, if you are a fast growing innovative company, you can't avoid that stage. You actually don't know how you're going to make money. You have to respond to the marketplace. You have to do whatever it takes. Then, as you get really good at things, you start to establish yourself in what is often now a new industry.

You've created an industry. That's how you succeeded. But because you're making money, you're going to attract competitors. When you get to the stage that you actually have competitors, then you look at what you created and you say, "Oh no, we really have to clean up some of this legacy." That’s really what stage two is about. It's the underlying technology.

Now, we're learning how to not make quite as big a mess, but there is still this stage of, "Okay, let's refrain from kind of the crazy innovation and be more disciplined about what we put in and how we reuse" and all that kind of thing.

In the third stage, we get much more emphasis on building platforms that wire in those core processes that enable us to do high-volume transactions. These are things around order-to-cash, human resources (HR), or finance. There will be some of that in the earlier stages, but we really worry about scale in this third stage, scaling up so that we can manage large volume transactions.

We think this third stage is going to look different in a world of software as a service (SaaS) and cloud, because in the past, third stage often meant you put in Oracle, SAP, or something like that. Nowadays, it's much more about piecing together some cloud services. It does look different. It goes in faster, but it's still pretty tricky. If you're not architected well, you can really create a mess in stage three.

Working smarter

Stage four is really about working smarter on this platform, learning how to innovate off the platform. And companies are struggling to get there, because once you get in this platform, it takes a while to really make it solid and learn how to use it well. We've been studying that for some time, and companies get there.

This is the story of Campbell Soups and the Southwest Airlines. They're trying to use the platforms they've created, even though the process of putting them in takes a very long time. So you're still putting them in, while you are trying to learn to get good at using them. It's a challenging world out there.

Gardner: So I shouldn’t reach the conclusion that the enterprise architecture kicks in, in stage three and four. It should be something that would be there and useful throughout these stages.

Ross: That's correct. What happens is that in stage one you don't think a lot about architecture. If you don’t think at all, you are going to regret it. But you just can't predict what are going to be the critical capabilities in your organization. When you can't predict the critical capabilities in your organization, it limits how much you can architect.

You can bet on some things. There are some things around finance and HR that are pretty predictable even in stage one. But that early stage is where you're really defining yourself as a company, and that can last for some years, as you grow. As long as you're under $500 million in sales or at least, let's say, $200 million in sales, you've got some leverage there, because you can only create so big of a mess.

The Open Group is great for me, because there is so much serious thinking in The Open Group about what architecture is, how it adds value, and how we do it well.

If you start growing beyond that, you're going to need more architecture. That’s when you really get into stage two and start seriously defining your standards and the processes that enable you to get them in and recognize when you need exceptions and when they're out of date and that kind of thing.

Gardner: So even as we have had this evolution in these stages that happen within these enterprises, we have also had historical evolution in the definition, standardization, and certification around the architects themselves. Where are we there? Is there a stage three or four that we are at with the architects?

Ross: I think we'll be constantly tweaking the certification processes for architects. We get smarter about what they need to know and what they need to be good at, but I don’t know that I would so much call it stages for the architect certification as just getting smarter and smarter about what great architects will excel at. We have the basics in place. I haven't been involved a lot in certification programs, but I think there is a good sense of the basics that are required.

Gardner: We certainly seem to be well into a professionalization phase and we've got a number of different groups within The Open Group that are working on that across different disciplines. So I'm curious. Is The Open Group a good forum for your message and your research, and if so, why?

Ross: The Open Group is great for me, because there is so much serious thinking in The Open Group about what architecture is, how it adds value, and how we do it well. For me to touch base with people in The Open Group is really valuable, and for me to touch base to share my research and hear the push back, the debate, or the value add is perfect, because these are people who are living it every day.

Major themes

Gardner: Are there any other major themes that you'll be discussing at the conference coming up that you might want to share with us? Did we cover them all? What did we leave out?

Ross: Well, we're still doing the analysis on our latest survey. So I'm not exactly sure what the key findings will be that I'll be sharing. One thing we have observed in our cases that is more and more important to architects is that the companies are struggling more than we realized with using their platforms well.

I'm not sure that architects or people in IT always see this. You build something that’s phenomenally good and appropriate for the business and then you just assume, that if you give them a little training, they'll use it well.

That’s actually been a remarkable struggle for organizations. One of our research projects right now is called "Working Smarter on Your Digitized Platform." When we go out, we find there aren't very many companies that have come anywhere close to leveraging their platforms the way they might have imagined and certainly the way an architect would have imagined.

It's harder than we thought. It requires persistent coaching. It's not about training, but persistent coaching. It requires enormous clarity of what the organization is trying to do, and organizations change fast. Clarity is a lot harder to achieve than we think it ought to be.

We find there aren't very many companies that have come anywhere close to leveraging their platforms the way they might have imagined and certainly the way an architect would have imagined.

The message for architects would be: here you are trying to get really good at being a great architect. To add value to your organization, you actually have to understand one more thing: how effectively are people in your company adopting the capabilities and leveraging them effectively? At some point, the value add of the architecture is diminished by the fact that people don't get it. They don’t understand what they should be able to do.

We're going to see architects spending a little more time understanding what their leadership is capable of and what capabilities they'll be able to leverage in the organization, as opposed to which on a rational basis seem like a really good idea.

We've been studying companies, and the easiest ones to study are ones like 7-Eleven Japan and Protection One, which is a security company. These are companies that have replicated models. You look at one branch or one store and you say, "How are you doing this?" Then you say, "Okay, here is the best one. How are we going to make sure that everybody uses our technology and the information that's coming from it? How are we going to do that throughout the company?"

That’s even harder than designing and implementing an architecture. Architects are going to have to be well aware of that, because if companies are not driving value from what they have built, you may as well stop spending the money. That’s a tough thing for an architect to admit, because there’s so much you can do just on a rational basis to make the company look better. But if they are not using it, it's not worth anything.

Gardner: That might explain some of the attention that’s been given to things like cloud and mobile, because there is a sense of an organic adoption going on, and if the workers, the managers, the departments, specific functional groups like marketing, for example, are going to SaaS, cloud, mobile for "bring your own device," or consumerization of IT benefits, perhaps there's an opportunity to take advantage of that, learn from it, and then standardize it and implement as a platform. Is that somewhere close to what you are seeing?

Ross: Yes, absolutely.

Getting started

Gardner: Before we segue out, let's consider advice about getting started. When you're an organization and you've decided that you do want to be a level three or four maturity, that you want to transform and take advantage of unique opportunities for either technical disruption or market discipline, how do you go about getting more structure, more of an architecture?

Ross: That's idiosyncratic to some extent, because in your dream world, what happens is that the CEO announces, "This is what we are going to be five years from now. This is how we are going to operate and I expect everyone to get on board." The vision is clear and the commitment is clear. Then the architects can just say, and most architects are totally capable of this, "Oh, well then, here are the capabilities we need to build. Let’s just go build them and then we'll live happily ever after."

The problem is that’s rarely the way you get to start. Invariably, the CEO is looking at the need for some acquisitions, some new markets, and all kinds of pressures. The last thing you're getting is some clarity around the vision of an operating model that would define your critical architectural capabilities.

What ends up happening instead is architects recognize key business leaders who understand the need for, reused standardization, process discipline, whatever it is, and they're very pragmatic about it. They say, "What do you need here to develop an enterprise view of the customer, or what’s limiting your ability to move into the next market?"

And they have to pragmatically develop what the organization can use, as opposed to defining the organizational vision and then the big picture view of the enterprise architecture.

When they see real demand and real leadership around certain enterprise capabilities, they focus their attention on addressing those.

So in practice, it's a much more pragmatic process than what we would imagine when we, for example, write books on how to do enterprise architecture. The best architects are listening very hard to who is asking for what kind of capability. When they see real demand and real leadership around certain enterprise capabilities, they focus their attention on addressing those, in the context of what they realize will be a bigger picture over time.

They can already see the unfolding bigger picture, but there’s no management commitment yet. So they stick to the capabilities that they are confident the organization will use. That’s the way they get the momentum to build. That is more art than science and it really distinguishes the most successful architects.

Gardner: We'll be looking forward to learning more through your research and through the examples that you provide.

We've been talking with Jeanne Ross, the Director and Principal Research Scientist at the MIT Center for Information Systems Research. Jeanne and I have been exploring how enterprise architects have helped lead the way to successful business transformations as a lead-in to her upcoming Open Group presentation.

This special BriefingsDirect discussion comes to you in conjunction with The Open Group’s Conference, which is January 30 to February 3 in San Francisco. You'll hear more from Jeanne and many other global leaders on the ways that IT and enterprise architecture support enterprise transformation.

So thank you, Jeanne, for joining us in this fascinating discussion. I really had a good time.

Ross: Thanks so much, Dana, I enjoyed it.

Gardner: And I look forward to your presentation in San Francisco and I encourage our listeners and readers to attend the conference, if they're able. There’s more information available on our website and through this content.

This is Dana Gardner, Principal Analyst at Interarbor Solutions, your host and moderator throughout this Thought Leader Interview Series. Thanks again for listening, and come back next time.

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

Transcript of a BriefingsDirect podcast in conjunction with The Open Group Conference in San Francisco on how enterprise architecture can lead to greater efficiency and agility. Copyright Interarbor Solutions, LLC, 2005-2012. All rights reserved.

Register for The Open Group Conference
Jan. 30 - Feb. 3 in San Francisco.

You may also be interested in:

• Overlapping Criminal and State Threats Pose Growing Cyber Security Threat to Global Internet Commerce, Says Open Group Conference Speaker
  
• Exploring Business-IT Alignment: A 20-Year Struggle Culminating in the Role and Impact of Business Architecture
• Enterprise Architects Increasingly Leverage Advanced TOGAF 9 for Innovation, Market Response, and Governance Benefits
• Open Group Cloud Panel Forecasts Cloud s Spurring Useful Transition Phase for Enterprise Architecture
• The Open Group's Cloud Work Group Advances Understanding of Cloud-Use Benefits for Enterprises
• Exploring the Role and Impact of the Open Trusted Technology Forum to Ensure Secure IT Products in Global Supply Chains