On the Road to Sydney: The Open Group Gets Under Enterprise Architecture, Business Architecture and Enterprise Transformation

Transcript of a BriefingsDirect podcast on the role that architects and analysts play in optimizing business capabilities and performance.

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

Dana Gardner: Hello, and welcome to a special BriefingsDirect Thought Leadership interview series, coming to you in conjunction with The Open Group Conference on April 15, in Sydney, Australia.

Gardner

I'm Dana Gardner, Principal Analyst at Interarbor Solutions, and I'll be your host and moderator throughout these business transformation discussions.

The conference, The Open Group’s first in Australia, will focus on "How Does Enterprise Architecture Transform an Enterprise?" And there will be special attention devoted to how enterprise transformation impacts such vertical industries as finance and defense, as well as exploration, mining, and minerals.

We're here now with two of the main speakers at the conference -- Hugh Evans, the Chief Executive Officer of Enterprise Architects, a specialist enterprise architecture (EA) firm based in Melbourne, Australia; and Craig Martin, Chief Operations Officer and Chief Architect at Enterprise Architects.

As some background, Hugh is both the founder and CEO at Enterprise Architects. His professional experience blends design and business, having started out in traditional architecture, computer games design, and digital media, before moving into enterprise IT and business transformation.

In 1999, Hugh founded the IT Strategy Architecture Forum, which included chief architects from most of the top 20 companies in Australia. He has also helped found the Australian Architecture Body of Knowledge and the London Architecture Leadership Forum in the UK.

Since starting Enterprise Architects in 2002, Hugh has grown the team to more than 100 people, with offices in Australia, the UK, and the U.S.

With a career spanning more than 20 years, Craig has held executive positions in the communications, high tech, media, entertainment, and government markets and has operated as an Enterprise Architect and Chief Consulting Architect for a while.

In 2012, Craig became COO of Enterprise Architects to improve the global scalability of the organization, but he is also a key thought leader for strategy and architecture practices for all their clients and also across the EA field.

Craig has been a strong advocate of finding differentiation in businesses through identifying new mixes of business capabilities in those organizations. He advises that companies that do not optimize how they reassemble their capabilities will struggle, and he also believes that business decision making should be driven by economic lifecycles. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

So welcome to you both. How are you doing?

Hugh Evans: Great, Dana. Welcome everyone.

Craig Martin: Thanks very much for having us.

Big-picture perspective

Gardner: I look forward to our talk. Let's look at this first from a big-picture perspective and then drill down into what you are going to get into at the conference in a couple of weeks. What are some of the big problems that businesses are facing, that they need to solve, and that architecture-level solutions can really benefit them. I'll open this up to both Hugh and Craig?

Evans: Thanks very much, Dana. I'll start with the trend in the industry around fast-paced change and disruptive innovation. You'll find that many organizations, many industries, at the moment in the U.S., Australia, and around the world are struggling with the challenges of how to reinvent themselves with an increasing number of interesting and innovative business models coming through.

Evans

For many organizations, this means that they need to wrap their arms around an understanding of their current business activities and what options they've got to leverage their strategic advantages.

We're seeing business architecture as a tool for business model innovation, and on the other side, we're also seeing business architecture as a tool that's being used to better manage risk, compliance, security, and new technology trends around things like cloud, big data, and so on.

Martin: Yes, there is a strong drive within the industry to try and reduce complexity. As organizations are growing, the business stakeholders are confronted with a large amount of information, especially within the architecture space. We're seeing that they're struggling with this complexity and have to make accurate and efficient business decisions on all this information.

Martin

What we are seeing, and based upon what Hugh has already discussed, is that some of those industry drivers are around disruptive business models. For example, we're seeing it with the likes of higher education, the utility space, and financial services space, which are the dominant three.

There is a lot of change occurring in those spaces, and businesses are looking for ways to make them more agile to adapt to that change, and looking towards disciplined architecture and the business-architecture discipline to try and help them in that process.

Gardner: I think I know a bit about how we got here -- computing, globalization, outsourcing, companies expanding across borders, the ability to enter new markets freely, and dealing with security, but also great opportunity. Did I miss anything? Is there anything about the past 10 or 15 years in business practices that have led now to this need for a greater emphasis on that strategic architectural level of thinking?

Martin: A lot has to do with basically building blocks. We've seen a journey that’s traveled within the architecture disciplines specifically. We call it the commodification of the business, and we've seen that maturity in the IT space. A lot of processes that used to be innovative in our business are now becoming fairly utility and core to the business.

In any Tier 1 organization, a lot of the processes that used to differentiate them are now freely available in a number of vendor platforms, and any of their competitors can acquire those.

Looking for differentiation

So they are looking for that differentiation, the ability to be able to differentiate themselves from their competitors, and away from that sort of utility space. That’s a shift that’s beginning to occur. Because a lot of those IT aspects have become industrialized, that’s also moving up into the business space.

In other words, how can we now take complex mysteries in the business space and codify them? In other words, how can we create building blocks for them, so that organizations now can actually effectively work with those building blocks and string them together in different ways to solve more complex business problems.

Evans: I'll add to that Dana. EA is now around 30 years old, but the rise in EA has really come from the need for IT systems to interoperate and to create common standards and common understanding within an organization for how an IT estate is going to come together and deliver the right type of business value.

Through the '90s we saw the proliferation of technologies as a result of the extension of distributed computing models and the emergence of the Internet. We've seen now the ubiquity of the Internet and technology across business. The same sort of concepts that ring true in technology architecture extend out into the business, around how the business interoperates with its components.

This type of thinking enables organizations to change more rapidly.

The need to change very fast for business, which is occurring now in the current economy, with the entrepreneurship and the innovation going on, is seeing this type of thinking come to the fore. This type of thinking enables organizations to change more rapidly. The architecture itself won't make the organization change rapidly, but it will provide the appropriate references and enable people to have the right conversations to make that happen.

Gardner: So architecture can come as a benefit when the complexity kicks in. When you try to change an organization, you don’t get lost along the way. Give me a sense about what sort of paybacks your clients get when they do this correctly, and what happens when you don’t do this very well?

Evans: Business architecture, as well as strategic architecture, is still quite a nascent capability for organizations, and many organizations are really still trying to get a grip on this. The general rule is that organizations don’t manage this so well at the moment, but organizations are looking to improving in this area, because of the obvious, even heuristic, payoffs that you get from being better organized.

You end up spending less money, because you're a more efficient organization, and you end up delivering better value to customers, because you're a more effective organization. This efficiency and effectiveness need within organizations is worth the price of investment in this area.

The actual tangible benefits that we're seeing across our customers includes reduced cost of their IT estate.

Meeting profiles

You have improved security and improved compliance, because organizations can see where their capabilities are meeting the various risk and compliance profiles, and you are also seeing organizations bring products to market quicker.

The ability to move through the product management process, bring products to market more rapidly, and respond to customer need more rapidly puts organizations in front and makes them more competitive.

The sorts of industries we're seeing acting in this area would include the postal industry, where they are moving from a traditional mail- to parcels, which is a result of a move towards online retailing. You're also seeing it in the telco sector and you're seeing it in the banking and finance sector.

In the banking and finance sector, we've also seen a lot of this investment driven by the merger and acquisition (M&A) activity that’s come out of the financial crisis in various countries where we operate. These organizations are getting real value from understanding where the enterprise boundaries are, how they bring the business together, how they better integrate the organizations and acquisitions, and how they better divest.

We're seeing, especially at the strategic level, that the architecture discipline is able to give business decision makers a view into different strategic scenarios.

Martin: We're seeing, especially at the strategic level, that the architecture discipline is able to give business decision makers a view into different strategic scenarios.

For example, where a number of environmental factors and market pressures would have been inputs into a discussion around how to change a business, we're also seeing business decision makers getting a lot of value from running those scenarios through an actual hypothesis of the business model.

For example, they could be considering four or five different strategic scenarios, and what we are seeing is that, using the architecture discipline, it's showing them effectively what those scenarios look like as they cascade through the business. It's showing the impact on capabilities, on people and the approaches and technologies, and the impact on capital expenditures (CAPEX) and operational expenditures (OPEX).

Those views of each of those strategic scenarios allows them to basically pull the trigger on the better strategic scenario to pursue, before they've invested all of their efforts and all that analysis to possibly get to the point where it wasn’t the right decision in the first place. So that might be referred to as sort of the strategic enablement piece.

We're also seeing a lot of value for organizations within the portfolio space. We traditionally get questions like, "I have 180 projects out there. Am I doing the right things? Are those the right 180 projects, and are they going to help me achieve the types of CAPEX and OPEX reductions that I am looking for?"

With the architecture discipline, you don’t take a portfolio lens into what’s occurring within the business. You take an architectural lens, and you're able to give executives an overview of exactly where the spend is occurring. You give them an overview of where the duplication is occurring, and where the loss of cohesion is occurring.

Common problems

A common problem we find, when we go into do these types of gigs, is the amount of duplication occurring across a number of projects. In a worst-case scenario, 75 percent of the projects are all trying to do the same thing, on the same capability, with the same processes.

So there’s a reduction of complexity and the production of efforts that’s occurring across the organizations to try and bring it and get it into more synergistic sessions.

We're also seeing a lot of value occurring up at the customer experience space. That is really taking a strong look at this customer experience view, which is less around all of the underlying building blocks and capabilities of an organization and looking more at what sort of experiences we want to give our customer? What type of product offerings must we assemble, and what underlying building blocks of the organization must be assembled to enable those offerings and those value propositions?

That sort of traceability through the cycle gives you a view of what levers you must pull to optimize your customer experience. Organizations are seeing a lot of value there and that’s basically increasing their effectiveness in the market and having a direct impact on their market share.

What type of product offerings must we assemble, and what underlying building blocks of the organization must be assembled to enable those offerings and those value propositions?

And that’s something that we see time and time again, regardless of what the driver was behind the investment in the architecture project, seeing the team interact and build a coalition for action and for change. That’s the most impressive thing that we get to see.

Gardner: Let’s drill down a little bit into some of what you'll be discussing at the conference in Sydney in April. One of the things that’s puzzling to me, when I go to these Open Group Conferences, is to better understand the relationship between business architecture and IT architecture and where they converge and where they differ. Perhaps you could offer some insights and maybe tease out what some discussion points for that would be at the conference.

Martin: That’s actually quite a hot topic. In general, the architecture discipline has grown from the IT space, and that’s a good progression for it to take, because we're seeing the fruits of that discipline in how they industrialize IT components.

We're seeing the fruits of that in complex enterprise resource planning (ERP) systems, the modularization of those ERP systems, their ability to be customized, and adapt to businesses. It’s a fairly mature space, and the natural progression of that is to apply those same thinking patterns back up into the business space.

In order for this to work effectively well, when somebody asks a question like that, we normally respond with a "depends" statement. We have in this organization a thing called the mandate curve, and it relates to what the mandate is within the business. What is the organization looking to solve?

Are they looking to build an HR management system? Are they looking to gain efficiencies from an enterprise-wide ERP solution? Are they looking to reduce the value chain losses that they're having on a monthly basis? Are they looking to improve customer experience across a group of companies? Or are they looking to improve shareholder value across the organization for an M&A, or maybe reduce cost-to-income.

Problem spaces

Those are some of the problem spaces, and we often get into that mind space to ask, "Those are the problems that you are solving, but what mandate is given to architecture to solve them?" We often find that the mandate for the IT architecture space is sitting beneath the CIO, and the CIO tends to use business architecture as a communication tool with business. In other words, to understand business better, to begin to apply architecture rigor to the business process.

Evans: It’s interesting, Dana. I spent a lot of time last year in the UK, working with the team across a number of business-architecture requirements. We were building business-architecture teams. We were also delivering some projects, where the initial investigation was a business-architecture piece, and we also ran some executive roundtables in the UK.

One thing that struck me in that investigation was the separation that existed in the business-architecture community from the traditional enterprise and technology architecture or IT architecture communities in those organizations that we were dealing with.

One insurance company, in particular, that was building a business-architecture team was looking for people that didn’t necessarily have an architecture background, but possibly could apply that insight. They were looking for deep business domain knowledge inside the various aspects of the insurance organization that they were looking to cover.

So to your question about the relationship between business architecture and IT architecture, where they converge and how they differ, it’s our view that business architecture is a subset of the broader EA picture and that these are actually integrated and unified disciplines.

We're going to see more convergence between these two groups, and that’s certainly something that we are looking to foster in EA.

However, in practice you'll find that there is often quite a separation between these two groups. I think that the major reason for that is that the drivers that are actually creating the investment for business architecture are actually now from coming outside of IT, and to some extent, IT is replicating that investment to build the engagement capability to engage with business so that they can have a more strategic discussion, rather than just take orders from the business.

I think that over this year, we're going to see more convergence between these two groups, and that’s certainly something that we are looking to foster in EA.

Gardner: I just came back from The Open Group Conference in California a few weeks ago, where the topic was focused largely on big data, but analysis was certainly a big part of that. Now, business analysis and business analysts, I suppose, are also part of this ecosystem. Are they subsets of the business architect? How do you see the role of business analysts now fitting into this, given the importance of data and the ability for organizations to manage data with new efficiency and scale?

Martin: Once again, that's also a hot topic. There is a convergence occurring, and we see that across the landscape, when it comes to the number of frameworks and standards that people certify on. Ultimately, it comes to this knife-edge point, in which we need to interact with the business stakeholder and we need to elicit requirements from that stakeholder and be able to model them successfully.

The business-analysis community is slightly more mature in this particular space. They have, for example, the Business Analysis Body of Knowledge (BABOK). Within that space, they leverage a competency model, which in effect goes through a cycle, from an entry level BA, right up to what they refer to as the generalist BA, which is where they see the start of the business-architecture role.

Career path

There's a career path from a traditional business analyst role, which is around requirements solicitation and requirements management, which seems to be quite project focused. In other words, dropping down onto project environments, understanding stakeholder needs and requirements, and modeling those and documenting them, helping the IT teams model the data flows, the data structures but with a specific link into the business space.

As you move up that curve, you get into the business-architecture space, which is a broader structural view around how all the building blocks fit together. In other words, it’s a far broader view than what the business analyst traditional part would take, and looks at a number of different domains. The business architect tends to focus a lot on, as you mentioned, the information space, and we see a difference between the information and the data space.

So the business architect is looking at performance, market-related aspects, and  customer, information, as well as the business processes and functional aspects of an organization.

You can see that the business analysts could almost be seen as the soldiers of these types of functions. In other words, they're the guys that are in the trenches seeing what's working on a day-to-day basis. They've got a number of tools that they're equipped with, which for example the BABOK has given them.

And there are all different ways and techniques that they are using to elicit those requirements from various business stakeholders, until they move out that curve up into the business architecture and strategic architecture space.

There is certainly a pattern emerging, and there are great opportunities for business analysts to come across into the architecture sphere.

Evans: There's an interesting pattern that I've noticed with the business-analyst-to-business-architecture career journey and the traditional IT track, where you see a number of people move into solution architect roles. There might be a solution architect on a project, they might move to multiple projects and ultimately do a program, and a number of those people then pop out to a much broader enterprise view, as they go through their career.

The business analyst is, in many respects, tracking that journey, where business analysts might focus on a project and requirements for a project, might look across at a high view, and possibly get to a point where they have a strong domain understanding that can drive high level sort of strategic discussions within the organization.

There is certainly a pattern emerging, and there are great opportunities for business analysts to come across into the architecture sphere. However, I believe that the broader EA discipline does need to make the effort to bridge that gap. Architecture needs to come across and find those connection points with the analyst community and help to elevate and converge the two sides.

Gardner: Craig, in your presentation at The Open Group Conference in Sydney, what do you hope to accomplish, and will this issue of how the business analyst fits in be prominent in that?

Martin: It’s a general theme that we're using leading right up to the conference. We have a couple of webinars, which deal specifically with this topic. That’s leading up to the plenary talk at The Open Group Conference, which is really looking at how we can use these tools of the architecture discipline to be able to achieve the types of outcomes that we've spoken about here.

Building cohesion

In other words, how do I build cohesion in an organization? How do I look at different types of scenarios that I can execute against? What are the better ways to assemble all the efforts in my organization to achieve those outcomes? That’s taking us through a variety of examples that will be quite visual. 

We'll also be addressing the specific role of where we see the career path and the complementary nature of the business analyst and business architect, as they travel through the cycle of trying to operate at a strategic level and as a strategic enabler within the organization.

Gardner: Maybe you could also help me better understand something. When organizations decide that this is the right thing for them -- as you mentioned earlier, this is still somewhat nascent -- what are some good foundational considerations to get started? What needs to be put in place? Maybe it’s a mindset. How do you often find that enterprises get beyond the inertia and into this discussion about architecture and about the strategic benefits of it?

Martin: Once again, it’s a "depends" answer. For example, we often have two market segments, where a Tier 1 type company would want to build the capability themselves. So there's a journey that we need to take them on around how to have a business-architecture capability while delivering the actual outcomes?

Tier 2 and Tier 3 clients often don’t necessarily want to build that type of capability, so we would focus directly on the outcomes. And those outcomes start with two views. Traditionally, we're seeing the view driven almost on a bottom-up view, as the sponsors of these types of exercises try to get credibility within the organization.

It's not just a bunch of building blocks, but the actual outcome of each of those building blocks and how does it match something like a business-motivation model.

That relates to helping the clients build what we refer to as the utility of the business-architecture space. Our teams go in and, in effect, build a bunch of what we refer to as anchor models to try and get a consistent representation of the business and a consistent language occurring across the entire enterprise, not just within a specific project.

And that gives them a common language they can talk about, for example, common capabilities and common outcomes that they're looking to achieve. In other words, it's not just a bunch of building blocks, but the actual outcome of each of those building blocks and how does it match something like a business-motivation model.

They also look within each of those building blocks to see what the resources are that creates each of those building blocks -- things like people, process and tools. How do we mix those resources in the right way to achieve those types of outcomes that the business is looking for? Normally, the first path that we go through is to try to get that sort of consistent language occurring within an organization.

As an organization matures, that artifact starts to lose its value, and we then find that, because it has created a consistent language in the organization, you can now overlay a variety of different types of views to give business people insights. Ultimately, they don’t necessarily want all these models, but they actually want insight into their organizations to enable them to make decisions.

We can overlay objectives, current project spend, CAPEX, and OPEX. We can overlay where duplication is occurring, where overspend is occurring, where there's conflict occurring at a global scale around duplication of efforts, and with the impact of costs and reduction and efficiencies, all of those types of questions can be answered by merely overlaying a variety of views across this common language.

Elevating the value

That starts to elevate the value of these types of artifacts, and we start to see our business sponsors walking into meetings with all of these overlays on them, and having conversations between them and their colleagues, specifically around the insights that are drawn from these artifacts. We want the architecture to tell the story, not necessarily lengthy PowerPoint presentations, but as people are looking at these types of artifacts, they are actually seeing all the insights that come specifically from it.

The third and final part is often around the business getting to a level of maturity, in that they're starting to use these types of artifacts and then are looking for different ways that they can now mix and assemble. That’s normally a sign of a mature organization and the business-architecture practice.

They have the building blocks. They've seen the value or the types of insights that they can provide. Are there different ways that I can string together my capabilities to achieve different outcomes? Maybe I have got different critical success factors that I am looking to achieve. Maybe there are new shift or new pressures coming in from the environment.

How can I assemble the underlying structures of my organization to better cope with it? That’s the third phase that we take customers through, once they get to that level of maturity.

Evans: Just to add to that, Dana, I agree with Craig on the point that, if you show the business what can actually be delivered such as views on a page that elicit the right types of discussions and that demonstrate the issues, when they see what they're going to get delivered, typically the eyes light up and they say, "I want one of those things."

It's not just enough to know the answer. You have to know how to engage somebody with the material.

The thing with architecture that I have noticed over the years is that architecture is done by a lot of very intelligent people, who have great insights and great understanding, but it's not just enough to know the answer. You have to know how to engage somebody with the material. So when the architecture content that’s coming through is engaging, clear, understandable, and can be consumed by a variety of stakeholders, they go, "That’s what I want. I want one of those."

So my advice to somebody who is going down this path is that if they want to get support and sponsorship for this sort of thing, make sure they get some good examples of what gets delivered when it's done well, as that’s a great way to actually get people behind it.

Gardner: I'm afraid we will have to leave it there. We've been talking with Hugh Evans, the CEO of Enterprise Architects, a specialist EA firm in Melbourne; and Craig Martin, the COO and Chief Architect at Enterprise Architects. Thanks to you both.

Evans: Thanks very much Dana, it has been a pleasure.

Martin: Thank you, Dana.

Gardner: This BriefingsDirect discussion comes to you in conjunction with The Open Group Conference, the first in Australia, on April 15 in Sydney. The focus will be on "How Does Enterprise Architecture Transform an Enterprise?"

So thanks again to both Hugh and Craig, and I know they will be joined by many more thought leaders and speakers on the EA subject and other architecture issues at the conference, and I certainly encourage our readers and listeners to attend that conference, if they're in the Asia-Pacific region.

This is Dana Gardner, Principal Analyst at Interarbor Solutions, your host and moderator through these thought leadership interviews. Thanks again for listening, and come back next time.

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

Transcript of a BriefingsDirect podcast on the role that architects and analysts play in optimizing business capabilities and performance. Copyright The Open Group and Interarbor Solutions, LLC, 2005-2013. All rights reserved.

You may also be interested in:

• The Open Group Panel Explains How the ArchiMate Modeling Language and The Open Group Architecture Framework Impact Such Trends as Big Data and Cloud
• The Open Group Conference Panel Explores How the Big Data Era Now Challenges the IT Status Quo
• Using the Cloud for Big-Data Requires a New Recipe
• Big Data Success Depends on Better Risk Management Practices Like FAIR, Say The Open Group Panelists
• The Open Group Keynoter Sees Big-Data Analytics Bolstering Quality, Manufacturing, Processes
• The Open Group Trusted Technology Forum is Leading the Way to Securing GLobal IT Supply Chains
• Corporate Data, Supply Chains Remain Vulnerable to Cyber Crime Attacks Says Open Group Conference Speaker

Enterprise Architecture and Enterprise Transformation: Related But Distinct Concepts That Can Change the World

Transcript of a sponsored podcast discussion on the respective roles of enterprise architecture and enterprise transformation and the danger --and opportunity -- of conflating the two.

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

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

Today, we present a sponsored podcast discussion in conjunction with The Open Group Conference held in San Francisco the week of January 30, 2012.

We've assembled a panel from among the conference speakers and contributors to examine the fascinating relationship between enterprise architecture (EA) and enterprise transformation. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

For some, the role and impact of an information technology and the organizing benefits of enterprise architecture make them larger than life, when it comes to enterprise transformation. In other words, if you really want enterprise transformation, you really need enterprise architecture to succeed in the modern enterprise.

For others, the elevation of enterprise architecture as a tag team to enterprise transformation improperly conflates the role of enterprise architecture and, as such, waters down enterprise architecture and risks obscuring its unique contribution.

So how should we view these roles and functions? How high into the enterprise transformation firmament should enterprise architecture rise? And will rising too high, in effect, melt its wings and cause it to crash back to earth and perhaps become irrelevant?

Or is enterprise transformation nowadays significantly dependent upon enterprise architecture, and therefore, we should make enterprise architecture a critical aspect for any business moving forward?

We'll pose these and other questions to our panel here to deeply examine the relationship between enterprise architecture and enterprise transformation. So with that, let me now introduce our guests.

We're here with Len Fehskens, Vice President of Skills and Capabilities at The Open Group. Welcome, Len.

Len Fehskens: Hi, Dana. Great to be here.

Gardner: We're also here with Madhav Naidu, Lead Enterprise Architect at Ciena Corp. Welcome to the show, Madhav.

Madhav Naidu: Thanks, Dana.

Gardner: We're also here with Bill Rouse, Professor in the School of Industrial and Systems Engineering and the College of Computing, as well as Executive Director of the Tennenbaum Institute, all at the Georgia Institute of Technology. He's also the Principal at Rouse Associates. Welcome to our show, Bill.

Bill Rouse: It's great to be here, Dana. Thank you.

Gardner: And Jeanne Ross, Director and Principal Research Scientist at the MIT Center for Information Systems Research, join us. Welcome back, Jeanne.

Jeanne Ross: Good morning, Dana.

Architecture and transformation

Gardner: Let's start with you Len. You’ve been tracking enterprise architecture for quite some time. You’ve been a practitioner of this. You’ve been involved with The Open Group for some time. Why is enterprise transformation not significantly dependent upon enterprise architecture, and why would it be a disservice to bring enterprise architecture into the same category?

Fehskens: I don't think that's quite what I believe. My biggest concern is the identification of enterprise architecture with enterprise transformation.

First of all, these two disciplines have different names, and there's a reason for that. Architecture is a means to transformation, but it is not the same as transformation. Architecture enables transformation, but by itself is not enough to effect successful transformation. There are a whole bunch of other things that you have to do.

My second concern is that right now, the discipline of enterprise architecture is sort of undergoing -- I wouldn’t call it an identity crisis -- but certainly, it's the case that we still really haven't come to a widespread, universally shared understanding of what enterprise architecture really means.

Just go onto any Internet discussion group about enterprise architecture, open up the discussion about the definition of enterprise architecture, and I guarantee that you will get hundreds and hundreds of posts all arguing about what enterprise architecture is. To make that problem worse by trying to fold enterprise transformation into the function of enterprise architecture is just not a good idea at this point.

To make that problem worse by trying to fold enterprise transformation into the function of enterprise architecture is just not a good idea at this point.

My position is that they're two separate disciplines. Enterprise architecture is a valuable contributor to enterprise transformation, but the fact of the matter is that people have been transforming enterprises reasonably successfully for a long time without using enterprise architecture. So it's not necessary, but it certainly helps. It's just like having power tools makes it easier to build a house, but people have been building houses for a long time without power tools.

I'm concerned about making bigger promises than we can actually keep by falling into the trap of believing that enterprise architecture, by itself, is sufficient to make enterprise transformation successful. I don’t think that’s the case. There are other things that you need to be able to do besides developing architectures in order to successfully transform an enterprise.

Gardner: Okay, Len, if the concept, the notion, or the definition of enterprise architect is changing, I suppose we also have to recognize that enterprise transformation, as it's defined, is changing as well. To borrow from your analogy, the power tools to build a house are not necessary, but you might be able to build a better house a lot faster. And building things better and faster seem to be much more a part of enterprise transformation now than they used to be.

Fehskens: No argument, but again, to use that analogy, you can do more with power tools than build just houses. You can build all kinds of other stuff as well. So, no argument at all that enterprise architecture is not a powerful means to effecting enterprise transformation, but they are distinct disciplines. The means to an end doesn’t mean the means is the end and doesn’t make them synonymous. They are still, as I said, distinct.

Gardner: I think we’re getting close to understanding the relationship. Madhav, as a practitioner of enterprise architecture at Ciena Corp., are you finding that your role, the value that you’re bringing to your company as an enterprise architect, is transformative? Do you agree with Len? Do you think that there's really a confluence between these different disciplines at this time?

Means and ends

Naidu: Definitely. What Len mentioned, it rhymes very well with me. The means and the end, kind of blending it down. Transformation itself is more like a wedding and EA is more like a wedding planner. I know we have seen many weddings without a wedding planner, but it makes it easier if you have a wedding planner, because they have gone through certain steps (as part of their experience). They walk us through those processes, those methods, and those approaches. It makes it easier.

That’s why, definitely, I agree with what Len said. Enterprise transformation is different. It's a huge task and it is the actual end. Enterprise architecture is a profession that can help lead the transformation successfully.

One another point Len brought up in this discussion is that, it is not just the enterprise architects who will be doing the whole thing. Almost everybody in the enterprise is engaged in one way or another. The enterprise architect plays more like a facilitator role. They are bringing the folks together, aligning them with the transformation, the vision of it, and then driving the transformation and building the capabilities. Those are the roles I will look at EA handling, but definitely, these two are two different aspects.

Gardner: Is there something about the state of affairs right now that makes enterprise architecture specifically important or particularly important for enterprise transformation? I believe I'm getting more towards this idea that IT is more important and that the complexity of the relationship between IT and business necessitates EA and therefore transformation really can't happen without it.

There is a lot of discussion about what really constitutes an EA and where are the boundaries for EA.

Naidu: We know many organizations that have successfully transformed without really calling a function EA and without really using help from a team called EA. But indirectly they are using the same processes, methods, and best practices. They may not be calling those things out, but they are using the best practices. When they do that, the transformations have been successful, but then when they don’t apply those best practices and standards, there are many organizations that fail.

That’s why, now, like Len brought up earlier, there is a lot of discussion about what really constitutes an EA and where are the boundaries for EA, because it is part IT, there are different roles, and part business, and a lot of people are engaged.

So there's a lot of churn going on over what should be the part of EA. But going back to your question, I definitely see the critical role EA is playing. Hopefully, in the next few years, EA will form its appropriate objectives, processes, and methods so that we can say this is what we mean by EA.

Gardner: Bill Rouse, how do you come down on this? Clearly there's an impact that EA has on enterprise transformation. We seem to grasp for analogies when we try to define this relationship. Are you finding in your research and through the organizations you're working with that the role of architecture creeps in? Even if people don’t know they’re doing architecture, when they get to transformation and a complex setting in today’s world, architecture is almost a necessity.

Rouse: There are two distinctions I’d like to draw. First of all, in the many transformation experiences we've studied, you can simplistically say there are three key issues: people, organizations, and technology, and the technology is the easy part. The people and organizations are the hard part.

The other thing is I think you’re talking about is the enterprise IT architecture. If I draw an enterprise architecture, I actually map out organizations and relationships among organizations and work and how it gets done by people and view that as the architecture of the enterprise.

Important enabler

Sometimes, we think of an enterprise quite broadly, like the architecture of the healthcare enterprise is not synonymous with IT. In fact, if you were to magically overnight have a wonderful IT architecture throughout our healthcare system in United States, it would be quite helpful but we would still have a problem with our system because the incentives aren’t right. The whole incentive system is messed up.

So I do think that the enterprise IT architecture, as I see it -- and others can correct me if I'm wrong, but I think that's what you’re talking about -- is an important enabler, a crucial enabler, to many aspects of enterprise transformation. But I don’t see them as close at all in terms of thinking of them as synonymous.

Gardner: Len Fehskens, are we actually talking about IT architecture or enterprise architecture and what's the key difference?

Fehskens: Well, again that’s this part of the problem, and there's a big debate going on within the enterprise architecture community whether enterprise architecture is really about IT, in which case it probably ought to be called enterprise IT architecture or whether it’s about the enterprise as a whole.

For example, when you look at the commitment of resources to the IT function in most organizations, depending on how you count, whether you count by headcount or dollars invested or whatever, the numbers typically run about 5-10 percent. So there's 90 percent of most organizations that is not about IT, and in the true enterprise transformation, that other 90 percent has to transform itself as well.

There's a big debate going on within the enterprise architecture community whether enterprise architecture is really about IT.

So part of it is just glib naming of the discipline. Certainly, what most people mean when they say enterprise architecture and what is actually practiced under the rubric of enterprise architecture is mostly about IT. That is, the implementation of the architecture, the effects of the architecture occurs primarily in the IT domain.

Gardner: But, Len, don't TOGAF at The Open Group and ArchiMate really step far beyond IT? Isn’t that sort of the trend?

Fehskens: It certainly is a trend, but I think we've still got a long way to go. Just look at the language that’s used in the architecture development method (ADM) for TOGAF, for example, and the model of an enterprise architecture. There's business, information, application, and technology.

Well, three of those concepts are very much related to IT and only one of them is really about business. And mostly, the business part is about that part of the business that IT can provide support for. Yes, we do know organizations that are using TOGAF to do architecture outside of the IT realm, but the way it's described, the way it was originally intended, is largely focused on IT.

The TOGAF standard was developed almost entirely by the IT community. But it is clear to people who step back far enough from the details of where the implementation happens that architectural thinking is a very generally applicable discipline and certainly can be applied to that other 90 percent of the enterprise that I talked about.

Not a lot going on

It's just that there's not a whole lot of that going on, and as Madhav pointed out, what is going on is generally not called architecture. It's called organizational design or management or it goes under a whole bunch of other stuff. And it's not referred to as enterprise architecture, but there is a lot of that stuff happening. As I said earlier, it is essential to making enterprise transformation successful.

My personal opinion is that virtually all forms of design involve doing some architectural thinking. Whether you call it that or not, architecture is a particular aspect of the design process, and people do it without recognizing it, and therefore are probably not doing it explicitly.

But Bill made a really important observation, which is that it can't be solely about IT. There's lots of other stuff in the enterprise that needs to transform.

Gardner: To that point, let's go to Jeanne Ross. Jeanne, in your presentation at The Open Group Conference, you mentioned data management and that the ability of leveraging analytics and presenting that to more people with good data in real time is an essential ingredient for transformation and for just doing things better, faster, cheaper, more impactful in the market, and so on.

Now wouldn’t the data management as a category sort of crossover. It's got parts of IT, parts of architectures, and parts of organizational management. When we think about making data management essential, doesn’t this in a sense bring about more recognition that an architectural approach that helps foster something at that level at that category becomes really important in today’s world?

Ross: I actually would discourage people from focusing on data management first. We've had a number of companies we studied who thought, "All I care about is the data. I'm just going to get that cleaned up." What they learned was that if they didn’t clean up their processes, they didn’t need to be thinking about data. It was going nowhere.

Analytics has been over-hyped as something that we can do a lot of in IT, while we're waiting for the rest of the organization to get its act together around architecture. Similarly, that has led to a lot of IT efforts that haven’t added real value to organizations.

So I wouldn't emphasize data management as a priority, even though we'll get there eventually. It is actually essential at some point. I think a lot of efforts around data management have been around the idea "Data makes this organization run. Let's get data fixed," as if we could just do that in isolation from everything else. That is a really frustrating approach.

I'd go back to the challenge we have here of enterprise architecture being buried in the IT unit. Enterprise architecture is an enterprise effort, initiative, and impact. Because enterprise architecture is so often buried in IT, IT people are trying to do things and accomplish things that cannot be done within IT.

We've got to continue to push that enterprise architecture is about designing the way this company will do it business, and that it's far beyond the scope of IT alone. I take it back to the transformation discussion. What we find is that when a company really understands enterprise architecture and embraces it, it will go through a transformation, because it's not used to thinking that way and it's not used to acting that way.

Disciplined processes

If management says we're going to start using IT strategically, we're going to start designing ourselves so that we have disciplined business processes and that we use data well. The company is embracing enterprise architecture and that will lead to a transformation.

Data management will be a crucial element of this, but the big mistake I see out there is thinking that IT will fix up data, and that is going to have some big impact on either enterprise architecture or enterprise transformation, or both. The ‘I’ is simply a critical element. It's not something that we can just fix.

Gardner: You also said that someday CIOs are going to report to the enterprise architects, and that’s the way it ought to be. Does that get closer to this notion that IT can't do this alone, that a different level of thinking across disciplines and functions needs to occur?

Ross: I certainly think so. Look at companies that have really embraced and gotten benefits from enterprise architecture like Procter & Gamble, Tetra Pak, and Maersk. At P&G’s, IT is reporting to the CIO but he is also the President of Shared Services. At Maersk and Tetra Pak, it's the Head of Global Business Processes.

Once we get CIOs either in charge with more of a business role and they are in charge of process, and of the technology, or are reporting to a COO or head of business process, head of business transformation, or head of shared services, then we know what it is we’re architecting, and the whole organization is designed so that architecture is a critical element.

But in practice, what we’re seeing is more CIOs reporting to someone who is, in fact, in charge of designing the architecture of the organization.

I don’t think that title-wise, this is ever going to happen. I don’t think we’re ever going to see a CIO report to chief enterprise architect. But in practice, what we’re seeing is more CIOs reporting to someone who is, in fact, in charge of designing the architecture of the organization. By that, I mean business processes and its use of data. When we get there, first of all, we will transform to get to that point and secondly, we’ll really start seeing some benefits and real strategic impact of enterprise architecture.

Gardner: Madhav, at Ciena, do you see that this process-level capability around enterprise architecture is what's occurring, even if the titles are not aligned that way or the org chart doesn’t point to the CIO reporting to an architect. Is architecture in practice elevating a process orientation to this capability set that therefore fosters better transformation?

Naidu: Definitely. Some progress has been happening, especially what Jeanne was mentioning about the business process changes itself, rather than just bringing the systems and customizing it to our needs, and rather than transforming our business processes so that they match industry standard.

That’s definitely happening, and the architecture team has engaged and is influencing that process. But that said, the maturity level takes quite a few years, not only at Ciena, but in other places too. It will take some time but this is happening.

Gardner: Len Fehskens, we have a mentality in our organizations that architecture isn't that important, and there's some cynicism and skepticism around architecture, and yet, what we’re hearing is it's not in name only. It is important, and it's increasingly important, even at higher and higher abstractions in the organization.

How to evangelize?

How then do you evangelize or propel architectural thinking into companies? You may have been concerned that advancement of architectural thinking would have been impelled when we conflate enterprise architecture into transformation, but until then, what should you do? How do you get the thinking around an architectural approach more deeply engrained in these companies?

Fehskens: Dana, I think that’s the $64,000 question. The fundamental way to get architectural thinking accepted is to demonstrate value. I mean to show that it really brings something to the party. That’s part of my concern about the conflation of enterprise transformation with enterprise architecture and making even bigger promises that probably can't be kept.

The reason that in organizations who’ve tried enterprise architecture and decided that it didn’t taste good, it was because the effort didn’t actually deliver any value. Certainly the advice that I hear over and over again, and that I myself give over and over again, is: “Don’t try to boil the ocean.” Start small and demonstrate success. And again, there's that old saw that nothing succeeds like success.

The way to get architectural thinking integrated into an organization is to use it in places where it can deliver obvious, readily apparent value in the short-term and then grow out from that nucleus. Trying to bite off more than you can chew only results in you choking. That's the big problem we’ve had historically. There are all these clichés and the reason of clichés is because there's certain amount of truth to them about your reach exceeding your grasp, for example.

It’s about making promises that you can actually keep. Once you've done that, and done that consistently and repeatedly, then people will say that there's really something to this. There's some reason why these guys are actually delivering on a big promise.

Trying to bite off more than you can chew only results in you choking. That's the big problem we’ve had historically.

Rouse: Can I offer something, another perspective?

Fehskens: Yeah, please do go.

Rouse: We ran a study recently about what competencies you need to transform an organization based on a series of successful case studies and we did a survey with hundreds of top executives in the industry.

The number one and two things you need are the top leader has to have a vision of where you’re going and they have to be committed to making that happen. Without those two things, it seldom happens at all. From that perspective, I'd argue that the CIO probably already does report to the chief architect. Bill Gates and Steve Jobs architected Microsoft and Apple. Carnegie and Rockefeller architected the steel and oil industries.

If you look at the business histories of people with these very successful companies, often they had a really keen architectural sense of what the pieces were and how they needed to fit together. So if we’re going to really be in the transformation business with TOGAF and stuff, we need to be talking to the CEO, not the CIO.

Gardner: Jeanne Ross, let’s focus on what Bill just said in terms of the architecture function really being at the core and therefore at the highest level of the organization.

Corporate strategy

Ross: I totally agree. The industries and companies that you cited, Bill, instinctively did what every company is going to need to do in the digital economy, which is think about corporate strategy not just in terms of what products do we offer, what markets are we in, what companies do we acquire, and what things do we sell up.

At the highest level, we have to get our arms around it. Success is dependent on understanding how we are fundamentally going to operate. A lot of CEOs have deferred that responsibility to others and when that mandate is not clear, it gets very murky.

What does happen in a lot of companies, because CEOs have a lot of things to pay attention to, is that once they have stated the very high-level vision, they absolutely can put a head of business process or a head of shared services or a COO type in charge of providing the clarification, providing the day-to-day oversight, establishing the relationships in the organizations so everybody really understands how this vision is going to work. I totally agree that this goes nowhere if the CEO isn’t at least responsible for a very high-level vision.

Gardner: So if what I think I'm hearing is correct, how you do things is just as important as what you do. Because we’re in such a dynamic environment, when it comes to supply chains and communications and the way in which technology influences more and more aspects of business, it needs to be architected, rather than be left to a fiat or a linear or older organizational functioning.

So Bill Rouse, the COO, the chief operating officer, wouldn’t this person be perhaps more aligned with enterprise architecture in the way that we’re discussing?

We can't find a single instance of a major enterprise transformation in a major company happening successfully without total commitment of top leadership.

Rouse: Jeanne makes a good point. Let's start with the basic data. We can't find a single instance of a major enterprise transformation in a major company happening successfully without total commitment of top leadership. Organizations just don’t spontaneously transform on their own.

A lot of the ideas and a lot of the insights can come from elsewhere in the organization, but, given that the CEO is totally committed to making this happen, certainly the COO can play a crucial role in how it's then pursued, and the COO of course will be keenly aware of a whole notion of processes and the need to understand processes.

One of the companies I work very closely with tried to merge three companies by putting in ERP. After $300 million, they walked away from the investment, because they realized they had no idea of what the processes were. So the COO is a critical function here.

Just to go back to original point, you want total commitment by the CEO. You can't just launch the visionary message and walk away. At the same time, you need people who are actually dealing with the business processes to do a lot of the work.

Gardner: Madhav, at the Ciena, how do you view the relationship between what you do as a lead enterprise architect and what your operations officer does? It might not be that title, but the function of operations management and oversight. How do they come together?

Not role, but involvement

Naidu: Not by role, but by involvement. There are quite a few business executives engaged in the business process identification and changes. Many of them report to the top executives in the business line. That’s what the current setting right now. We're pretty happy that that kind of support is coming from many of the executives and business teams. That said, there is no formal relationship in terms of reporting and all.

Gardner: Len Fehskens, you mentioned a while ago that finding success and demonstrating value are instrumental to promulgating the use of architecture and understanding the benefits of architecture. Would operations, rather than just technology, be a target than for how you can demonstrate that? The architecture processes might be the sweet spot in some of the thinking now about where to demonstrate that enterprise architecture is the way to go.

Fehskens: Absolutely. And this ties into another thing we need to be aware of, which is that the need to transform, the motivation for enterprise transformation, doesn’t always come from disruptive technologies. There was a really interesting talk last week at the conference on sustainable enterprise architecture, and they made the point that there are lots of major disruptions that have nothing to do with technology.

In particular, in a world where resources are becoming increasingly scarce, and impact on the environment is a significant concern, the drive to transform an enterprise will often come from other places than the appearance of disruptive technologies. There will be disruptions of all sorts that have to be dealt with. The transformation in response to those isn't going to come out of the IT organization. It's going to have to come from other organizations.

The idea that we talked about at the beginning of the discussion was that architecture is a very powerful means for figuring out what kind of transformation is necessary, and how to effect it, means that we need architectures that aren’t about IT, we need to understand driving architectural approach to the other considerations that an enterprise deals with.

Architecture is a very powerful means for figuring out what kind of transformation is necessary, and how to effect it.

As Bill said, historically it's been the case that the lead architects in the most successful organizations were the guys who had the vision and the guys who were at the very top of the organizational structure who created this organization in the very first place. And they weren’t IT guys. Bill Gates, in particular, didn’t build Microsoft around its IT capability. He built it around a whole bunch of other ideas that were really business ideas, not IT concepts. So, yeah, absolutely.

Gardner: I'm afraid we'll have to wrap it up. I’d like to go once around the panel with a pretty direct question and if you could perhaps provide your succinct thoughts. What is the relationship between enterprise architecture and enterprise transformation? Let's start with you first, Jeanne.

Ross: I'd say the relationship between enterprise architecture and enterprise transformation is two-way. If an organization feels the need for a transformation -- in other words, if it feels it needs to do something -- it will absolutely need enterprise architecture as one of the tools for accomplishing that.

It will provide the clarity the organization needs in a time of mass change. People need to know where they're headed, and that is true in how they do their processes, how they design their data, and then how they implement IT.

It works just as well in reverse. If a company hasn't had a clear vision of how they want to operate, then they might introduce architecture to provide some of that discipline and clarity and it will inevitably lead to a transformation. When you go from just doing what every individual thought was best or every business unit thought was best to an enterprise vision of how a company will operate, you're imposing a transformation. So I think we are going to see these two hand-in-hand.

What's the relationship?

Gardner: Bill Rouse, same question, what in your view is the relationship between enterprise architecture and enterprise transformation?

Rouse: I think enterprise transformation often involves a significant fundamental change of the enterprise architecture, broadly defined, which can then be enabled by the enterprise IT architecture.

Gardner: Madhav, also to you the same question, relationship between EA and enterprise transformation?

Naidu: Like I mentioned in the beginning, one is end, another one is means. I look at the enterprise transformation as an end and enterprise architecture providing the kind of means. In one way it's like reaching the destination using some kind of transportation mechanism. That’s how I look at the difference between EA and ET?

Gardner: Len, I know you’ve gone out at some length about this, but perhaps the elevator version. How do you view the relationship between EA and enterprise transformation?

Enterprise transformation often involves a significant fundamental change of the enterprise architecture, broadly defined, which can then be enabled by the enterprise IT architecture.

Fehskens: One of the fundamental principles of architecture is taking advantage of reuse when it's appropriate. So I'm just going to reuse what everybody just said. I can't say it better. Enterprise architecture is a powerful tool for effecting enterprise transformation. Jeanne is right. It's a symmetric or bidirectional back-and-forth kind of relationship, and what Bill and Madhav said applies as well. So I really don't have anything to add.

Gardner: Well, I found it very interesting. I have a newfound appreciation for architecting how you do something better enables you to decide what it is that you're going to do in the future, and there is an interesting relationship between how and what that perhaps escape some folks. I hope they recognize that a little bit more deeply.

You’ve been listening to a sponsored podcast discussion in conjunction with The Open Group Conference in San Francisco, the week of January 30th, 2012. We've enjoyed our discussion with our guests and I’d like to thank them and call them out individually one more time.

Len Fehskens, the Vice President of Skills and Capabilities at The Open Group. Thank you, Len.

Fehskens: Thank you, Dana.

Gardner: Madhav Naidu, Lead Enterprise Architect at Ciena Corporation. Thanks so much.

Naidu: It's been my pleasure.

Gardner: Bill Rouse, Professor in the School of Industrial and Systems Engineering as well as the College of Computing and also Executive Director at The Tennenbaum Institute, all at the Georgia Institute of Technology, and Principal at Rouse Associates. Thank you, Bill.

Rouse: Thank you. I enjoyed it.

Gardner: And Jeanne Ross, Director and Principal Research Scientist at the MIT Center for Information Systems Research. Thanks so much for your input.

Ross: Thank you. Great talking with you all.

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

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

Transcript of a sponsored podcast discussion on the respective roles of enterprise architecture and enterprise transformation and the danger --and opportunity -- of conflating the two. Copyright Interarbor Solutions, LLC, 2005-2012. All rights reserved.

You may also be interested in:

• Open Group Conference Speakers Discuss the Cloud: Higher Risk or Better Security?
• Capgemini's CTO on Why Cloud Computing Exposes the Duality Between IT and Business
• San Francisco Conference observations: Enterprise transformation, enterprise architecture, SOA and a splash of cloud computing
  
• MIT's Ross on how enterprise architecture and IT more than ever lead to business transformation
• Overlapping criminal and state threats pose growing cyber security threat to global Internet commerce, says Open Group speaker
• Enterprise architects play key role in transformation, data analytics value -- but they need to act fast, say Open Group speakers
  
• Exploring Business-IT Alignment: A 20-Year Struggle Culminating in the Role and Impact of Business Architecture