Showing posts with label Turner. Show all posts
Showing posts with label Turner. 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 Podcast.com. 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 Podcast.com. 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.

Thursday, February 12, 2009

TOGAF 9 Advances IT Maturity While Offering More Paths to Architecture-Level IT Improvement

Transcript of a podcast on the evolution of the TOGAF 9 architectural framework, announced at The Open Group's 21st Enterprise Architecture Practitioners Conference in San Diego, February 2009.

Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. 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. 3, 2009. Our topic for this podcast, which is part of a series of podcasts on events and major topics of this conference, centers on TOGAF 9, the newly released enterprise architecture framework.

The framework, the latest in the series, was released here Feb. 2 at the conference, and it really represents a departure for The Open Group and for enterprise architecture frameworks in general. It's larger, more mature, and modular to allow folks to enter it from a variety of perspectives. It takes on a much more significant business services and accomplishments perspective.

While IT practitioners and architects will be looking over TOGAF 9 deeply, it’s also going to be of interest to the business side of the enterprise and will be a way for them to understand more about how IT can service their business needs.

To guide us through our discussion on the evolution of TOGAF 9, where it's come from and where it is today, we're joined by Robert Weisman, CEO and principal consultant for Build The Vision, based in Ottawa. Welcome to show, Robert.

Robert Weisman: Delighted to be here.

Gardner: We're also joined by Mike Turner, an enterprise architect at Capgemini, based in London. Welcome to the show.

Mike Turner: Thanks, Dana.

Gardner: It's been my contention for some time now that architecture is destiny. How well you do architecture has a deep impact on your cost, your benefits, your quality of services, and ultimately, how competitive and well run you are as an enterprise.

Let’s go first to Robert. Do you agree that architecture is destiny, and is it perhaps more so now than ever?

Weisman: I can see architecture being an integral part of the business planning process. It structures the business plans and makes sure that the objectives are realizable. In other words, we can use the acronym SMART, specific, measurable, actionable, realizable, and time bound. What TOGAF 9 does is provide an overarching vision and capability with which to cooperate.

Gardner: Let’s take the same question over to you, Mike, this notion that how well you do architecture is a rather important aspect of your competencies of business. [Read more on a panel discussion about the importance of enterprise architecture.]

Turner: Architecture is definitely a factor. I see architecture as a set of tools and techniques that can help you achieve what you want to do as a business. Taking architecture in isolation is not necessarily going to achieve the right things for your organization, because you actually need to have the direction as an input for architecture to support achievement of a particular outcome.

Architecture is really a vital tool for is being able to assure that the correct business outcome is achieved. You need to have a structured approach to how you define the problem space that businesses are facing, then define the solution space, and define how you move from where you are right now to where you want to be.

If that’s not managed in a structured and traceable way that takes you from strategy through to realization, it’s very easy to go off track. It’s very easy for people to reinterpret what the business needs. It's very easy for technology projects, in particular, to take on a life of their own and deliver something, but not necessarily the thing that was originally intended.

So, in some way, architecture is that essential toolkit to make sure that the achievement of change is realized effectively from a content perspective.

Gardner: Change, of course, is a very important aspect of business nowadays, with a difficult economic climate and rapid change across many different industries, how they finance themselves, what their customers are doing, as well as the supply chain. Before we get more deeply into TOGAF 9 and frameworks, what does architecture bring to the ability of an organization to change rapidly?

Mergers and acquisitions

Weisman: When you're talking about change in this climate, there's going to be a great many mergers and acquisitions. Having been through them, there are two ways of going through them -- painful and less painful. Architecture is certainly a less painful way of doing it.

If you want to use knowledge in a knowledge-based economy, you want to make sure, when you actually acquire a company, that they stay acquired, that they don’t just walk. You have to know what they have. You have to also know the value of the soft assets within a company, and that’s what architecture brings to the fore. It brings out clearly the full value of the company, and make sure, before you do an acquisition or a merger, that you can compare the companies and do due diligence to determine whether there is actually a fit.

Gardner: Mike Turner, how about this change aspect and how architecture might be a serious foundation for good change management?

Turner: That question would have a different answer depending on the type of change that you are looking and dealing with. There are some changes that organizations are prepared to encounter and are anticipating. In those cases, architecture is a really good tool to help you to become more effective at dealing with those changes as they happen.

A good example of that would be a large organization that’s on an acquisition trail of buying up small organizations that operate in a similar business model as they do. Using architecture as a technique, you can actually say, "When we acquire a business, we expect it to have these capabilities. This is how we would take those capabilities into our environment." You can quite quickly absorb that change by having a repeatable approach to deal with it.

In those kind of spaces, architecture is really key, because you're anticipating the change, can plan for it, and can manage it strategically. If you don’t do that, then you end up having to face the problem afresh every time you encounter this situation and become ineffective at dealing with those kinds of repeatable processes.

Gardner: What about the discipline that’s required through adoption of a framework, that then puts you in a position to be able to be fleet and agile, when the unanticipated changes are required?

Turner: The other class of change is the change that you weren’t expecting. In those situations, your organization needs to be structured or siloed in ways that actually allow you to quickly reorganize and do things that are unexpected.

In those kind of situations, there's a component where architecture is helpful and then there's a piece where a architecture probably isn’t going to help you at all, because you're dealing with something that’s outside of what you understand today.

Architecture can help you structure your organization so that it's flexible. Outside of that, you're really into the space of a more agile-type approach, where you're not prepared to deal with things, and you just need to try something out, do something quickly, do something tactical, and build from that.

Plan for change

Weisman: There's an old adage that a plan is a common basis for change. If you don’t have the plan or your architectural framework, change is very difficult. Secondly, there is the old Roman adage, which basically says that luck is only where opportunity meets preparation. Architecture is that preparation or part of the preparation for that.

Gardner: Let’s take a brief trip down memory lane. I spoke to Allen Brown, the CEO of The Open Group, and he said that 9 coming out was, in a sense, like giving birth. It was a long gestation period and then a rather difficult last few days. So now that its out, tell us what the frameworks were like leading up to TOGAF 9, and then particularly what differentiates or distinguishes 9. We'll start with you Robert.

Weisman: TOGAF 9, first of all, is more business focused. Before that it was definitely in the IT realm, and IT was essentially defined as hardware and software. The definition of IT in TOGAF 9 is the lifecycle management of information and related technology within an organization. It puts much more emphasis on the actual information, its access, presentation, and quality, so that it can provide not only transaction processing support, but analytical processing support for critical business decisions.

The gestation took five years. I've been part of the forum for five years working on the TOGAF 9. Part of the challenge was that we had such an incredible take up of TOGAF 8. Once a standard has been taken up, you can’t change it on a dime. You don’t want to change it on a dime, but you want to keep it dynamic, update it, and incorporate best practices. That would explain some of the gestation period. TOGAF 8 was very successful, and to get TOGAF 9 right, it was a little longer cycle, but I think it’s been well worth the wait.

Gardner: Mike, what more generally has been the shift or change over time in how frameworks have been developed? Obviously, they've gotten larger and are more inclusive, but more generally, as a character of what they're trying to accomplish, how have frameworks changed over the past 20 years?

Turner: If you look at the industry in general, we're going through a process where the IT industry is maturing and becoming more stable, and change is becoming more incremental in the industry. What you see in architecture frameworks is a cycle of discovery, invention, and then consolidation that follows, as consensus is reached.

One thing that’s really key about TOGAF 9 is that it takes a lot of ideas and practices that exist within individual organizations or proprietary frameworks, building a consensus around it, and releasing it into a public-domain context.

Once that happens, the value you can get from that approach increases exponentially. Now, you're not talking about going to one vendor and having to deal with one particular set of concepts, and then going to a different vendor and having to deal with another set of concepts, and dealing with the interoperability between those.

You're in a situation where the industry agrees this is the way to do things. Suddenly, the economies of scale that you can get from that, as all the participants in the industry starts to converge on that consensus, mean that you get a whole set of new opportunities about how you can use architecture.

Vendor and technology neutral

Gardner: For those listeners who might not be familiar, The Open Group is a vendor-neutral and technology-neutral consortium. TOGAF, which is The Open Group Architecture Framework, is free in its online form, and there's a charge for the printed version.

About 7,500 individuals currently hold TOGAF certification, which is another important aspect of TOGAF, basically approving that you have the knowledge, experience, and understanding to carry it through. To date, 90,000 copies of TOGAF framework have been downloaded and 20,000 hard copies have been sold.

Let’s go back to Robert Weisman. Let’s look a little deeper at what distinguishes TOGAF 9. We mentioned the modularity. There is also the deeper use of the architecture development method. There is also a bit more inclusive comfort, if you will, with cloud computing and service-oriented architecture (SOA), and thinking more of security, start to finish and holistically. Maybe we could go through a laundry list of what distinguishes TOGAF 9.

Weisman: There are many particular factors. TOGAF 9 is, in certain ways, an evolutionary change and in certain other ways a revolutionary change. The architecture development methodology has basically remained similar. However, transforming the architecture from concept into a reality has basically been expanded pretty dramatically, with a great many lessons learned. So, architecture transformation is a large one. Various architectural frameworks have been incorporated into it.

A great many concepts that allow enterprise architecture to be molded with operations management, with system design, portfolio management, business planning, and the Governance Institute's COBIT guidelines and other industry standards have also been incorporated into TOGAF.

Also, there's been a major contribution by such companies as Capgemini, with respect to artifacts and structure. The content meta model is a huge contribution and as a core contribution, but Mike can elaborate upon that.

Overall, it’s much more extensive and it covers much more of the issues that most CIOs and IT architects have to confront on a daily basis. The nice thing about TOGAF is that you don’t have to use it all. You can use bits of it. You can use a large chunk of it, or you can basically choose to use in its entirety. It’s a very modular and flexible framework that way.

Gardner: As I understand it, with 9 they have made a pathway. If you've already adopted 8, you have a bit of a head start, but you don’t have to have gone to 8 in order to start adopting 9. You can work through different modules and start fresh, which I think is a bit of a departure from the past.

Let’s go over to Mike at Capgemini. Tell us about the meta model, and particularly how the use of repositories for policy driven governance and for the organization of assets across both IT and business become relevant now. [More on how Capgemini views cloud computing.]

Addressing challenges

Turner: If we rewind to TOGAF 8 and talk about some of our experiences using TOGAF 8, that's probably a good way to frame what we've tried to add into TOGAF 9 to address some of those challenges that we have encountered.

TOGAF 8, in our experience, was a very powerful process that you could follow to develop architectures. Where you started to hit limitations with TOGAF 8 was around the work products that you produced as a part of executing the architecture development method.

So TOGAF 8 has a lot of language that talks quite informally about the type of activities that an architect would carry out and the type of work products that they would create.

For example, it discusses creating business scenarios and process models and looking at logical data models and physical data models. There's a lot of language in TOGAF 8 that refers to modeling concepts, but then there is nothing actually in TOGAF 8 that says, "This is what a good deliverable looks like," or "This is actually how you would approach modeling those concepts formally."

What we find are organizations that are using TOGAF 8 effectively have two choices. They can adopt the process and leave the content side of things quite open-ended, or they can adopt the process and select something else to do with the content.

At Capgemini, we had a proprietary internal framework for content prior to TOGAF 9. We did a lot of work taking TOGAF 8 process and Capgemini content framework and putting the two together. We found that to be a really effective combination.

What we also found was that, because of the proprietary nature of the Capgemini framework, it became quite difficult for organizations to adopt that configuration. While we're working entirely within a Capgemini environment and we've got control over the people, the skills, the knowledge, and the approach, that works really well. But, when you're looking at multi-vendor sourcing models or looking at upskilling an end user organization, it becomes a lot more difficult.

What we wanted to do with TOGAF 9 was to address that problem head on and to try to create something equivalent to the Capgemini proprietary framework in a way that allows incremental evolution out of TOGAF 8. We took a lot of the informal concepts that were defined in TOGAF 8 and tried to formalize those around some of our internal thinking for content.

Gardner: What is the upside now, since we've made this transition to 9, for the strategic use of repositories?

Turner: One of the things that we've been working on quite heavily over the past few years is getting the various tool vendors to support the Capgemini framework. We've got quite a long list of tool vendors supporting this framework model. What we are expecting is a small incremental effort for those same vendors to transition and make what are essentially cosmetic changes to be able to support the TOGAF 9 content framework.

Very soon, we'll be in a position where we're looking at a market for enterprise architecture tools, where there is now a level of consensus about how to structure models and how to represent them in a way that didn’t exist before. That can only be a good thing for enterprise repositories, because we're moving closer and closer to that consensus point about how content should be structured.

The problem that we're unable to solve is then to take that model, go one step further, and look at the actual operating model within a particular enterprise, how that enterprise chooses to assign roles and responsibilities for carrying out architecture, and how it chooses to federate governance and those kind of concerns. This is fundamental to how you structure repository, because the repository needs to reflect the partitioning that you actually hold within your organizational structure.

We'll see a big improvement, but it’s not the solution in its entirety.

Gardner: Repositories will include a number of different types of artifacts and services, and each organization will have a unique way of approaching that, given their legacy and their history. We do seem to have reached somewhat of a tipping point in recognizing that to manage complexity, to adopt SOA principles effectively and extend them holistically to start dabbling in cloud computing and take advantage of resources and assets available through that particular model or set of models. Does this increasingly require this organizational framework of repository. Do you agree with that Robert?

Underlying rigor

Weisman: No. I've been an enterprise architect now since 1985, and many of these terms come and go. Underlying it is a certain degree of rigor that the frameworks provide.

It doesn’t matter what environment you go into, but if you have a client with 500 definitions of client, their customers, and you're trying to integrate that to take an overview of the customer throughout goodness knows how many databases, what happens is there is certainly a cogent case for consolidating that.

Many organizations carry orders of magnitude more information than they need. The implications for the information technology infrastructure are immense, and the quality of information because of that is pitiful, not allowing the business executives to make proper decisions.

Whether you do cloud computing or not is immaterial. Whatever paradigm you choose, as long as you apply it in a professional and effective manner, it will work. Trying to use a silver-bullet type of approach and a new name to circumscribe rigorous engineering and professional principles would be a grave error.

Gardner: Okay, fair enough. What is it about TOGAF 9, in particular, that does grease the skids a bit for organizations to better adopt and utilize SOA principles, services like software-as-a-service (SaaS), or infrastructure-as-a-service, what we loosely call cloud nowadays?

Weisman: TOGAF was based on a foundational architecture called the Technical Reference Model, which came out of the U.S. many years ago. It's all service oriented.

The term SOA is old wine in new bottles. It's been around for a long time. If you just have a service catalog, if you have duplicate services, it becomes very evident. That’s one of the advantages of the repositories -- you can have an insight into what you actually have.

TOGAF, from its outset in the early 1990s, has been service oriented for that. Just by applying TOGAF, you have a chance of doing your Gap Analysis, of having the visibility into what you have, which makes it not only efficient, but effective from a business perspective.

Gardner: Anything to offer, Mike?

Two points of view

Turner: When you look at SOA, there are probably two different ways that you can think about IT. One offers quite limited benefits to an organization, and the other offers much greater benefit. At a technical level, there are a bunch of standards and design approaches referred to as SOA, that really deal with standardizing the way the applications talk to one another at a software level.

Implementing SOA in this technical sense isn't necessarily a bad thing, and there are certainly benefits to be had in terms of interoperability at a software level from implementing SOA principles. But, just working at that level on its own is not going to give you any business advantages. It’s just going to make it easier to execute development projects.

The power of thinking about services is much more centered on how you look at your organizational capability and how you can more effectively break down your organization into discrete capabilities that are not replicating the same data, business processes, and IT systems in multiple silos.

If you can have a more granular business organization, where you are replicating capability less, it’s much easier to change more quickly, it’s much easier to use those capabilities to do different things, and you see a step change in the performance of your business.

We need to get those kinds of SOA benefits. The first and most important question to ask is, "What are the services that I need in my business? How should I structure my business to make it meet the goals of the industry?" That may be flexibility, but there are actually some organizations or some parts of your enterprise where you actually don’t desire flexibility. You want stability, cost efficiency, and effectiveness in a much more linear, repeatable sense.

TOGAF allows you to understand what makes your business good and then identify what your services are in a way that considers all the different angles. Once that’s defined, you can then put the right technology underneath that to realize what the business is actually looking for. That’s something that can have an absolutely transformational effect on your business.

Gardner: You mentioned that architecture and SOA by themselves don't necessarily aid a business in achieving its goals, but TOGAF 9 has taken steps over this past five years to increase its relevance to business. Robert, explain how that takes place and what that really means?

Weisman: We're talking about services here. The old TOGAF used to talk in terms of the Technical Reference Model. That's still in 9, but we're looking at business services, as Mike was alluding to. We're looking at rationalizing business services and making sure that they're basically well supported by that.

It also assumes that, when you're doing your preliminary planning, you come up with a framework that recognizes the business operation model within your organization and that you have identified your stakeholders and what they actually want to see in the enterprise architecture framework.

Lack of vision

Most projects fail, because they don’t have proper preliminary planning, and they don’t basically go through the problem. They don’t go through the effort of putting a vision in place. As a consequence, they just jump into the architecture -- usually into the applications and technology architecture -- and they find themselves in trouble very quickly for that. They get a great deal of dissatisfaction.

Outsourcing is an excellent example where a high degree of enterprise architecture maturity correlates to a high degree of satisfaction from both the client and vendor of outsourcing services.

Satisfaction, according to Peter Weill’s book, Enterprise Architecture as Strategy, essentially goes from 50-50 with poorer enterprise architecture maturity to 90-90 with enterprise architecture maturity, and that’s satisfaction both for a client and vendor.
So it ends up being a win-win.

When I talk about outsourced services, they are not necessarily all technology either. They can be business processes that are now being outsourced as well, and it will work its way up the stack.

Gardner: We've talked about architecture as important, of course, but the people who then implement the architecture are quite important. To what degree is certification now a particularly relevant aspect of success in a down economy?

Labor issues and getting good people have been a challenge. There have been significant layoffs, but there has also been an increase in the demand for strong IT to support change in a dynamic business environment. Let’s start with you Robert, the role of certification in the year 2009?

Weisman: First of all, there are two dimensions of certification. For example in The Open Group, you have certification with respect to knowledge of the TOGAF methodology, and then you have IT architecture certification. IT architecture is much broader. It includes business architects and enterprise architects as well, and that takes a look at competencies.

There are no international standards for IT architecture. There are many consultancies that work globally. So, all of a sudden, you're called upon, but this provide a global standard and a global level of confidence with respect to the individuals.

The IT Architect Certification (ITAC) and the IT Services Certification (ITSC) that The Open Group are doing, will provide a level of comfort and assurance to clients that basically they are getting people with a uniform degree of competence.

With respect to the downturn, this is going to become important. Right now, most architects call themselves architects, but there is no international standard against which to measure them. That’s led to a great many architecture failures, which, when you examine them, are not surprising.

Using a standard methodology will also enable RFPs to be written rapidly. What happens is now when you say, "I want a vision as per TOGAF," everybody knows what the baseline is. Then, both suppliers and clients can come up with the assurance, saying, "These guys know what they're talking about," and they can put in a reasonable bid for that.

You're talking about the standardization of product and competencies. This is becoming increasingly important. Globally, there's a huge decrease in enrollment in computer science and computer engineering programs, because of the fact that clients aren’t recognizing these professional designations. Many people say there's no business case in going through an expensive degree program, when you can take a short course and have a very deep but very narrow competency in a particular field?

Certification, both from a competency point of view and from a product point of view, is the wave of the future and extremely important.

Gardner: Mike, how does Capgemini look at the certification process and how important it is for your clients?

Demonstrating capability

Turner: It’s very important, and there are two reasons why. If you look externally in trying to source resources from the market -- whether that’s through a subcontractor or to recruit individuals -- having certification is a good way for candidates to be able to demonstrate that they have reached a level of capability and also for potential employers to put in place a benchmark that filters out the noise.

They can spend much more time looking at individual candidates and assessing them as potential fits to the roles that they're trying to source. I wouldn’t say that certification necessarily guarantees that you get the right person, but it gets you to a short list much quicker.

Gardner: How about practitioners themselves? Is there a significant boost in the pay or ability to find the right jobs as a result of this TOGAF certification?

Turner: If you look at the UK market, there is a correlation between certification and higher pay, but I wouldn’t that that’s the absolute overriding factor.

Another angle to this is, if you look within an organization -- and Capgemini as an organization has a large number of architects, but our client base has architects that work in their organizations -- certification starts to outline a career path for architects within an organization and to allow them to develop themselves and demonstrate that they are improving in capability.

Capgemini has a very active certification program, which we run internally and which is based on experience, engagement, and community. We find that to be a very effective way to build and maintain a community and show professional development and mentoring within our internal environment. That’s something that we help our clients do as well.

Ultimately, architecture is about a network of people. It's about communicating effectively within that network, and then that network having a good face to all the stakeholders for architecture. Having training certification, professional development, and those factors can only be a good thing for building that practice.

Gardner: We're going to be wrapping up in a bit. It’s clearly too soon to look into the future. We just got TOGAF 9 out of the gate. I wonder if there isn’t any extrapolation or looking from the vision point of view where we have come from TOGAF 8 to TOGAF 9, to perhaps give some indication to our listeners as to where TOGAF and enterprise architecture frameworks in general are headed.

Let’s start with you, Robert, for our last question. What can we say, given what we now know about TOGAF 9, as to where the next TOGAF might lead us?

Weisman: There are many working groups right now working on TOGAF, the next generation, whatever it’s going to be called, for example, the Information Architecture Working Group and the like. They've been established and they're looking towards the future and the strategy for that.

Working together

What I see eventually is a lot of these architectural frameworks will start emerging. One of the beauties of TOGAF is that it works very well in conjunction with other architectural frameworks. Let’s say that you're using another architectural framework, which a lot of the industry verticals have. Normally they're model based and TOGAF is mainly process based. They come together, extremely well together, and this is a major strength.

You can’t say, "I'm using this. I can’t use TOGAF." TOGAF will help you deliver the other framework. One of the major issues with many of the other frameworks is that they're wonderfully detailed models, but there is no methodology in place with which to deliver them in a systematic manner. So, I see TOGAF not in terms of an über framework, but certainly a cooperative framework.

It’s also linked with other management frameworks and it’s going to be closer to project management, portfolio management, and the like, which should make it an easier transition. An integrative framework of choice might be a way of describing where TOGAF is going. It's going to be a pointer to other standards and how to integrate them within a company.

We're not there to duplicate the work of other wonderful organizations. It’s how to integrate all the wonderful work, because right now, for executives at the CIO and CEO level, it’s pretty confusing out there.

Gardner: Mike Turner, do you agree on that particular extrapolation in the future of more inclusivity and convergence across business types of frameworks, or are there other future elements of TOGAF we should consider?

Turner: Those are all valid points, and I'd add a few more. One thing we're going to see with TOGAF 9 being available now in the industry is that there would be a reaction to that. A lot of the frameworks and standards that sit around the edge of TOGAF are going to realign slightly to make themselves more consistent with how TOGAF works, which, as Bob mentioned, will help TOGAF integrate some of these different approaches. That will happen without changing TOGAF itself. It would just be that the industry will change to be more aligned around the TOGAF model.

In terms of TOGAF development, there's going to be a big focus on people and organizational aspects within TOGAF, trying to formalize the different skills that are required and the different places where you can use TOGAF within an organization.

Ultimately, that will lead to much greater specialization of the method that we have right now, because we have a single method that applies at a very strategic level and also at a very tactical level. As we understand the organizational context, we can start to be more specific about how the method is applied in different contexts.

Another trend is around the formalization of the specification content. We would expect to see, particularly around a standard for managing this kind of massive information that you are managing semantic content and mature, that TOGAF will start to embrace some of those standards. Looking at formal languages for specifying the methodology and putting the tool set itself within software tools that can be customized and configured is something that we would look to do.

Gardner: Well, that gives us quite a bit to look forward to, some more maturity, even though we have reached a significant milestone in the current level of maturity.

We have been talking about TOGAF 9, its introduction and where its come from and part of its evolution. Our conversation today comes to you through the support of The Open Group, and we are coming to you from the 21st Enterprise Architecture Practitioners Conference in San Diego, in February 2009.

I want to thank our panelists. We have been joined by Robert Weisman, CEO and principal consultant for Build The Vision. Thank you Robert.

Weisman: You're very welcome.

Gardner: Also Mike Turner, enterprise architect at Capgemini. Thanks so much, Mike.

Turner: Thanks.

Gardner: I'm Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to BriefingsDirect. Thanks and come back next time.

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

Transcript of a podcast on the development of the TOGAF 9 architectural framework, announced at The Open Group's 21st Enterprise Architecture Practitioners Conference in San Diego, February 2009. 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

Live panel discussion on enterprise architecture trends

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