Showing posts with label Peyret. Show all posts
Showing posts with label Peyret. Show all posts

Monday, May 18, 2009

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Talk about business

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

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

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

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

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

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

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

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

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

Demonstrate added value

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Uniquely positioned

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Turner: Absolutely.

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

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

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

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

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

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

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

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

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

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

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

Common good vs. individual good

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Two-dimensional question

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

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

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

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

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

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

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

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

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

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

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

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

The issue of value

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

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

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

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

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

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

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

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

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

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

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

The need for rigor

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

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

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

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

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

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

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

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

White: 87 percent.

Getting on the same timeline

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

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

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

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

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

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

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

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

Good to great

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

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

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

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

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

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

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

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

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

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

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

Survival without EA?

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

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

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

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

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

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

White: Perhaps we could go to Thomas?

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

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

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

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

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

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

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

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

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

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

Monday, February 09, 2009

Strong IT Architecture Doubly Important in Tough Economic Times, Says Open Group Expert Panel

Transcript of podcast panel discussion on the role and future of enterprise architecture, recorded at The Open Group's 21st Enterprise Architecture Practitioners Conference in San Diego, Feb. 2, 2009. Special thanks to Paul van der Merwe and Louw Labuschagne of realIRM of South Africa for audience polling features.

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

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today we welcome our listeners to a sponsored podcast discussion coming to you from The Open Group's 21st Enterprise Architecture Practitioners Conference in San Diego, Feb. 2, 2009.

This podcast, part of a series on events and major topics at this conference, centers on enterprise architecture (EA), its role in IT and its role in the business. [Read and hear a related interview with The Open Group CEO Allen Brown.]

We're going to look at the value and role of architecture in light of a dynamic business environment. We've seen tremendous change in just a matter of months across the globe. Prices of commodities are going up and down by a factor of 50 percent in a matter of months. This is creating a new dynamic for businesses -- and therefore also for IT departments.

We're going to take a look at why enterprise architecture -- particularly when it's involved or related to service-oriented architecture (SOA), cloud computing, and security -- plays what I think is an extremely important role, and is something that will become more important, not less, in the short-term.

Here to help us weed through the issues of enterprise architecture is our panel. Please welcome Tony Baer, senior analyst at Ovum. We're also joined by Janine Kemmeren, enterprise architect at Getronics Consulting and chair of the Architecture Forum Strategy Working Group in The Open Group.

We have Chris Forde, vice president and technology integrator at American Express and chair of the Architecture Forum in The Open Group; as well as Jane Varnus, architecture consultant for the enterprise architecture department at the Bank of Montreal, and Henry Peyret, principal analyst at Forrester Research.

We've been hearing an awful lot about TOGAF, and particularly TOGAF 9, but enterprise architecture frameworks are a larger construct, and the relationship between them is something we need to manage. I want to look principally at the relationship between business alignment of IT, business value and outcomes.

My first question goes to Henry. How do EA frameworks generally help businesses align their technology with their dynamic goals?

Henry Peyret: Today, the issue of frameworks is very generalized. They should be customized to fit to the business. I continue to hear that we should align the business with IT, and I think that there is something that is changing currently, where we should synchronize business and IT. That means that we should prepare IT to be not only in line, but synchronized with the business.

What does that mean? That means that the EA framework should be customized and continuously adjusted to the business requirements. That means that sometimes we will collect some artifact and then end the collection of that artifact, because it doesn't mean anything at that point, and we should change to another artifact, which we fit to the new requirements, to the new dynamic.

Gardner: It’s important, of course, for the IT folks to be able to explain the value of architecture, why they need to look across the different aspects of IT, and try to bring a strategic value to them, leveraging such things as TOGAF and other frameworks.

Tony Baer, what are some of the new ways that the IT people need to communicate to the business people, in order to continue to maintain a strategic operative funding?

Value of consistency

Tony Baer: The most important thing, and it's a goal that IT has attained more in the breach, is being consistent. In other words, as opposed to being assigned a project, with maybe 80 percent of the budget you need and 60 percent of the time -- and by the way, the requirements become a moving target -- IT needs a consistent means for translating the undoable to the doable.

This means having consistent process for evaluating the requirements that come in, and evaluating your capabilities, versus what types of regulatory constraints you have, versus -- and here is where the business input comes in -- the speed of change and the velocity of the marketplace.

Without a consistent process, you're going to be reinventing it each time. The most important means for IT to communicate with the business, besides getting to know the business better, is have a consistent process.

Gardner: Chris Forde, there are naysayers nowadays. You can get a lot of hype on just about any side of many arguments. From your perspective, what are the chief components of continuing to invest in architecture, even in a downturn, and what are the paybacks in terms of some of these tremendous shifts, including mergers, acquisitions and consolidations? What are the top three or four rationales?

Chris Forde: The degree of change that we're seeing in the economy and its implications for businesses are -- Nick used the phrase Tsunami during his presentation earlier today -- and that’s really not an understatement. What you have to do is keep your eye on the ball, and the ball is not enterprise architecture. The ball is where the business needs to manage and operate itself effectively.

When the rules change, you can’t just reach back into the same old bag of tricks around architecture. You have to sit down with your partner and say, "Okay, what has changed? Why has it changed, and how do we respond to this?" You need good people with good heads on their shoulders to be able to do that.

Gardner: Let’s take our first question to the audience. They'll see a slide come up with the next question, and that is looking at this impact on the economy, on the whole architecture-IT business alignment set of issues. [Special thanks to Paul van der Merwe and Louw Labuschagne of realIRM of South Africa for audience polling features.]

We're going to be asking you once again to vote with your pads, and the question is: "Does a need for higher general productivity from IT, which loosely means more business value for the same or less money, promote the use of an enterprise architecture framework like TOGAF?"

If you agree, yes; if you disagree, no. Once again, the need for higher general productivity from IT promotes the use of an enterprise architecture framework, yes or no.

While we're tabulating our scores, why don’t we look also at the role of enterprises, and the difference between these various frameworks? There is the Zachman Framework, FEAF, DoDAF, Gartner, and MODAF. I wonder if we need to look at how these relate, rather than how they stand on their own.

Let me take that to Jane Varnus. What is the relationship among these various frameworks, and how should that change in the near term?

Value and history

Jane Varnus: All the frameworks have a valid history and purpose. Every practice has to look at which one is more relevant, both as to its maturity, its goals, and its business, and understand the strengths and appropriateness of the framework they're assessing.

For example, Zachman can be understood and used by inter-practitioners and as a reference point to discuss other frameworks, but none of these are complete. At this point, we're still at an early stage. All the frameworks have value and they all have strengths in different pieces of the workspace.

Gardner: Henry, you said also something around this federation of frameworks.

Peyret: Yes. We just did a survey about framework use in December, and approximately 60 percent of our customers still make their own custom framework. There are more than 40 frameworks available in the market. Why are we still building our own? That’s the main question. Why? Probably because we don't understand what exactly a framework is.

We're able to make a framework to draw broadly across the enterprise. One issue is to take a framework that really fits the enterprise culture. Another also is the maturity of enterprise architecture at the same time.

Just to paraphrase a comment to Jane prior to joining the round table, we've seen a lot of mistakes about choosing those frameworks, because it was chosen only by the enterprise architect. A good framework is one that helps to communicate with the other stakeholders. That means that sharing the same work presentations, the same vocabulary, and the same context. It's absolutely key to choose the right framework.

Gardner: Do you think we're at a point where we need to consolidate, standardize, and reduce the number? What would be the right balance between customization and standardization?

Peyret: I now have more than 10 years in enterprise architecture, and I feel that no one fits every type of enterprise. So, standardizing to only one framework will never happen. I remember a time when I said, "No, the Zachman Framework was not enough, take my own, and I was wrong, and I changed my mind.

Gardner: There you have it. Change is the only constant. Looking now at our first question, not too surprising, given that we have a group of IT architects and planners, 77 percent agree that the need for higher general productivity promotes the use of enterprise architecture.

That’s a pretty strong return on investment (ROI) indicator, when productivity and change are two essential ingredients in normal times, and particularly in a downturn. Only 23 percent disagree with that.

We've talked quite a bit today about business value, the alignment issue between the IT and the outcomes. Our next question is: "Good strategic level IT architecture practices will concretely demonstrate a business value in 12 months or less."

We're looking for a time frame here. How long a term do we need to get for our return on investment?

Please continue to vote, and while you do that we are going to discuss certification, because compliance issues, other concerns about human resources and competency, come to the fore when you have to reduce headcounts. The heads that you keep or you hire have to be extremely good, valuable, capable people.

Let’s take this to Janine Kemmeren. Janine, certification, why is it more important now then ever?

Market demands

Janine Kemmeren: It's now more important than ever because -- and it's a good thing TOGAF 9 has progressed on this -- the market now asks for people who can show that they're capable of doing enterprise architecture.

Gardner: What is the root cause for the rapid increase in certification that we have seen? Is this a function of human resources wanting to see certification before they'll hire, or people recognizing they can increase their value and their career benefit by seeking certification? Any sense of whether this is a supply or a demand function?

Kemmeren: I think it’s both. It’s showing you can do it, and asking people to ensure they can.

Gardner: Let’s take the same question to Chris Forde. Certification, supply and demand, why do you see this as such a skyrocketing aspect of frameworks?

Forde: Certification is a playing-field leveler for organizations, both the consumers and the suppliers. It's somewhere you can apply a rule set and say, "Well, the likelihood that I'm going to get a competent individual is raised, if there are associated standards that are generally accepted and adhered to." Terry talked about this in his presentation earlier today.

To the extent that we have a certification program and a certification body that is credible and is rigorous, you raise the bar for the profession. When you raise the bar for the profession, you get incremental value added over time.

So the certification mechanism for me is a long-term activity. It's not just a snap, and then away we go. We're going to see the benefits of this over the next five to seven years.

Gardner: Tony Baer, governance, risk management, and compliance (GRC) are also very important nowadays. The security issue is something that needs to be thought through from beginning to end in a life cycle, not as an add-on or something that you consider as an afterthought. What do you see as the relationship between the certification trend's rapid uptake, and the security and compliance issues?

Baer: I'll give an example that comes out of the software development life cycle. Back when we had mainframe applications or client-server, you didn’t even have a concept of firewall back then. Nothing really went out of the enterprise, except what you communicated, let’s say through EDI.

At that time it was really all about perimeter, but the perimeter was access control. Then, in the early days of the Internet, we started putting in firewalls. You had specialists, and it developed as a branch of facility security.

However today, no matter how secure you try and write your code, there are all these back doors that keep opening up. You see that just from the insane rate of patches that come through almost weekly on browsers or whatever. It’s gotten to the point where, even if we had enough security professionals in the world, there just aren't enough. It's impossible to keep pace with the rate at which holes are opening up.

Design for security

The only thing we can do is borrow a lesson from manufacturing, which is to design for quality, testability, and security. We'll bring this back into certification shortly, but what you're seeing right now in the software tools market, for example, is that developers and testers are having to test their code for security. You can’t just throw it over the wall to the security professionals.

What this really means today is that there isn't a single standard or certification for security. Yes, there are security certifications, but increasingly they are being embedded in the various jobs we perform in the life cycle of developing software.

Gardner: It didn’t seem that long ago when architects didn’t necessarily concern themselves with security. Now, they should, and so they should get certified.

Baer: No question, because basically the dangers have multiplied so much. There is no single class, and besides, it’s not just a matter of perimeter security.

Gardner: The best way for security is to make it a core methodology.

Baer: Embed it. We found it in manufacturing. The Japanese proved it to us with their cars back in the 1980s, designed for quality the first time with no rework. It's much cheaper in the long run, and the car is better in the long run. The same goes for security.

Gardner: Let’s go back to our audience survey. "The impact on business value from good strategic IT architectural practices will concretely demonstrate a business value in 12 months or less."

Fifty-five percent believe that this has a fairly short-term return. That’s encouraging, and 45 percent are saying no -- you either won’t get it at all or it will take longer.

Let’s go to our next question. Get your pads ready. We're going to open up the time frame a little bit. "Good strategic IT architectural practices will concretely demonstrate a business value in 24 months or less." Yes or no?

Let’s see what you think about a longer-term value. Is this something that will have a return if you give it a little bit more time to pay back the practices that you employ, the methods that you learn, and the certification that you hire, when you follow a framework, and when you use context properly. Will that payback in the near term -- a 24-month horizon?

Back to our panel. Let’s move into these newer areas like cloud computing and SOA. These are also under fire. We have heard the possibility of the death of SOA, if you actually say it's SOA, but perhaps it’s still valuable if you call it something else or pretend it’s not a strategic activity and keep it tactical.

Henry, SOA, in the context of good architecture -- why would SOA not be something powerful in today’s change-oriented, cost-conscious environment?

A concept, not a term

Peyret: I disagree with the idea that we should kill SOA. I've heard about that from some colleagues. If you read completely through the article, you see that the term should disappear. I don’t care if it disappears or not. It's a concept. In fact, for me SOA is mainly principles. Many of those principles are good and should continue to develop in fact.

SOA will go to another state, and we don’t care if it changes its name. The goal is to continue to adopt practices, which will help, and to continue to develop more flexible information systems.

Just to come back to one statement about SOA that was very good. We talked previously about value. The problem with value is that today we measure value mainly on productivity. It should be more productive on maintenance, more productive for development, and more productive for many other aspects.

The problem is that we should measure one more value -- particularly on quality -- and I fully agree with you on taking risk, such as adding bad technology at a bad time. We've seen that so many times, such as in adopting client-server.

There is probably another value of good SOA, which is agility. We should measure the way we can deliver faster -- being able to put in place a new application which is complex, embedding BPM, and things like that in less than three months. That’s a good point. We should measure that sort of approach.

That’s a new value that will help to justify EA. At the moment, with more and more governance and more and more committees, we're not bringing any more agility, which will be needed by the dynamic environment.

Gardner: Jane Varnus, from The Bank of Montreal, do you see SOA as something that’s necessarily an all-or-nothing proposition, where you have to have huge up-front capital expenditures and a long-term payback, or is there a crawl, walk, run process here where you can get incremental value?

Varnus: Certainly that’s the approach that has been taken, and it seems our business really depends more on other things. This is a facilitating technology, and we should do exactly as you say -- look at where it will bring value and where the opportunities are to use it for modernizing and making us more flexible. We're not likely to go at this in a "big bang" way.

Gardner: Let’s look at what our audience has to say about the impact of business value and good strategic-level IT architecture.

"Will practices concretely demonstrate a business value in 24 months or less?"

An overwhelming 88 percent says yes; we seem to agree that it’s going to take longer than a year, perhaps around two years, perhaps a little longer, and yet it seems a good investment. Two years to me doesn’t seem too long to ask, given the complexity and the size of the problems that we've inherited over the years and that we're still dealing with.

Let’s key up our next question, while we talk a little more about SOA. The question is: "SOA, as an enterprise IT-wide strategic initiative is dead, because ... ." This is a multiple choice, so feel free to punch any of these numbers:
  • 1) SOA is not dead, tactically or strategically.
  • 2) the business outcomes from holistic SOA are too small and hard to define.
  • 3) SOA is too complex and hard to do.
  • 4) SOA is too expensive and does not offer concrete return on investment.
  • 5) Existing architectures and approaches are good enough.
  • 6) Benefits of SOA can be better attained via Web-oriented architecture (WOA), or RESTful, or "webby" means instead.
We're asking you whether the end of SOA is a result of any of these factors more than the others, what’s the chief culprit, and/or is this whole business of SOA not continuing hogwash.

Let’s continue this discussion among us. Chris Forde, what's your perspective on the SOA payback issue? It seems to me that about a year ago in Texas, we were discussing how enterprise architecture and SOA might, in fact, become conjoined, that we wouldn’t necessarily distinguish SOA, but that it was good architecture. Do you agree with that, or should SOA these days be given a new lease on life?

Transforming the business

Forde: If SOA is aimed at transforming the business and EA is aimed at the same space, then there is a parallel. In some of the debate what we talk about is actually EA, IT architecture, and what we talk about as SOA is really a technical solution looking for a business problem?

So, it depends on a particular organization’s approach to these problems. Services orientation in your architectural approach and in your solution delivery is certainly practicable. Is it scalable across an enterprise, right off the bat? Unlikely.

Gardner: But as we saw with architecture in general, this is one- to two-year concrete demonstrable return.

Forde: I was hoping you would follow up on that point during the audience discussion. It would be interesting to delve into the drivers of what was behind everybody’s response on that two-year cycle. I speculate that the driver is that it can take you maybe three months to six months to carve up a strategic perspective on something.

When you start, if you are starting it at the beginning of your investment cycle for your business, you're in good shape. If you're not, you're going to be out of frame with the business investment cycle. So, the key to working into a 24-month cycle is the probability of the outcome, because you don’t necessarily get to choose when the business or IT wants to get engaged in some strategic activity.

If you've taken a reasonable approach in terms of the architectural assessment, what you have is a roadmap that can be chunked up after that to 12-month, 13-month, 15-month, 18-month, or 24-month increments for delivery. That’s really what the business and technologists are looking for, something that can be dealt with in bite-size choices. The 24-month thing is an interesting idea, but the drivers behind it are more interesting to me. I guess that's my point.

Gardner: Now, we're seeing some interesting results from our audience. They're overwhelmingly coming down on Number 1, that the death of SOA is hogwash. So, perhaps the notion of postponing such things as SOA or strategic architecture, or evaluating and deploying a framework rigorously doesn’t make sense.

It's not something you should postpone, regardless of the business cycle or the economy. That seems to be a takeaway. Do you agree with that, Henry?

Peyret: Despite the economic downturn -- and we don't know when that will end -- we predicted one or two years ago that we should see a new curve of adoption of new technologies, and we talked about dynamic business applications, business process management (BPM), and many other things like that.

Due to social computing and the fact that more people will add new types of collaboration onto Web, they will ask also for some more activity within the enterprise itself. The problem won't be to deliver more solutions in 18 months or 24 months. Perhaps for strategic types of solution, yes; but we should also look at the enterprise architecture level to deliver some solutions for two days, three days, or one week.

Sometimes, obviously, there will be a lot of limitations about quality, security, risk, scalability, and many others things. Our role as an enterprise architect is to allow that.

I know I'm a little bit provocative when I say that. That’s against the governance processes and many other things like that, but if we continue to have the same governance, we have a lot of committees. We did, in fact, because that was painful to establish. The governance process and committees will be fought.

We have seen some customers who fight their committees, just because the governance and committees weren't responsive enough. So, we should find a balance. I recognize that for the moment the downturn is against that balance, but we should see more agility for governance itself.

Gardner: So we have nothing to fear from enterprise architecture and SOA but fear itself? Tony?

Lag and inertia

Baer: I second Henry’s motion. What I think we have to fear is lag and inertia. That’s what we really have to fear.

One of the things I have actually been very cheered about with TOGAF 9 is that it's taken some important steps in the right direction, in terms of making the practice and the learning of enterprise architecture more accessible, and it's modularized things.

There was a discussion briefly at the end of your presentation this morning about, whether we could adapt this for smaller firms and could we implement this "lite." Allen Brown started mentioning that within The Open Group you're taking elements of TOGAF and applying it to a very moderate-size organization.

Those are important starts, but I think we need to do just as the software development world has, in certain areas, embraced Agile development. And, believe me, Agile is not the solution to everything. In the enterprise architecture space, we need to also take a look at what processes can be implemented lightly to take advantage of opportunities that may happen now, but that may totally change in a matter of weeks.

Move the clock back to the beginning of September. It looked like energy prices were still going through the roof. September 15, Lehman fails, and two weeks later, we start to see oil prices declining from $140 a barrel to $35 a barrel. Classic, long lead-time enterprise architecture processes that require two-year paybacks are just not going to make it in that type of scenario.

Gardner: Just to drill down a little bit more on our audience results, we had 63 percent saying that the SOA business is not dead, either tactically or strategically. The number one reason for those who were less optimistic was that, "Tthe business outcomes from holistic SOA are too small and they're hard to define."

That gets back to some of the comments we've heard today. What do we need to take to the business and the bean counters to get them to better understand the value, whether 12 months, 24 months, or at a crawl, walk, run basis? Is it compliance? Is that the rationale?

Is it security or the ability to get future-proofed, so when we do have an opportunity to exploit cloud services, we can do that readily with governance?

We need to give our enterprise architecture practitioners here a little ammunition that they can take back to their business leaders in order to get the buy-in. Everyone is still looking for an answer to that question.

So, we're going to go down our panel and get your best advice. Let us start with you Jane. What is your advice? What should the technologist tell the business leaders to make them better understand the value that we all seem to understand?

Varnus: This is an incredibly challenging question. The thing we can’t do is go back to the business and start talking technology to them. They're not interested in how we support them. What they're interested in is that we should, at a reasonable cost, be reasonably flexible, be absolutely reliable, and be creative. Lag is a big problem. We have to address their concern that we are a partner who is responsive.

So, my short advice is that we have to learn to talk to the business better in their terms, become more tuned in, translate whatever solution we have, and express it back in the terms of that problem. I don’t know what that problem would be in anyone else’s business, but don't mention SOA and don't mention the cloud.

Gardner: The architecture that should not be mentioned. Chris Forde, you mentioned earlier that business alignment is as much about business in business, than it is about business in IT. Is that part of the discussion that we should be having with them?

The right conversation

Forde: Yeah, it is, and it’s a relatively easy conversation to have, as long as the issue isn’t IT, because there are a lot of issues with the way IT operates. But in having a conversation about enterprise architecture and moving the business, I agree with Jane.

We don’t want to have the conversation about architecture. We want to have the conversation about what it is that’s going to make their business more effective. Some of those issues may be inter-business unit related, not specific to IT, and that’s a good conversation to have.

Gardner: Tony Baer, what’s the ammunition that we need to better reinforce the value of investing at the strategic IT architecture level?

Baer: I'd reinforce what Jane was saying. It’s showing consistent results and -- I don’t want to get hung up on the term rapid -- but let’s just say responsive results. It's showing that we're not going to fall into the usual trap of delivering late, over budget and under scope, that IT can be relied upon.

At the end of the day, that’s what enterprise architecture is all about. It's not about devising frameworks. It's about making your performance consistent, rational, and understandable.

Gardner: You are saying, I think, "under promise and over deliver," but is that possible?

Baer: I was saying that the problem that IT has had perennially is that we have over promised, we have under delivered, and we have overcharged. The whole idea of adopting more consistent practices is that hopefully you can avoid having to reinvent the wheel every time and stop making all those damn mistakes.

Gardner: Henry, are we also looking at a continuum here, where we are really only in the early decades of computing at this holistic level in these organizations? Isn’t there a need to look at some sort of Moore’s Law when it comes to IT, that prices will come down, but we have to invest, and that we haven’t gotten maturity yet and we shouldn’t give up.

Peyret: No, we haven't yet come to a maturity at that level, but there's a bigger problem. IT is suffering, and particularly the enterprise architect group, which is more transverse to some lines of business that are not complete today. This is particularly true in the bank industry, but there are some other industries that are also changing. I think that we're going to have a new organizational model. The matrix model is not dead. It's still living, unfortunately, and we're facing a big problem with that.

The problem is that the enterprise architect is trying to solve some of the organizational issues, which have not been solved. We're trying to solve some transverse problem at the enterprise architecture level, when it should have been solved at the business-unit level, by naming one business unit that has had some problems from beginning to end.

Because we have not named those business units to have that new model, which is a network organizational model, the EAs are struggling. A lot of the problem is making the right decision and finding the right owner.

What does that mean for us? That’s challenging for the moment. And, I fully agree. We're not transparent enough to explain to people who are struggling with their own problems that it's not an EA problem. At the same time, we are there to compensate for those problems.

That’s not easy, obviously, and that’s somewhere I have seen a lot of enterprise architect fight, just because they have faced that problem.

Gardner: It seems like there have always been several very good excuses to remain tactical and not get strategic with IT. We just happen to have a big economic excuse right now. But, the longer we postpone, the longer that we resist taking a top-down, holistic, well-thought out, methodological, and standardized perspective, the bigger the problem gets -- and the harder it is to move to that standardized level. Do you agree with that Janine?

Kemmeren: Yes, I do.

Gardner: Is there anything else that you'd offer in terms of how to keep the momentum moving toward strategic IT thinking and planning?

The language of business

Kemmeren: The key in this is not to focus only on technology, but in trying to talk the language of the business, and, in that way, try to get close to the business and understand the problems.

Gardner: What about the business understanding the IT problems?

Kemmeren: That’s a good one.

Gardner: Maybe we're not giving them enough information about what’s really going on in IT!

Kemmeren: I think maybe we're giving them too much information.

Gardner: But, not the right kind of information.

Kemmeren: In the wrong kind of way.

Gardner: What kind of information should we be giving them, Henry?

Peyret: We talk mainly about productivity and costs. When we talk about ROI and cost only, and not risk at the business level, then we lose something. The issue now is to talk more about agility, flexibility, and the capability to shorten the time to market and deliver new products.

During the last decade, we've seen a dramatic change that affected many businesses. It was the capability to take some invention brought by partners, by delivery channels, by new things like those, but assembling them only in terms of capability. We call that the innovation network, and we have seen that network at large, creating a lot of difficulties within different enterprises.

The banking industry, for example, is no longer delivering their own business only through their own internal systems. They're assembling many other external partners. That trend will continue and will grow.

The problem is more about describing those complexities, and it's not about the technology aspect, but more about some business that is booming. The new way to demonstrate value is to explain that we will be able now to make something faster in terms of time to market, time to design, and time to deliver. All of those things are what we call key agility indicators.

It's the flexibility aspect, again, but not the flexibility that every IT provider is talking about. Why? Because they are not defining what type of flexibility they are talking about. We need to specify a key agility indicator at a business level.

We need also to assess our process to say that perhaps we need to deliver that in three months. Unfortunately, our current process and systems are able to deliver that only in five months. How could we shorten that? How could we bring in new practices and new ways to do that, or perhaps a new technology?

Gardner: Tony, earlier you raised the issue of the maturation of manufacturing in the past 40 or 50 years, since World War II as an example of a trajectory for IT. Isn’t that a viable way to explain the difficulties -- that we need to do what you've done with your transportation systems, what you do with your facilities, what you've done with human resources and hiring? There’s been an emphasis on quality, process, and innovation.

Why wouldn’t it make sense to draw that into the IT department to get resources, buy-in, and more SOA?

Baer: I'll start with a very important qualification. We're talking about manufacturing, but we don’t want do what GM has done. What we can learn is the idea of lean, which the Japanese adapted from the doctrine of Juran and Deming, total quality control, lean manufacturing.

Do it right the first time

Gardner: It makes sense to do it right the first time.

Baer: Exactly. In other words, traditional manufacturing relied on rework. We'll just get it out there, and if we need to fix it, we'll just bring it back and fix it. As it turned out, it not only wastes time and money, when you have to fix something that’s already been built, it makes for a poorer quality product.

Gardner: Chris, before we go to the audience for questions, do you have anything to offer in terms of the right messaging, so that business better understands the challenges and requirements of the IT function, and also that the IT people can ascertain from the business side what’s going to be perceived as mission critical and readily backed?

Forde: One thing that's probably going to be useful is a degree of transparency into the IT function. When the business clearly understands what’s driving the quotes coming back to them, they're in a better position to determine what kind of investments they really need to make. In the course of developing that transparency, it causes IT to be more introspective about the way it operates.

There’s a certain set of conversations that needs to occur about how effective the IT operation actually is. This is also in context with other business units. We talk about IT as if it's separate from the business, when, in fact, it's a component of our business operation just like others. It has a certain level of importance and a relationship to certain types of technology, but it isn’t the be all and end all.

We just have to get into a better conversation with the business partners about what’s driving the behaviors in IT, and transparency is one way to do that.

Gardner: I'd like to ask our audience for questions. We've posed questions to you, and now it’s your turn. Raise your hand, and we will get a microphone to you shortly.

But I just wanted to take one last stab here. We need to transform business. We have a very dynamic global, economic environment. We're talking about transforming IT as a lever, as a mechanism to help transform the business. Perhaps we need to transform the dialog between business and IT in order to facilitate some of these other transformations. Henry?

Peyret: As a consequence of some business process orientation, also of the change of the organizational model, and to have a different discussion between IT and business, we'll need to contractualize better and faster between the different parties. I say contractualize, and I know that's probably not the right word about that, but we need to discuss contracts, including internally. The more we go to the next organizational model, the more we will be required to contractualize.

What does that mean? I really believe that it’s the next trend for application adoption, after CRM, ERP, supply chain management, and things like that. It will be about contract management at every level and everywhere. That requires us to develop a contract bus or contract exchange between the different aspects.

The problem with contractualization is that it's very close to the business. It's something that affects everything in the business, but it affects something that is key within each business. There is no a single contract management program out of the box or off the shelf, which will solve all those aspect.

But in that manner we'll be able to become more transparent to the different functions within the enterprise. We'll be able to assemble services very quickly. If we're able to contractualize and take the cost for every one of those contracts, we'll be able to negotiate and have more contracts to deliver from IT to different line of business requirements.

Gardner: This sounds like governance at a business level, but it cuts across all relationships.

Contracts -- the next step

Peyret: Absolutely -- internally and externally, and the external contracts will impact the internal contracts as well. That’s why we need to develop that contractualization all across the different groups. That’s just a next step for the client and customer supplier relationship that we've developed for a decade now. It's just the next step.

Gardner: Thank you very much. We're now happy to take some questions and even observations. If you have a statement that you want to debunk or if you want to reaffirm something, we'd be delighted to hear from you.

Christian Slate: Hi, my name is Christian Slate. I keep hearing people say they're searching for ways of explaining the benefits of enterprise architecture. I usually find that explaining the risks, exploiting the fear factor, the things that can go wrong if you don’t understand your architecture, don’t understand your business, pays off more. Any comments on that?

Gardner: That sounds like, if you think getting an education is expensive, try not getting one. Anybody want to respond?

Varnus: It’s a great idea. At the same time, if you're going to raise a specter of fear you have to know that you can address that and resolve it. That gets us back into the question of having a better understanding on both sides of who owns what. That’s partly coming back to the question of contracts. When you raise fear, you have to understand your capability to deliver as part of the whole organism.

Gardner: Thank you, Jane. Henry?

Peyret: That works very well for some verticals. When you're talking about finance, for example, obviously fear is key. I work for nuclear, and, believe me, that’s also a good point. For some other industries, where they don’t care, absolutely not. So, you have to take care about that approach.

That has some limitation for the time being. It’s more positive to talk about the flexibility aspect, rather than only fear. It's less pessimistic.

Gardner: Thank you. Yes, next question.

Charles Alexi: It’s Charles Alexi from Tonex. I have a question to the audience and maybe to everyone. What we have seen, as a consultant industry, is that the idea of EA is great. No one has any problem with alignment of the business and the IT. But the main issue is that the businesses are also transforming themselves. When we want to align the IT to the business, you need to make IT people become business people, and that’s what they don’t want.

I think the major issue will be really the culture, as you mentioned, and also the issue of a good methodology, because you have now to learn, as IT people, how the business process works. Any comments on that?

Gardner: I think you are saying we need to bring more crass commercialism into the thinking of the IT department.

Forde: There’s a certain degree of discipline that comes out of an IT organization about how to approach things in a certain fashion. Now, that may or may not be a good thing, from a business perspective, but where there’s a high degree of readiness in the IT organization to engage with the business partner, there may be not the same level of readiness on the business side and vice versa.

What I'm suggesting is that the IT folks need to improve their game, relative to understanding their business partners’ issues and context, and vice versa. I think that was the question Dana was asking earlier.

But where we are talking about architecture and change, from a business transformation perspective as well, the opportunity here for us, from an EA framework perspective, is to bring a discipline and a structure that can be transferred out of IT into the business. Now, whether the readiness is there or not on both sides is a different question, but it’s an opportunity for us.

Tom Graves: Hi, Tom Graves. I am really picking up a comment of Jane’s about IT and the focus on the business wanting reliability, rather than just cost cutting. One of the things I'm seeing is that if we become more aware of what the business is looking at, we shift from being a cost center to a profit center, to actually becoming an agility focus for the business.

Are you seeing this happening in your own environments, in your own business? As we become more engaged in the business, we become a partner rather than just simply a supplier, and a not very loved one at that.

Gardner: Alright, how do we become the enabler. Obviously a good question. Maybe too good.

Peyret: That particularly is the case currently in some verticals, where the IT is seen as participating in the innovation and changing the attitude of business. I've seen that in pharmaceuticals. I've seen that also in banks, in some of the banks where they see really the IT as helping the innovation.

Gardner: Well, obviously we know part of our challenge is how to convert ourselves into being perceived differently.

Well, I want to thank our panelists. We have been enjoying the insights of Tony Baer from Ovum; Janine Kemmeren of Getronics Consulting; Chris Forde, American Express; Jane Varnus of the Department of Architecture at the Bank of Montreal, and Henry Peyret of Forrester Research.

I also want to tell you that our conversation today comes to you through the support of The Open Group from the 21st Enterprise Architecture Practitioners Conference, here in San Diego. I'm Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening and come back next time.

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

Transcript of a podcast panel discussion on the role and future of enterprise architecture, recorded at The Open Group's 21st Enterprise Architecture Practitioners Conference in San Diego. Special thanks to Paul van der Merwe and Louw Labuschagne of realIRM of South Africa for audience polling features. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

View more podcasts and resources from The Open Group's recent conferences and TOGAF 9 launch:

The Open Group's CEO Allen Brown interview

Deep dive into TOGAF 9 use benefits

Reporting on the TOGAF 9 launch

Panel discussion on security trends and needs

Panel discussion on cloud computing and enterprise architecture

Access the conference proceedings

General TOGAF 9 information

Introduction to TOGAF 9 whitepaper

Whitepaper on migrating from TOGAF 8.1.1 to version 9

TOGAF 9 certification information

TOGAF 9 Commercial Licensing program information