Showing posts with label SOA. Show all posts
Showing posts with label SOA. Show all posts

Friday, July 29, 2011

Discover Case Study: How IHG Has Deployed and Benefited from Increased App Testing

Transcript of a BriefingsDirect podcast from the HP Discover conference on how InterContinental Hotels Group has reduced time and cost in app development.

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

Dana Gardner: Hello, and welcome to a special BriefingsDirect podcast from the recent HP Discover 2011 conference in Las Vegas. We're here to explore some major enterprise IT solution trends and innovations making news across HP’s ecosystem of customers, partners, and developers.

I'm Dana Gardner, Principal Analyst at Interarbor Solutions, and I'll be your host throughout this series of HP-sponsored Discover live discussions.

Our latest user case study focuses on InterContinental Hotels Group (IHG). We're going to be looking at what they are doing around automation and unification of applications, development and deployment, specifically looking at software as a service (SaaS) as a benefit, and how unification helps bring together performance, but also reduce complexity costs over time.

To help guide us through this use-case, we're here with Brooks Solomon, Manager of Test Automation at InterContinental. Welcome to BriefingsDirect.

Brooks Solomon: Thank you, Dana. Pleasure to be here.

Gardner: Give me a sense of the scope and size of your operations?

Solomon: InterContinental Hotels Group is the largest hotel company by number of rooms. We have 645,000 rooms, 4,400 hotels, with seven different brands, and the largest and first hotel loyalty program with 58 million members.

The majority of the hotels, 3,500 or so, are in the US and the others are distributed around the world. We're going to be expanding to China more and more over the next few years.

Gardner: How about in terms of numbers of applications and scope and size of your IT operations?

Solomon: I couldn’t list the number of applications we have. The majority of the revenue comes from four major applications that are consumer-facing

Gardner: What were the high-level takeaways from your presentation at Discover?

Solomon: We use HP’s testing software all the way from Quality Center (QC), through Quick Test Professional (QTP), through LoadRunner, up into the Business Availability Center (BAC) tool. I've talked about how we get to the process of BAC and then how BAC benefits us from a global perspective.

I couldn’t list the number of applications we have. The majority of the revenue comes from four major applications that are consumer-facing.



Gardner: Let’s get into that a little bit. Obviously, reservations, rewards, customer-facing web, and self-service type of functionality are super-important to you. Give us a sense of what you're doing with those sorts of apps and how critical they really are for you?

Solomon: The apps that we generate support the majority of IHG’s revenue and, if they're not customer-facing, they're a call-center application. If you call 1-800 Holiday Inn, that kind of thing, you'll get a reservation agent somewhere around the world wherever you are. Then, that agent will actually tap into another application that we developed to generate the reservation from there.

Gardner: A lot of test and development organizations have been early adopters of SaaS and cloud functionality. What’s the breakdown with your use of products? Do you have an on-premise portion or percentage in SaaS? How does that break down for you?

SaaS monitors

Solomon: We use SaaS and we have a private use of SaaS. Going back to our call-center applications, there are local centers around the world, and we've installed SaaS monitors at those facilities. Not only do we get a sense of how the agent’s response time and availability is from their centers, we also get a full global view from customers and how their experience is, wherever they maybe.

Gardner: In terms of your developers, your testing, and your application life-cycle to what degree are the tools that you're using SaaS-based?

Solomon: Right now the only SaaS-based tool we have is the BAC. The other HP tools that we use are in-house.

Gardner: When you move toward lifecycle benefits, do you have any sense of what that’s done for you, either at a cost and efficiency level within IT, or most importantly, at the customer level in terms of satisfaction and trust?

Solomon: Without the automated suite of tools that we have, we couldn’t deliver our products in a timely fashion and with quality. We have an aggressive release schedule every two weeks, distributing new products, new applications, or bug fixes for things that have occurred. Without the automated regression suite of tools that we have, we couldn’t get those out in time. Having those tools in place allows us approximately a 75 percent reduction in cost.

Gardner: Having gone through this process, to move into that level of efficiency, do you have any 20/20 hindsight things that you may have done differently with that knowledge or that you might pass along as advice to our listeners?

Without the automated suite of tools that we have, we couldn’t deliver our products in a timely fashion and with quality.



Solomon: I would say just to define the core functionality of your applications and automate those first. Then, once new enhancements come along and there are business-critical type transactions, I would include those in your automated suite of tools and tests.

Gardner: How about your thoughts for the future? Do you have any purchases or acquisitions or tools you're looking to adopt in the future? Do you have a roadmap?

Solomon: We're coming off of a mainframe reservation system and we are converting that into service oriented architecture (SOA). So, we’ve recently purchased HP service tests. We hope that acquisition would help us automate all of our services coming off the mainframe. We're going to do that on a gradual basis. So, we're going to be automating those as they come online.

Gardner: Very good. We've been talking about application lifecycle management and productivity. Our guest has been Brooks Solomon, Manager of Test Automation at InterContinental Hotels Group, based in Atlanta.

Thanks to our audience for joining this special BriefingsDirect podcast, coming to you from the HP Discover 2011 Conference in Las Vegas.

I'm Dana Gardner, Principal Analyst at Interarbor Solutions, your host for this series of user experience discussions. Thanks again for listening, and come back next time.

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

Transcript of a BriefingsDirect podcast from the HP Discover conference on how InterContinental Hotel Group has reduced time and cost in app development. Copyright Interarbor Solutions, LLC, 2005-2011. All rights reserved.

You may also be interested in:

Tuesday, August 03, 2010

Harvard Medical School Use of Cloud Computing Provides Harbinger for New IT Business Value, Open Group Panel Finds

Transcript of a sponsored podcast discussion from The Open Group's Boston Cloud Practitioners Conference on gaining business paybacks from cloud computing.

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

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, we present a sponsored podcast discussion on the business impact of cloud computing, coming to you from The Open Group Conference in Boston, the week of July 19, 2010.

We've put together a distinguished panel to explore practical implementations of cloud-computing models, and of moving beyond the hype and into the business paybacks from proper cloud adoption.

We'll tackle such issues as what stands in the way, safe and low-risk cloud computing, and what seems to be inhibiting IT leaders and/or business leaders as they seek to reduce the risk and exposure of their ongoing cloud efforts. We're also going to delve into a compelling example of successful cloud practices at the Harvard Medical School.

Here to help us better understand these best practices and proper precautionary steps on the road to cloud implementations that provide practical business improvements is our panel: Pam Isom, Senior Certified Executive IT Architect at IBM; Mark Skilton, Global Director, Applications Outsourcing at Capgemini; Dr. Marcos Athanasoulis, Director of Research Information Technology for Harvard Medical School, and Henry Peyret, Principal Analyst at Forrester Research.

Let me take my first question to you, Mark Skilton. I enjoyed your presentation earlier. The whole wellspring of interest, I might even say hype, in cloud computing wouldn’t happen if there wasn’t some dissatisfaction with the status quo. From your perspective, now that we have moved a little bit through a hype cycle with cloud computing, what are the resilient dissatisfaction elements of the status quo that are leading to a continued interest in cloud computing?

Mark Skilton: Thanks, Dana. I've answered this question a number of times before. What I typically say to people is that there are probably three areas that are persistent or continuing into the post-initial hype of the cloud -- I'm not saying Cloud 2.0 just yet.

There's the resilience of utility computing, the on-demand storage or the self-service component of computing. We're starting to see utility computing becoming much more common mainstream, so that it’s no longer a fad or an alternative to mainstream. We're seeing that sort of consistency.

To answer your question quickly, we're also seeing software as a service (SaaS), due to the economic conditions, taken quite seriously now, particularly targeted at specific business processes that we spoke of earlier, but also starting to become potentially more mainstream. Clearly, with Salesforce.com and others like that, we are seeing that starting to accelerate.

Different app store

The third one is a different type of app store. We're seeing application stores, particularly through the federal sector and government, to some extent in telecoms, and even in academic circles. We're seeing this idea that you certify into a catalog.

Gardner: Pam Isom, do you see a difference between the interest from the business leaders and the IT leaders, and why would that differ?

Pam Isom: From a business leadership and an IT leadership perspective, based on my customer experiences, I would say that it’s about the same. There is a tendency for IT leaders to want to share their capabilities. Business leaders just want to get the problem resolved -- tell us what you can do to fix our problems. They don’t specifically go out and request cloud, but there's a need for a business performance improvement, which leads to cloud enablement.

As far as what’s driving cloud as a solutions strategy is the need to improve business performance. If we can get solutions that will help drive business performance and business sustainability, the cloud is a good place for that.

Gardner: Henry, from your research and from some of my observations, do you share with me this notion that the business seems to be selling cloud computing to the IT department, and in only some cases the IT department is selling cloud computing to the business? What’s up with that?

Henry Peyret: That’s a good point, and I agree. Sometimes, when the business is trying to sell cloud computing, and IT is not really prepared to do that, they say no. They find tons of reasons to never go to the cloud.

The same also happens on the other side. Sometimes, IT is selling the cloud approach, and the business says, "No, I don’t want to take the risk. I have heard a lot about cloud, and I don’t want to take the risk."

The supposition is not so easy at the moment, but from an enterprise architect (EA) point of view, we should prepare for that. We should prepare to determine what are the elements that can migrate to the cloud, different types of cloud. Then, we should try to evangelize. The EA should be in between business and IT. That’s a good place to make a right choice and mitigate risks and choices.

Gardner: Of course, we've been talking for decades about alignment between IT and business. Do you think that cloud and the concept of cloud provides common ground for IT and business in a way that perhaps we hadn’t seen before? First to you Henry.

Wrong approach

Peyret: I don’t like to talk about IT and business alignment, I think that’s a bad approach. We should be in-sync. That means that every time the business changes, we should be prepared to be in-sync with the same thing.

We see the business changing faster than previously. So being aligned, you're always late, rather than being in-sync. That means that we should be able to anticipate where the competitors are going, and then we should propose several things to help the business at that point. Then, when the business is coming up, we should try to help. That’s where cloud is offering options, scenarios, and other choices to help existing or future problems.

Gardner: Pam, do you have a different outlook on what this common ground, the cloud, can provide?

Isom: You can’t produce cloud solutions in a vacuum. You won’t get any consumers. So, it’s a great venue for cloud providers to work with business stakeholders to explain and explore opportunities for valuable services.

Gardner: Mark, we've heard from several different speakers today that this notion of business process is where the cloud will pay off in the future. Even business process as a service has been raised. Does that provide the common ground? Maybe it’s not so much the delivery model of the cloud, but the fact that you focus on the process rather than systems or even applications?

Skilton: The fact that you are publishing this as a podcast and also there are people in this room probably doing Twitters and things, I think the cloud is already a common ground in a social sense. So, it's slow car crash, just waiting to happen. You've got to manage the situation with that. It’s already here, guys.

I'm very interested to hear from the business customers' perspective how cultural impact and change affects how that might need to accelerate into business adoption.

We're seeing two types of clouds: a social cloud, social networking, and also the business cloud, which is still forming in front of our eyes. It's less clear to know which direction that will go. The cultural and the consumer dynamics will drive that internally.

Gardner: Marcos, please tell us about your use-case and how cloud computing has been adopted at Harvard Medical School. Then, we'll also look to find out whether there was commonality there, or who was selling to whom.

Dr. Marcos Athanasoulis: Thank you. I'm delighted to be here. The business of Harvard Medical School is research, and this is true of course in big pharma and other organizations that are engaged in research. Similar to many industries, there is a culture that requires that for IT to be successful, it has to be meeting the needs of the users.

We have a particularly interesting situation. I call Harvard Medical School the land of a thousand CIOs, because, in essence, we cannot mandate that anyone use central IT services, cloud services, or other things. So that sets a higher standard for us, because people have to want to use it. It has to be cost-effective and it has to meet their business, research objectives.

We set out about five years ago to start thinking about how to provide infrastructure. Over time, we've evolved into creating a cloud that's a private cloud at the medical school.

User participation

P
erhaps we'll touch on a little later some of the unique characteristics of biomedical research that have some particular constraints on the public cloud. But, we've been able to put in place a cloud that, number one, has user participation. This means that the faculty have and the researchers have skin in the game.

They can use the resources that are made available and subsidized by the school, but if they need additional resources, additional computing power, they're able to buy it. They actually purchase nodes that go into the cloud and they own those nodes, but when those notes are idle, other people's work can run on it. So they buy into the cloud.

These folks are not very trusting of central IT organizations. Many of them want to do their own thing. In order to get them to be convinced that they ought to participate, we told them, "You buy equipment and, if it doesn't work out for you, you can take that equipment and put it under the bench in your lab and set it up how you want." That made them more comfortable. But, not a single time has anyone ever actually come back and said they were going to take back the equipment.

In essence, it's building the trust of the researchers or the business clients, if you're in more of a business environment, getting them engaged in their requirements, and making sure it will meet their needs.

Of course, the real value of the cloud for us is handling the burstiness of research. Various organizations have different levels of "burstiness," meaning sometimes a project might suddenly need thousands of hours of CPU time. It might need additional bursts of storage and things like that. So, you need to have a cloud that can adapt to those needs.

This actually worked out well for us. It was cost effective, we got to utilize a whole range of services within the cloud, and that allowed us to move forward.



Gardner: Was there a common-ground effect, where you provided a certain services, saw adoption patterns, and responded to that? Did you see a dance between the consumers and the providers in cloud that may have been different than previous modes of IT?

Athanasoulis: Dance is a great way of describing it, because you take the first step with your partners, the ones who are early adopters and want to try it out, and then they talk to their colleagues and say, "This actually worked out well for us. It was cost-effective, we got to utilize a whole range of services within the cloud, and that allowed us to move forward."

Skilton: It's interesting about the dance, but I think one of the things I am seeing is an incremental revelation, or do you have to have a critical mass? I'm assuming you must have had some kind of critical number of people to cost-justify the boot of the cloud. In the ideal world, the one to many or just starting off with one or two people and growing incrementally, financially that's not usually possible. How did you get around that?

Athanasoulis: We really started out by saying to the senior business leaders within the school -- the deans and the others -- "To keep Harvard Medical School as the number-one preeminent medical school in the country, we're going to have to invest a little money, because these folks out there are not just going to adopt this, if they can't see that there is already some utility to it."

So we started out with a relatively small cloud initially. Once people saw the value, they began to adopt it more, and it's really starting to have a snowball effect, where we are growing by orders of magnitude.

Gardner: Henry?

Peyret: In the bio business, before the cloud was formed, there was grid. Do you think that was key to bring some credibility to your approach, for some researchers and for some business users?

Personal relationship

Athanasoulis: Absolutely. Personal relationship is a part of what it's about. We had to make sure that we weren't seen as just a black box that they had absolutely no control over. That was step number one.

Then we also had to make sure that it was very much of an iterative process. We would start with one folk's needs and then realize there were certain other needs.

Of course, within the biomedical sphere, as I alluded to earlier, there are some unique things. There are certain types of data, protected health information, that you simply have to make sure is protected.

There are things like the Health Insurance Portability and Accountability Act (HIPAA) that requires that health data is protected in certain ways. A lot of extra concerns come into play within the biomedical area.

Gardner: Hearing this sounds as if that iterative approach, the dance effect, is a strong selling point in taking cloud into an organization that's been used to two- to three-year year upgrade cycles, six- to 12-month cycles for the processing of requirements, development, test, deploy, re-requirements, and so forth. Perhaps, cloud allows for agile development and Scrum benefits but for the rest of us?.

It's a subtle difference, but it's one that is fundamentally changing the way you would offer an incrementalized service as opposed to more of a clunky, project-based, traditional waterfall approach.



Athanasoulis:
This is true not only in the cloud, but it's true across the whole information technology industry. People are moving from the giant project, two- to three-year implementation cycles to, "Let's take a chunk, see how it works, and then iterate and moderate along the way."

Gardner: Mark Skilton?

Skilton: One of the things we're also seeing is how it affects traditional application development life cycles. What's illustrated here is this need to move to more continuous-release or continuous-improvement type of life cycle. This is a transformation for IT, which may be typically more project-cycle based. It's a subtle difference, but it's one that is fundamentally changing the way you would offer an incrementalized service as opposed to more of a clunky, project-based, traditional waterfall approach.

Gardner: Pam Isom, wouldn't that be appealing to both the IT side of the house as well as the business? Is this that common ground we were looking for, that the iterative constant, more streamlined, but persistent approach is better than the fits and starts, for both sides?

Isom: I would think so, based on the experiences that I have had, I would say yes to that.

Gardner: It probably also allows us to bring in more metrics to measure the benefits. We have, of course, heard of soft, qualitative metrics like agility, but if we have this constant, iterative, step-by-step, crawl-walk-run, we might be able to apply metrics to each of those steps, rather than try to come up with a return on investment for a $40 million project.

Henry, do you have any thoughts about whether the metrics or measurement of success in a cloud-iterative approach will be of more use than some of the past approaches?

Key agility concept

Peyret: I am fundamentally against the fact that agility is a soft metric. I published in 2007 the key agility concept that we should use now. It's something that is quantitative, not qualitative. Believe me, we can define now what agility means at the business and the IT level, and then the cloud and additional technologies, including joint development. But, that's not the same part of agility that I am talking about, which can help to provide some agility as a business.

Even IBM endorsed that one or two years ago for demonstrating SOA and that sort of thing. They collected more than 300 key agility indicators for 22 or 27 types of industries. So, that's interesting.

Just to come back to your point, yes, there are some new metrics, and there would be more and more metrics about that. We talked a lot about the aspect of cost and that sort of thing. There is a big shift after Copenhagen. Most of the enterprises now are endorsing the three bottom line approach. They are reporting not only on the finance aspect, but also on risks. If banks had done that before, we would not be in the subprime problem.

And, the third one, which is about sustainable business. Because of sustainable business requirements, we will measure additional metrics, and the cloud should share additional metrics as well. The more we are involved with some cloud systems in your information systems, the more they should share what type of pollution they are providing and what type of consumption they are doing to include that into the three bottom-line metrics that your CEO would require from you.

Gardner: Let's see how this works in practice. Marcos, did you feel that, on the IT side, you had an easier time validating your efforts, demonstrating the value through some of the cloud activities, as compared to earlier modes of delivery?

Come on and try it out. If it doesn’t work for you, so be it, but you also have demonstrated successes that people can point to.



Athanasoulis: Absolutely. It's always easier to show someone something that's already working and say, "Do you want to hop onto this bus" than to say, "We're going to build this great new giant infrastructure, and just trust us, it's going to work great. So, hop on board now, before anyone has even seen it or tried it out." It's having the ability to let people walk before they run. Come on and try it out. If it doesn’t work for you, so be it, but you also have demonstrated successes that people can point to.

Gardner: I imagine this has to be a two-way street. Where is the point in the middle, between the discussion of value on the business side and the IT side, is that something that the CIO does or the architect? Where did you see, in terms of the politics or the organization? Where was that discussion translated?

Athanasoulis: It's complicated, because the discussion happens everywhere, from in the cafeteria, to meetings with faculty, and in one-on-one communications. Obviously, the CIO is instrumental.

The CIO at Harvard Medical School, John Halamka, had the vision to start this. It started with his initial vision and going to bat to move from everyone from doing their own thing and setting up their own infrastructure, to creating a cloud that will actually work for people.

He had the foresight to say, "Let's try this out." He went to his leadership, the dean and others and said, "Yes, we're taking a chance. We're going to spend some money. We're not going to spend a huge amount of money until we prove the model, but we're going to have to put some money in and see how this works." It was a very interesting communication game.

Gardner: Henry, where does the enterprise architect fit into this dance of value between consumption and provider?

Business service catalog

Peyret: The EA should participate to establish and negotiate what I call the business service catalog, something that will be an extension of the ITIL service catalog, which is very IT-based and IT-defined.

Something that is missing currently within ITIL V3 is how to deal with the business to define the service and define also the contract in terms of cost and of service level agreement (SLA). But, it's not only the SLA. It's broader than that. That's something that's missing at the moment. Most of the EAs are not participating in that.

I have built a sort of maturity model, and I discovered that the EA to deliver a project on time, which is the sort of next point for the EA, should work on the definition of business service catalog.

That's what I wanted to ask to Marcos. Is that something that you're dealing with today, trying, at least at the beginning, to define the service at a business level?

Athanasoulis: Yes. Defining the service with the users is the first clear step, and obviously getting the requirements from the users, particularly in an organization like our medical school, where they have choices and they don’t have to use the systems.

We have people who want to just come in and put in systems, buy a rack of stuff and put it under the lab bench, and then they are surprised when the power and cooling isn’t there to meet the requirement.



Various industries have a different IT maturity level. Unfortunately, Harvard Medical School actually is rather at the bottom of that from a user point of view, because most of the people are trained in life sciences and know absolutely nothing about best practices in IT.

So, we have people who write software, but have never heard of source control. And, we have people who want to just come in and put in systems, buy a rack of stuff and put it under the lab bench, and then they are surprised when the power and cooling isn’t there to meet the requirements.

So, having this balance of bringing in an IT specialist, the enterprise architect, to define the requirements in joint-step -- back to the dance with the customers -- was really what allowed us to be successful.

Gardner: While you're a unique organization, it sounds as if you might be a harbinger for the future. You are talking about a marketplace of services that you allow your users to shop from. That strikes me as something that will be a valuable tool for discerning where the traction is, both in terms of the technology capabilities, but where the human behavioral factors kick in, and even group factors and socialization.

Is that marketplace something that you think will become more the norm, and this is open to our panel? Traditionally, IT has been ... "Here are the marching orders, here are the apps, here are the methods, here is the data, here is the processes, now march." If we give people, vis-à-vis cloud approaches, more choice, wouldn’t that build trust, wouldn't that give us a chance to discern where the real interests are? Let’s hear about a marketplace approach from cloud computing, Mark.

A new question

Skilton: In a nutshell, what we are seeing with clients now is that they are over the initial infrastructure as a service (IaaS), platform as a service (PaaS), SaaS, and business process as a service-sort of conversation. They're now asking, "What cloud services do you do?"

What they mean by that is that they need to see your cloud security reference model. They need to see your cloud services model. They need to understand the type of services that you can offer into a portfolio and then the types of service catalogs that you can interact with them.

They then make a decision. Does that need to be on-premise, can it be out in the cloud, or is there something as a hybrid? They're on that page now, and there is a strategic planning process starting to evolve around that. So, yes, I'd concur that we do need to do that.

Gardner: Pam, what about a market basket of services that constitutes processes that aren’t necessarily locked into processes to begin with, but are delivered to the market to let them exercise the choice?

Isom: Based on what I've seen and experienced with customers, the catalog of services would be great. I think we need to be careful about that catalog of services, so that it doesn’t become too standardized.

We need to be careful with the catalog of services that we offer, but I definitely think that it is a new way of thinking, when it comes to the role and capacity of IT.



As I mentioned earlier today in one of my presentations, you want to be careful with that standardization, because you do want to give people some flexibility, but you need to manage that flexibility. So, you need to be careful. We need to be careful with the catalog of services that we offer, but I definitely think that it is a new way of thinking, when it comes to the role and capacity of IT.

It’s a new way of thinking, because along with that comes service management. You can't just think about offering the services. Can you really back up what you offer? So, it does introduce more thinking along those lines.

I want to go back to your question earlier about the iterative approach, and then you asked about the enterprise architect. If we tie those two together, the enterprise architect would be the one who would provide that enterprise view and make sure that anything that we do is thought out from a holistic perspective, even though we may actually start practicing on a smaller scale or for a smaller domain.

A good practice would be to involve the enterprise architect, even though we may start with a specific domain for implementing the cloud, because you've got to keep your eye on the strategic vision of the company.

Gardner: Henry, we started talking about cloud, but then we got into service catalogs. It almost sounds like the service oriented architecture (SOA) route. How do those come together in your thinking?

Peyret: The business service catalog is the next step. We have heard in enterprise architecture about business capabilities. We talked about that business capabilities to help develop business architecture.

A missing link

W
e have also heard SOA. There is a missing link in between -- the business service catalog. It's a way we will contractualize. I like very much the fact that you said, we are contractualizing, but with flexibility. We should manage that flexibility. We should predict what that flexibility means in terms of impact. Perhaps that service is not valuable for other parts of the company.

That's where I think that EA and the next step for EA will take place. SOA is not an end, and the next step will be the business service catalog, which we will develop to link to the business capabilities.

Gardner: Mark Skilton?

Skilton: I concur with that, and I am also detecting at this conference and some of the work we're doing in The Open Group that there are worries around the risks of achieving the catalog flexibility. I agree. You're absolutely right. The portfolio needs to be put in place, but it also needs another set of service management investment tools to control data distribution, compliance, or access and security control, and things like that.

I detect a worry about whether I can outsource that. Do I need to do something in-house? What do I need to spend money on? Because that's a block, and people need to understand that.

Gardner: Let's go to our harbinger of the future, the Harvard Medical School here in Boston. What did you do to prevent the rewards from outstripping the risk, that is to say spinning out of control?

You don't want to sell something to everyone and then find six months into it that you're way oversubscribed and everyone is bitter and unhappy, because there isn't the capability that they expected.



Athanasoulis: Again, starting small. To build on what my colleague was saying, you want to iterate and you have to have a vision of where you are going.

If you're taking a car trip and you're going to drive from here to Ohio tomorrow, we know where we're going, we have our map, we start to drive, but we might along the way find, that the highway is clogged with traffic. So, we're going to go around over here, or we are going to take a detour.

Perhaps, somewhere along the way you say, "You know what, now that we have been learning more, Ohio isn't really where we wanted to go. We actually want to keep on going. We're heading right out to Colorado, wherever it may be." But, you have to have a vision of where you are going.

Then, to keep things from spinning out of control along the way, it's really important to know the potential factors that might lead to things starting to fall apart or fray at the edges. How do you monitor that you have the right capacity in place? You don't want to sell something to everyone and then find six months into it that you're way oversubscribed and everyone is bitter and unhappy, because there isn't the capability that they expected.

You have to also make sure to check in with folks along the way a lot. Part of my MO of dealing with a wide set of customers is constant contact with them. I'm always checking in because, as IT leaders, we know that you don't usually hear when things are going well. You usually only hear when things are going poorly. And, even then, you don't always hear when things are going poorly. You have to make sure to get that feedback, because people will just drop off and go find some other way to get done what they need to get done.

Gardner: To continue with our dance metaphor, you don't just drop them off at the dance. You have to stay with them.

Athanasoulis: That's right.

Gardner: Let's look a little bit at the public and private divide issue. We have heard public cloud, private cloud. What do you use, and do you make a distinction around public and private cloud?

Now a marketplace

Athanasoulis: I think it makes clear sense. To some degree, as IT leaders, we all know that there is now a marketplace. The public cloud is available to folks. People can get on Amazon EC2. They can get on to these various clouds and they can start to use them. That forces us to have compelling cloud offerings that are more cost effective than what they can go get out in the public sector.

For us, when you set aside the issues of protected health information and HIPAA and other things like that, there’s plenty of research and business processes that don’t have those security concerns. We view the public cloud as an extension of the private cloud to the degree that there is consistency of virtual machine definitions and to the degree that we can make a node on the public cloud look exactly like a node on the private cloud and make the same databases available there.

If someone has the money, they want the capabilities, say 10,000 processor hours or 100,000 processor hours, whatever it might be, between now and this deadline three weeks from now, and they are willing to spend the money, wouldn’t it be great if transparent to them, they just spend up to $100,000, $200,000, whatever their budget is, and let this stuff go from our private cloud out to the public cloud. What a great solution that would be for folks.

Gardner: Mark Skilton, is it the role of the enterprise architect to be the arbiter of public and private? It sounds like in Marcos’s case there is a bit of self-selection and being driven by the users. I think that’s a bit unique to that type of organization. Isn’t there going to be a traffic cop of some sort to then allow for these services to be used, but with the acceptable level of risk, and so doesn’t the role of IT shift from providing IT to brokering IT services?

Skilton: It’s a funny dimension I have come across, where you have the purchasing or the procurement department having procurements and license strategies and license agreements that could be within a particular business or across a number of businesses, and it could be related to a country or a company or a collection of companies or countries.

It’s not the role of the EA to make the choice. That’s the role of IT, responsible to the CIO.



It was an interesting point Marcos made earlier about needing not only a vision, but articulating the vision as a roadmap. What I think you're inferring is almost like a technology and purchasing roadmap.

I often ask how often an enterprise architect bothers to find out what’s in the data center, when they go ahead and do development? There's probably a new style of communication, that maybe not the enterprise architect, but the architecture department, the AMO or the PMO, start to put out a service briefing about what they can do.

Just a very quick story. In Australia, a couple of years ago, I was over in BHP Billiton, a major, massive mining operation. I always remember the CTO there looking me in the eye and saying, "Do we need requirements from users, because all I have to do is put out a catalog and make them buy off that?" He was being candid with the whole process. Perhaps we are not there yet, but instead of this mentality of design to order, we need to move more to assemble to order, or made to stock.

Peyret: Can I answer your first question? I would be provocative about that. For me, it’s not the role of the EA to make the choice. That’s the role of IT, responsible to the CIO, to say yes or no, I would like to deliver that service internally or not internally, that’s part of my service delivery. If you want to be seen as a service delivery within your company, you should act as a business person saying, "Yes, I want to keep that service internally or I want that service to be delivered externally."

Final decision

Yes, the EA can help. Yes, the EA can participate through the gateway that I talked about previously. Yes, the EA can be instrumental to know if it makes sense to have that service at that point and that sort of thing. But, the final decision is not in the EA space.

Gardner: Okay. Coming back full circle to our goal here of uncovering ways to better take, sell, or bring cloud computing to the business side of the house. ... We have talked about that role of broker that Marcos and Mark discussed a bit: procurement, contracts, agreements. These are terms that the business side understands, more so than enterprise service bus (ESB), Agile, and Scrum. Is there a commonality there, where IT becomes something as a business function that the business leaders, those with the purse strings, can better understand?

Isom: Just from my experiences and customer interactions, the IT department should be more focused now on providing information technology as a service. It’s not just a cloud figure of speech. They are truly looking at providing their capabilities as a service and looking at it from an end-to-end perspective.

That includes that service catalog and includes some of the things you were talking about, how to make it easier for consumers to actually consume the services, and also making sure that the services that they do provide will perform, knowing that the business consumers will go somewhere else if we don't. The services are just that available now. You really have to think about that. That shouldn’t be the driving force for us, providing IT as a service, but it should be a consideration.

The IT department should be more focused now on providing information technology as a service. It’s not just a cloud figure of speech.



Gardner: Let’s do a quick series of recommendations from each of our panelists. We'll start with you, Henry. One major recommendation you would make to the IT organization and the enterprise architects about convincing the others in the organization that cloud is a good thing.

Peyret: That’s not exactly the question I wanted to answer, but let me rephrase a little bit in my mind.

Gardner: Give it your best shot.

Peyret: What I wanted to recommend is that you should evangelize your IT person to act as an IT service. What does that mean? That means that you should recommend to them to contractualize their service, to express and establish, through the business service catalog, including some pricing aspects. Within the enterprise, where you have some funding and no problem about funding, you should contractualize. That’s absolutely key to make the adoption of cloud, any type of cloud, easier. That would be more or less transparent.

Gardner: Pam, I am going to rephrase the question. What are some recommendations you can make that both the IT and the business side of the house could agree on, when it comes to either cloud or the effects the cloud provokes in the organization?

Risk mitigation

Isom: I was having a conversation with someone earlier and we were talking about the fact that cloud can be a risk mitigator, and we're going to have some follow on conversation about that. If I think about how cloud can be a mitigator of some risk, I'll just name some of the risk that we discussed. We talked about how we can help mitigate the risk of losses in product, sales and services, because capabilities are now made faster. There is also that infrastructure to try things out. If you don’t like it, try something else, but that infrastructure is more readily adaptable with cloud.

Also, there's the fact that there is the mitigation of the proliferation of licenses and excess inventory that you have with respect to products, software, and things like that. We can help mitigate that with the cloud, with the pooling of licensing and things like that, so you can reach cloud from that respect.

Our discussion was around how to see cloud as a risk mitigator. I won't go into them all, but those are two examples.

Gardner: Great. Mark, same question.

Skilton: There is one lesson for the business side and one lesson for IT. From the business side, I would recommend to go out and look at best practices. Go and look at examples of where SaaS is already being used.

The number of case studies are growing by the month. So, for businesses, go out and learn about what's out there, because it is real. It’s not a cloud.



It constantly amazes me how many blue-chip Fortune 500 companies are already doing this.

From an IT point of view, as we have heard from Marcos, go and learn. Try it, pilot it in your organization. I'll go further and say, practice what you preach. Test it out on one of your own business processes.

From my own experience in my own company, we do use what we preach in the cloud. That way, you learn what it means internally to yourself to transform, and you can take that learning and build on it. You can't get it in a book. You can’t just read it. You have to do it. Those are the two key things.

Gardner: Last words, you Marcos.

Athanasoulis: I will think of four words that begin with P to describe where I would emphasize. One, pilot, as we have already been saying. Two, participation. You have to get buy-in and participation across the entire group. Three, obviously produce results. If you don’t produce results, then it’s not going anywhere. And then, promotion. At the end of the day, you also have to be out there promoting this service, being an advocate and an evangelist for it, and then, once the snowball gets going, there is no stopping it.

Gardner: Well, very good. We've been discussing the practical implications of cloud computing models, of moving beyond the hype and into business paybacks from cloud adoption.

This sponsored podcast discussion is coming to you from The Open Group Conference in Boston. We're here the week of July 19, 2010.

I'd like to thank our panelists: Pam Isom, Senior Certified, Executive IT Architect at IBM; Mark Skilton, Global Director of Applications Outsourcing for Capgemini; Dr. Marcos Athanasoulis, Director of Research Information Technology for the Harvard Medical School, and Henry Peyret, Principal Analyst, Forrester Research.

I'm Dana Gardner, Principal Analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect podcast. Thanks for joining, and come back next time.

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

Transcript of a sponsored podcast discussion from The Open Group's Boston Cloud Practitioners Conference on gaining business paybacks from cloud computing. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in:

Tuesday, May 04, 2010

Confluence of Global Trends Ups Ante for Improved IT Governance to Prevent Costly Business 'Glitches'

Transcript of a sponsored BriefingDirect podcast on the growing danger from faulty software and how to overcome it.

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

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 nature of, and some possible solutions for, a growing parade of enterprise-scale glitches. The headlines these days are full of big, embarrassing corporate and government "gotchas."

These complex snafus cost a ton of money, severely damage a company’s reputation, and most importantly, can hurt or even kill people.

From global auto recalls to bank failures, and the cyber crime that can uproot the private information from millions of users, the scale and damage that technology-accelerated glitches can inflict on businesses and individuals has probably never been higher. So what is at the root?

Is it a technology run amok problem, or a complexity spinning out of control issue -- and why is it seemingly worse now?

A new book is coming out this summer that explores the relationship between glitches and technology, specifically the role of software use and development in the era of cloud computing.

It turns out the role and impact of governance over people, process, and technology comes up again and again in the new book.

We have with us here today the author of the book as well as a software expert from IBM to delve into the causes and effects of glitches and how governance relates to the problem and fixes.

Please join me in welcoming our guests, Jeff Papows, President and CEO of WebLayers, and the author of Glitch: The Hidden Impact of Faulty Software. Welcome to the show, Jeff.

Jeff Papows: Thanks, Dana. Thanks for having us on.

Gardner: We're also here with Kerrie Holley, IBM fellow and Chief Technology Officer for IBM’s SOA Center of Excellence. Welcome to the show, Kerrie.

Kerrie Holley: Thank you, very much.

Gardner: Jeff, let me start with you. Now, the general trends around these complex issues are affecting business and probably affecting just about everyone’s lives. How do these seem to be something that’s different? Is there an inflection point? Is there something different now that 20 years ago in terms of the intersection of business with technology?

Papows: There is. I’ve done a lot of research in the past 10 months and what we're actually seeing is the confluence of three primary factors that are creating an information technology perfect storm of sorts. Some of these are obvious, but it’s the convergence of the three that’s creating problems on the scale that you are describing here.

The first is a loss of intellectual capital. For the first time in our careers -- the three of us have all been at this for a long time now -- we saw, between 2000 and 2007, the first drop in computer science graduates. That's the other side of the dot-com implosion.

Mainframe adoption patterns

While it’s not always popular or glamorous to talk about, 70 percent of the world’s critical infrastructure still runs on IBM mainframes. Yet, the focus of most of our new computer science graduates and early life professionals is on Java, XML, and the open and more modern development languages.

For the first time in our lifetimes and careers, the preponderance of that COBOL-based analytical community is retiring and/or -- God forbid -- aging and dying. That’s created a significant problem, concurrent with a time where the merger and consolidation activity -- the other side of the recession of 2008 -- have created this massive complexity in these giant mash-ups and critical back-office systems. For example, the mergers between Bank of America and Countrywide, and on and on.

The third factor is just the sheer ubiquity of the technological complexity curve. It’s the magnitude of technology that’s now part of our social fabric, whether it’s literally one million transistors that now exist for every human being on the planet or the six billion network devices that exist in the world today, all of which are accessing the same critical, in many cases, back-office structures.

It's reached the point, Dana, from a consumer standpoint, where 60 percent of the value of our automobiles now consists of networked electronic components -- not the drive trains, engines, and the other things. Look at the recent glitches you have seen at places like Toyota.

You take those three meta-level factors and put them together and we're making the morning broadcast news cycles now on a daily basis with, as you said, more and more of these embarrassing things coming to light. They're not just inconvenient, but there are monumental economic consequences -- and we're killing people.

Gardner: Kerrie Holley, we've looked at some of these issues -- society issues, organizational issues, and the technology behind them -- but technology has also been part of the solution or the ability to scale and manage and automate. I think service oriented architecture (SOA) has a major impact on that.

So, are we at a point where the ability of technology to keep up with the rate of growth is out of whack? What do you sense is behind some of this and why hasn't the technology been there to fix it along the way?

Holley: Jeff brought up some excellent points, which are spot-on. The other thing that we see is that we've had this growth of distributed computing. The easy stuff we've actually accomplished already.

If we look at a lot of what businesses are trying to accomplish today, whether it’s a new business model, differentiation, or whatever they're trying to do compete, what we are finding is that the complexity of that solution is pretty significant.

It's something that we obviously can do. If we look at a lot of technologies that are out in the market place, unfortunately, in many cases they are siloed. They repair or they help with a part of the problem, but perhaps they're not holistic in dealing with the whole life-cycle that is necessary to create some of this value.

Secondly -- this is a point-in-time statement -- we're seeing rapid improvements in the technology to solve this. With Jeff's company and other organizations, we are seeing that today. It hasn’t caught up, but I think it will. In summary, Jeff brought up several points in terms of the fact that we have ubiquitous devices and a tremendous amount of computing power. We have programming available to the masses. We have eight-year-olds, grandmothers, and everyone in between, writing software.

Connecting devices

We have a tremendous need to connect mobile devices and front-ends. We have 3D Internet. We just have an explosion of technologies that we have to integrate. Along with that comes some of the challenges in terms of how we make this agile, and how we make it such that it doesn't break. How do we make sure that we actually get the value propositions that we see? Clearly, SOA is a part of the solution, but it's certainly not the end-all in terms of how we repair and how we get better.

Gardner: One of the things that intrigues me about SOA is the emphasis on governance. To get the best out of a distributed services-orientation, you need to think at the very beginning and throughout the process about how to manage, automate, and reuse, as well as the feedback loops into the process -- all on an ongoing basis.

It strikes me that if that works for SOA, it probably also works for management and organizations, and it works for the relationship between workers and customers. Let me take this back to you, Jeff. Is governance also in catch-up mode? Do we have a sense of how to govern the technology, but not necessarily the process? Is that what's behind some of it?

Papows: You're right, Dana. There's a cultural maturation process here. Let's look at a couple of the broad economic planks that have affected how we got here, because I've been in the software industry for 30 years now. Remember that the average computer scientist, at least in North America, on average, makes 32 percent more than the mean average in the U.S. economy. And, software, computer services and infrastructure has accounted for about 37 percent of the growth in the gross domestic product in the United States and Asia in the last decade.

So the economic impact and success of our industry almost can’t be overstated. Because of that, we've grown up for decades now where we just threw more and more bodies at the problem, as
the technological curve grew.

All that means is automating those best practices and turning them inward, so that we’re governing ourselves as an industry the way that we would automate or govern many things.



There was always this never-ending economic rosy horizon, where you would just add more IT professionals and you would acquire and you’d merge systems, but rarely would you render
portions of those workforces redundant.

In 2008, the economic malaise that we’re managing our way through changed all of that. Now, the only way out of this complexity curve that we’ve created, to use Kerrie's terms, is turning the innovation that has been the hallmark of our industry back on ourselves.

That means automating and codifying all of the best practices and human capital that’s been in-place and learning for decades in the form of active policy management and inference engines in what we typically think of as SOA and design-time governance.

Really, all that means is automating those best practices and turning them inward, so that we’re governing ourselves as an industry in the same way that we would automate or govern many things. But now it’s no longer a "nice to have." I would argue that it’s critical, because the complexity curve and the economics have crossed and there is no way to put this genie back in the bottle. There is no way to go backward.

Gardner: Kerrie, any thoughts about what’s perhaps now a critical role for governance, perhaps governance up and down the technology spectrum, design time, runtime, but also governance in terms of how the people and processes come together?

Holley: Absolutely. One of the nice things that the attention to SOA has brought to our marketplace is the recognition that we do need to focus on governance. I don’t know of a single client who’s got an SOA implementation who has not, as a minimum, thought about governance. They may not be doing everything they want to do or should be doing, but governance is clearly on the attention span of everyone in terms of recognizing that it needs to be done.

So, when we look at governance and when we look at it around SOA, IT governance is something that we’ve had for a long time. SOA governance is a subset, you could say. It complements, but at the same time, it focuses our attention on, what some of the deltas have brought to the marketplace that require improved governance.

Services lifecycles

That governance is not only around the technology. It’s not only around the life-cycle of services. It’s not only around the use of addressing processes and addressing application development. Governance also focuses on the convergence that’s required between business and IT.

The synergistic relationship that we seek will be promoted through the use of governance. Change management specifically brings about a pretty significant focus, meaning that there will be a focus on the part of the business and the IT organizations and teams to bring about the results that are sought.

Examples of problems

Gardner: Jeff, in your book you identify some examples. Are there any that really stand out I that we can trace back to some root cause in the software lifecycle?

Papows: There are, and it’s unfortunate. The ones that make the greatest memory points and often the national headlines, characteristically are the ones that affect the consumer broadly as opposed to the corporate ones.

Obviously, Toyota is in the headlines everyday now. Actually, there was another news cycle recently about Toyota’s Lexus vehicles. The new models apparently have a glitch in the software that controls the balance system.

The ones that make the greatest memory points and often the national headlines, characteristically are the ones that affect the consumer broadly as opposed to the corporate ones.



One of the most heartbreaking things in the research for the book was on software that controls the radiation devices in our hospitals for cancer treatment. I ran across a bunch of research where, because of some software glitches and policy problems in terms of the way those updates were distributed, people with fairly nominal cancers received massive overdoses in radiation.

The medical professionals running these machines -- like much of our culture, because something is computerized -- just assume that it’s infallible. Because of the problems in governance or lack of governance policy, people were being over-radiated. Instead of targeting small tumors in a very targeted way, people’s entire upper torsos, and unfortunately, in one case, head and neck were targeted.

There are lots of examples like that in the book that may not be as ubiquitous as Toyota, but there are many cases of widespread health, power, energy, and security risks as a consequence of the lack of policy management or governance that Kerrie was speaking to just a few minutes ago.

Gardner: Well, these examples certainly are very poignant and clearly something to avoid. I wonder if these are also perhaps just the tip of the iceberg. In addition to things that are problematic at a critical level, is there also a productivity hit? Are large aspects of work in process not nearly as optimal as they could be or are plagued by mistakes that drag down the process?

I want to take this over to Kerrie. IBM has its Smarter Planet approach. I think they're talking about the issue that we're just not nearly as efficient as we could be. What makes the headlines are these terrible issues, but what we're really talking about is a tremendous amount of waste. Aren’t we?

Things we could do better

Holley: We are. That’s exactly what inefficiency is. It speaks to a lot of waste and a lot of things we could do better. A lot of what we’ve been talking about from a Smarter Planet standpoint is actually the exact issues that Jeff has talked about, which is that the world is getting more instrumented. There are more sensors. There is a convergence of a lot of different technology, SOA, business process management, mobile computing, and cloud computing.

Clearly, on one end of the spectrum, it’s increasing the complexity. On the other end of the spectrum, it’s adding tremendous value to businesses, but it mandates this attention to governance.

Gardner: Jeff, in your book do you offer up some advice or solutions about what companies ought to be doing in this governance arena to deal with these glitches?

Papows: We do. We talk about what I call the IT Governance Manifesto, for lack of another catchy phrase. I make the argument that it’s almost reached the point now where we need to lobby for legislation that requires more stringent reporting of software glitches in cases where there is human health and life at stake. Or, alternately, that we impose fines upon individuals or organizations responsible for cover-ups that put people at risk. Or, we simply require a level of IT governance at organizations that produce products that directly affect productivity and quality of life issues.

Kerrie said this really well, Dana. Remember that about 70 percent of our computer scientists in a given year are basically contending with maintaining the existing application inventories that run all of our financial transactions in core sub-systems and topologies. So, 70 percent of our human capital is there to basically keep the stuff that’s in place running.

So, 70 percent of our human capital is there to basically keep the stuff that’s in place running.



Concurrently, we have this smarter planet, where we’ve got billions of RFID tags in motion and 64-bit microprocessors have reached a price point where they are making the way into our dishwashers. We’ve got this plethora of hand-held devices and applications that’s exploding.

All of that is against the backdrop of this more difficult economy, where we can’t just hire more people without automation. We haven't a prayer keeping our noses about water here.

So, God forbid that we ask the federal government, which moves at a dinosaur’s pace relative to Internet speed, to intercede and insist on some of the stuff. But, if we don’t police our own industry, if we don’t get more serious about this governance, whether it’s IBM or WebLayers or some other technological help, we run the risk of seeing the headlines we’re seeing today become completely ubiquitous.

Gardner: Kerrie, I understand that you’re also penning a book, and it’s focused on SOA. First, could you tell us about it, but then are there any aspects of it that address this issue of governance, maybe from a self-help perspective and of not waiting for some legislation or external direction on it.

Holley: The book that’s going to be out later this year is 100 SOA Questions: Asked and Answered. What my co-author [Ali Arsanjani] and I are trying to accomplish in the book, which distinguishes us from other SOA books in the marketplace, is based on thousands of questions that we’ve experienced over the decade in hundreds of projects where we’ve had first-hand roles in as consultants, architects, and developers. We provide the audience with a hands-on, prescriptive understanding of some of the more difficult questions, and not just have platitudes as answers, but really give the reader an answer they can act on.

We’ve organized the content in a way that you can go by domain. If you’re a business stakeholder, you can go to particular areas. That gets back to your question, because business clearly has a big role to play here. The convergence or the relationship between business and IT has a big role to play.

You can go directly into those sections. We do talk about governance. The book is not about governance, but a good percentage of the questions are on governance. What we try to do is help organizations, clients, practitioners, and executives understand what works what doesn’t work.

Always a choice

One of the examples, a small example, is that we always have a choice when we do a project. We can do it in multitude of ways, but we have a lot of evidence that when governance is not applied, when it’s not automated, when it’s not thought about upfront, the expense on the back-end side is enormous. That expense could be the cost of not having the agility that you foresaw.

The expense could be not having the cost reduction that you foresaw. The expense could be the defects that Jeff has spoken about -- the glitches. There is a tremendous downside to not focusing on governance on the front-side, not looking at it in the beginning. The book really tries to ask and answer the toughest SOA questions that we’ve seen in the marketplace over the last decade.

Gardner: We’ll certainly look forward to that. Back to you Jeff. When we think about governance, it has a bit of a siloed history itself. There's the old form of management, the red-light, green-light approach to IT management. We’ve seen design-time governance, but it seems to be somewhat divorced from, even on a different plane than, runtime or operational governance.

What needs to happen in order to make governance more holistic, more end-to-end?

Papows: It’s a good question, Dana. It’s like everything else in our industry. We’re sometimes our own worst enemy and we get hung up on language, and God forbid, we create yet another acronym headache.

There's an old expression, "Everybody wants governance, but nobody wants to be governed." We run the risk, and I think we’ve tripped over it several times, where we get to the point where developers don’t want to be slowed down. There is this Big Brother-connotation at times to governance. We’ve got to explore a different cultural approach to it.

Governance, whether it’s design time or run time, is really about automating and codifying best practices.



Governance, whether it’s design-time or run-time, is really about automating and codifying best practices, and it’s not done generically as was once taught. It can be, in my experience, very specific. The things we see Ford Motor Co. doing are very different. They're germane to their IT culture and organization, and very different than what we see the Bank of America do, as an example.

To Kerrie’s point about the cost of a lack of automated best practices, if we can use the new verb, it isn’t always quantitative. Look at the brand damage to a bank when they shut customers out of their ATM network, the other side of turning the switch when they merged back-office systems. Look at the number of people whose automated payment systems and whatnot were knocked out of kilter.

The brand damage affecting major corporations is a consequence of having these inane debates about whether SOA is alive or dead, whether you need design-time governance or run-time governance. What you need is a way to automate what you are doing, so that your best practices are enforced throughout the development lifecycle.

Kerrie answered your question well when he said it really is about waste. It’s not just about wasted human capital or wasted productivity or cycles. It’s about wasted go-to-market opportunity. Remember, we're now living in the era of market-facing systems. For almost every major business enterprise, our digital footprint is directly accessible in the marketplace, whether it’s an ATM network or a hand-held device. The line between our back-office infrastructure and our consumer experience is being obliterated.

I'd argue that rather than making distinctions between design and run-time governance, companies simply, one way or another, need to automate their best practices. The business mandates of the corporations need to be reflected in an automated way that makes it manageable across the information technology life-cycle -- or you exist at your own peril.

Gardner: Kerrie, any thoughts on this concept of governance and how we make it more ubiquitous and more enforced as the pain and the problems grow evident? The solution at a high level seems pretty clear. It seems to be the implementation where we stumble.

Governance mindset

Holley: You hit it on the head, and Jeff made the point as well. A lot of people think governance is onerous, that it’s a structure that forces people to do things a certain way. They look at it as rigid, inflexible, unforgiving. They think it just gets in the way.

That’s a mindset that people find themselves in, and it’s a reason not to do something. But when you think about the goals that you're seeking, most goals have something to do with efficiency, lower cost, customers, and making the company more agile. When you think about this, pretty much everybody in the marketplace knows that you don’t get those goals for free. There is some cultural change that’s often necessary to bring those goals about, some organizational change.

There's automation. You don’t start with automation. You actually start with the problem, the processes, and picking the right tool. But, automation has to be a part of that solution. One end of the spectrum, we’ve got to address this mindset that governance gets in the way, that it’s overhead, and that it’s unnecessary.

We know that organizations that are very successful, that are achieving many of their goals, when we peel the onion back, we see them focused on governance. One advice that we all know is that you shouldn’t boil the ocean, that you should do incremental change. We also need to do this in governance.

We need to have these incremental successes, where we are focused on automation holistically and looking at the life-cycle, not just looking at the part-of-the-problem space.

Looking for automation as a way out of the hole that has been created is a consequence of the industry’s own success.



Gardner: Jeff, it sounds like governance needs a makeover. Is there an opportunity? You are going to be discussing this book at the IBM Impact Conference 2010, their SOA conference? Is this a good opportunity? You have a lot of IT executive and software executives from the variety of enterprises on hand, but what would you tell them in terms of how to make governance a bit more attractive?

Papows: We all need to say, "I am a computer science professional. We have reached a point in the complexity curve where I no longer scale." You have to start with an admission of fact. And the reality is that the demands placed on today's IT organizations, the magnitude of the existing infrastructure that needs to continue to be cared for, the magnitude of application demands for new systems and access points from all of this new technology, simply is not going to correlate without a completely different highly automated approach.

Kerrie is right. You can't boil the ocean and you can’t do it at once, but you have to start with an honest self-assessment that, as an industry, we can't continue to go forward at the rate and pace that we have grown, given everything we know and that we see, without finally eating our own cooking.

Looking for automation as a way out of the hole that has been created is a consequence of the industry’s own success. We didn't get here because we failed to be fair to all of those developers in the audience. They're going to listen to this and say, "Why am I the bad guy?" They're not the bad guys.

The reality is, as I said, that we're responsible for the greatest percentage of growth in the gross domestic product. We're responsible for the greatest percentage workforce productivity. We've changed the way civilization lives and works. We've dealt with a quantum leap -- and the texture of human existence is a consequence of this technology.

It's time that we simply admit that we need to turn back on ourselves in order to continue to manage this or we, literally, I believe, are on the precipice of that digital equivalent of a Pearl Harbor, and the economic and productivity consequences of failing are extreme.

Gardner: Well, we'll have to leave it there. We're about out of time. We've been discussing how glitches in business have highlighted a possible breakdown in the continuity of technology and that governance is an important factor in making technology continue on its productivity curve, without falling at some degree under its own weight.

I want to thank our guests. We have been joined today by Jeff Papows, President and CEO of WebLayers, and the author of the new book, Glitch: The Hidden Impact of Faulty Software. Thank you so much, Jeff.

Papows: Thank you, Dana, and thank you, Kerrie.

Gardner: And, we have been joined also by Kerrie Holley, an IBM Fellow as well as the CTO for IBM’s SOA Center of Excellence. Thanks for your input, and we will look forward to your book as well.

Holley: Thank you, Dana, and thank you, Jeff.

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

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

Transcript of a sponsored BriefingDirect podcast on the growing danger from faulty software and how to overcome it. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.