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

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 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. 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 Podcast.com. 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

Interview: The Open Group's CEO Allen Brown on Advancing the Value of Enterprise IT Through Architecture

Transcript of a podcast with Allen Brown, president and CEO of The Open Group on TOGAF 9 and its effect on enterprise architecture and IT productivity.

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, the week of February 2, 2009.

Our topic for this podcast, part of a series on events and major topics at this conference, centers on The Open Group itself. We're going to be talking with Allen Brown, president and CEO of The Open Group, about the organization and the arrival of TOGAF 9, a major release of its enterprise architecture framework. (Download the TOGAF 9 whitepaper.)

We're going to be discussing how The Open Group operates, some of its goals, and what it does for its members. It's an open and neutral vendor and technology-neutral consortium. It's been around for over 20 years in several different forms. We're going to learn more about the history, but I'm particularly interested in the future.

So, allow me to welcome Allen Brown. Thanks, Allen.

Allen Brown: Thanks, Dana.

Gardner: The Open Group this week has delivered TOGAF 9, a major undertaking for you. I think you referred to it as like having a baby -- a long gestation period and then a tumultuous endpoint. Tell us why TOGAF 9 is such an important milestone for The Open Group?

Brown: TOGAF 9 really feeds into the vision of The Open Group. We've been working on TOGAF for about 15 years. Bear in mind, Dana, that everything that The Open Group does is driven by the members. The vision was driven by the members. All of the work that's gone into TOGAF 9 and all of the other standards are driven by the members, supported by the staff, of course.

Back in 2002 the members were looking for a solution to the problem of stovepipe applications. They all dealt with cross-functional teams, breaking down the boundaries within and between organizations. They found that the applications didn't work in that way, and they needed some way of getting what they called an "integrated information infrastructure."

We worked through that and came up with the guiding light, if you will, for the vision statement of boundaryless information flow. As we worked through, we found that TOGAF was taking off.

TOGAF 8 really took off, when we focused on that subject and we included the enterprise edition of TOGAF 8, coinciding with everyone's need to take a much broader view of their organization. No application lives in a silo anymore. Anything that's done has to integrate with everything else. You have to take a city-planner view to what you do.

So, at the same time as all organizations had this need to have a boundaryless organization with information flowing in a boundaryless way, TOGAF was an ideal method for how you would help that to happen. Whatever other framework you might use, none of them gave the actual guidance to get you there. TOGAF 8 really pushed us in that direction.

A need to move forward

Since then, over the last three or four years, the members have been working on what the next edition would be. TOGAF 8 was so good that it needed a move forward. I think someone described TOGAF 8 as 500 pages of common sense that you don't have to think of yourself. It's a common guide. It's also treated by those organizations that use TOGAF as a common language.

If you've trained everyone within your organization to use TOGAF, they're all speaking a common language and they're using a common approach. It's a common way of doing things. If you're bringing in systems integrators and contractors, and they are TOGAF certified also, they've got that same approach. If you're training people, you can train them more easily, because everyone speaks the same language. (More information on TOGAF certification.)

TOGAF 9 really needed to add some more to TOGAF 8. In March 2007, I did a survey by talking to our members -- really just asking them open-ended questions. What are the key priorities you want from the next version of TOGAF? They said, "We need better guidance on how to align with our business and be able to cascade from that business down to what the IT guys need to deliver. We need more guidance, we need it simpler to use."

Those were the two key driving forces behind where we were going, a more modular structure, and things like that. Trying to do those things, the members focused on how to bring that forward, and it's taken a lot of work.

If you can imagine a large consortium where you've got 300 member organizations -- which is a lot of people at the end of the day -- and everyone is contributing something and a smaller number is doing a real heavy lifting, you've got to get consensus around it. They have done a huge amount of work.

TOGAF 8 was very much focused on giving guidance on how to do enterprise architecture, and the key thing was the architecture development method. What they've done now is provide more guidance on how to do it, made it more modular, and made it easier to consume in bite-sized chunks.

Then they've added other things like a content framework. The content framework provides a meta model for how you can map from the architecture development method, but it also provides the foundation for tools vendors to construct tools that would be helpful for architects to work with TOGAF.

There is a capability framework, not a maturity model, but it's way of helping folks to set up their capability. There are a lot of things that now in TOGAF 9 that have built on the success of TOGAF 8, it has taken a huge amount of work by our members.

Gardner: Over the past several years, and perhaps over a decade, the role of enterprise architecture itself has been elevated. This, I think, is largely a function of the maturity of how IT is done, but also because of the complexity in a number of different variables and the importance of IT to some of these large global enterprises.

As we've seen an elevation in the importance in the role of enterprise architecture, how has The Open Group changed over that same period to align itself with that growing importance of architecture?

Raising the level of professionalism

Brown: The architecture forum itself has grown. The membership numbers have grown, and we've had to deal with much larger numbers of members and contributors, but it's not just TOGAF. It's not just a case of having a framework, a method, or a way of helping organizations do enterprise architecture. We're also concerned with raising the level of professionalism.

There are a couple of other things that we've done. First, we've introduced the IT Architect Certification (ITAC) program. That provides a certification to say not only that this person knows how to do architecture, but can demonstrate it to their peers.

The ITAC certification is agnostic on method and framework. You don't have to know TOGAF to do that, but you have to be able to convince a board-level review that you do have experience and that you're worthy of being called an IT architect.

It requires a very substantial resume, and a very substantial review by peers to say that this person actually does know, and can demonstrate they've got the skills to do IT architecture.

Gardner: This would be someone at that city-planner level, rather than the actual application or even a subset of building architect, to continue the metaphor.

Brown: There are a lot of different areas where we can get confused with enterprise architects. They're not developing applications and they're not architecting applications. They're actually looking at how you can introduce solutions across an enterprise.

The other thing we've done to raise the level of professionalism is to introduce in San Diego two years ago The Association of Open Group Enterprise Architects. That was focused on individuals who could come along and raise the level of professionalism throughout. We launched it the end of January 2007 here.

We now have more than 9,000 members, which shows that the degree of urgency and importance of trying to raise this level of professionalism.

Gardner: Why do you think the very rapid uptake in certification has taken place? I suppose there's both a supply and demand element to it. The folks who are practitioners themselves want to hang their shingle out as best they can. I'm told that the income and career trajectory for those with certification is quite significant and improved over those without.

Also, for the organizations that are in the hiring mode it helps them find qualified people. But, is there something larger at work here, perhaps in regards to our economy right now where we have so much risk. We're dealing with so many dynamic variables. What is it about certification in a recession that makes it all the more important?

Hiring the right people

Brown: Well, in a recession -- and we're early into this period -- a couple of things happen. One is that jobs are scarcer. So, people are looking for qualifications in the people that they're hiring or retaining. Certification is a way of making sure that you're hiring or retaining the right people.

The other thing with certification in TOGAF is that you're making sure that everyone is consistent in their approach. With ITAC, you're making sure that people have got the skills and they're not just claiming to be enterprise architects or IT architects without having demonstrable skills.

So there is a demand pull for those qualifications. There is also more need on the side of individuals to be certified or credentialed in the market.

Gardner: You're also involved with commercial licensing. Can you tell us how that works and whether there is a counter-cyclical effect for that in a downturn as well?

Brown: The way that TOGAF works is that it's free to use for anyone to implement an enterprise architecture within their enterprise. But, if you're going to use TOGAF for commercial gain -- as trainers, consultants, integrators or whatever -- then it's important that you give back to the community. It's the basic open-source model.

We expect people to give back via participation in membership and we use the commercial license to make sure that we know who's doing this. We know that they're certified, but we also know that they get involved in the membership and actually do give back to the community.

Some of them could be dormant. They may just want the commercial license, which comes with the membership. They may want the commercial license to go off and sell TOGAF. Alternatively, they may want the commercial license and participate and contribute. Those that contribute are the ones that get the most back.

Gardner: Is there something about trying times? I suppose we're not just in a trying time, but also a very dynamic time. We have change management, modernization, productivity, and efficiency. Many organizations are looking to reduce their operating costs significantly. Are these accelerators to the role of The Open Group and TOGAF?

Brown: With regards to TOGAF, or enterprise architecture in general -- it doesn't have to be just TOGAF -- there's an underlying theme of using the right kind of processes. With architecture -- and we've had a lot of evidence back from organizations -- they've been able to retire applications leading to savings across their organization. If you can make those savings across the organization using enterprise architecture, then there's a positive ROI and that's good in any time.

Gardner: It also appears, given the complexity, the rapid change, modernization, and maturity, that the role of architecture and the architectural perspective over IT is more important than ever. Do you agree with that, and if so, why?

A need for integration

Brown: The role of architecture is more important right now because of the complexity, because of the need to integrate across organizations and with business partners. You've got a situation where some of the member companies are integrated with more than a thousand other business partners. So, it's difficult to know where the parameters and boundaries of the organization are.

One member I was talking to said that they've got something like 500,000 individuals inside their infrastructure that are not their own staff. So this is a concern that's becoming top of mind for CIOs: Who's in my infrastructure and what are they doing.

We've got, on one hand, the need for enterprise architecture to actually understand what's going on, to be able to map it, to be able to improve the processes, to retire the applications, and to drive forward on different processes. We've also got the rising need for security and security standards. Because you're integrated with other organizations, they need to be common standards.

Gardner: These issues about boundarylessness and security are reflected in some expansion here at the conference. You've introduced the Enterprise Cloud Computing Conference as well as the first Security Practitioners Conference. Why these new conferences? I suppose that we answered that in the first question, but let's hear a little bit more about why cloud and security are enterprise architecture issues. Some may have perhaps not seen it that way?

Brown: The Open Group is broader than just enterprise architecture. The architecture forum is one of a number of forums including Security/Identity Management, the Platform, the UNIX standards, Real-Time and Embedded Systems, Enterprise Management Standards, and so forth. A lot of attention has been focused on enterprise architecture, because of the way that TOGAF has contributed, and some of the professional standards have raised.

We're now looking at other areas. We always look at new areas and see whether there is something unique that The Open Group could contribute where we can collaborate with other organizations and where we can actually help move things forward.

We're looking at cloud. We don't know if it's something that we can contribute to at this point, but we're examining it and we will continue to examine it. There are a number of areas that look as though there is some relevance to what The Open Group does.

One of those, of course, is security. As you said, we've got our first Security Practitioner Conference here at San Diego, and the reason is that security is now becoming top of mind for many CIOs. Many of them have the integration stuff sorted out. They've got processes in place for that, and they know how they're going to move forward with enterprise architecture. They're looking for more guidance and better standards -- and that's why TOGAF 9 is there.

Now that they've got that sorted out, the big issue for them is security: Who is in my infrastructure and what are they taking? So, we're raising the level of security practitioners, and that's coming to the fore. That's why we've got the first conference here.

Coincidentally, a lot of the interest from the members in looking at security is also converging with looking at cloud. Some of the sessions here are on secure cloud and the issues of security with cloud, but also we're looking at Web 2.0 security, and some of the other standards. There's a security assertion markup language (SAML) standard that we're looking at.

We've got a lot of movement forward in those areas. With the enterprise architecture practitioner conferences here, the agenda is led by members. What it has done is to expose enterprise architecture to a lot of people. It's brought people into The Open Group to share their experiences.

A lot of the value, of course, is in the networking and sharing experiences with people that are at the same level and in the same situation as you are. We want to do the same with security, and that's where our security forum members want to take it.

Gardner: I suppose it is bit premature, seeing as you've just introduced TOGAF 9 to the market, but these things never stop. They're always in motion. There's a next generation TOGAF in the works. Do you have any sense of what emphasis, or least trajectory, we could extrapolate from where TOGAF 8 and 9 have taken us to what we might expect in several years in the next revision.

Brown: That's something that the architecture forum will be working on. It's not something that I am up on right now. The great thing about TOGAF 9 is that we've had such a great reception from the analysts, bloggers, and so on. Many of them are giving us recommendations, and they say, "This is great, and here are my recommendations for where you go."

We've got to gather a lot of that together, and the architecture forum, the members, will take a look at that and then figure out where the plan goes. I know that they're going to be working on things more general, as well as TOGAF in the architecture space.

Gardner: Very good. We've learned a bit more about The Open Group upon the arrival of its milestone TOGAF 9 release and have clearly seen that there are many moving variables within organizations that they need to embrace and understand and put in the context of their operation. We want to thank Allen Brown, president and CEO of The Open Group for joining us.

Brown: Thank you very much, Dana.

Gardner: Our conversation today comes to you through the support of The Open Group from their 21st Enterprise Architecture Practitioner Conference 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 Podcast.com. Learn more. Sponsor: The Open Group.

Transcript of a podcast with Allen Brown, president and CEO of The Open Group on TOGAF 9 and its effect on enterprise architecture and IT productivity. 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:

Live panel discussion on enterprise architecture trends

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