B & EA EXECUTIVE REPORT VOL. 8, NO. 6
  

Read the Executive Summary

What if enterprise architecture (EA) enabled the organization to flex in pace with the rhythm of its strategy process, facilitating the ongoing renewal of differentiating capabilities, allowing it to constantly maintain a position at the forefront of the competitive order? That would indeed be something to get excited about. But this just sounds like more hype, and we are learning to be leery of big claims as to the strategic importance of anything to do with IT.

Yes, EA has its roots in IT. And "IT doesn't matter" [2] in the strategic differentiation game -- or does it? Certainly, Nicholas Carr has been associated with increased scrutiny of IT spending, although the downturn in the economy also deserves some credit for the increased cynicism about IT benefits, conservatism regarding IT spending, and exhortations to show value and better align IT with the business.

Yet jumping to the conclusion that IT is nonstrategic could be dangerous. Consider the example set by Wal-Mart: It has proven that what everyone in mass merchandizing has to do, namely distribution and inventory management, can be done so well that it can become a tremendous competitive advantage. Though its competitors have access to much the same technology, labor pool, and value network, Wal-Mart puts these factors together in a way that works superbly for its competitive strategy.

Information technology is used to underpin various strategies from industry-beating reductions in inventory costs, to customer delight through individualized tailoring of the consumer experience, to new products or services that shake up the competitive order [1]. That is, technology is fundamental to differentiating capabilities, whether we choose to compete on operational excellence, customer intimacy, or innovation. At the same time, IT is also fundamental to business activities in which we are not choosing to excel but merely opting to do well enough.

Thus, information technology is a tool. In some places we may use this tool to maintain parity with our competitors, and in others we may use it to build capabilities that are critical to our strategic differentiation strategy.

OVERVIEW

In broad outline, this Executive Report confronts the realities of the IT world that EA grew up in: a world of legacy systems, a world of sincere efforts to do good for the business, and a world where the business-IT alignment gap exists because there is a pervasive assumption that technology is a tactical rather than a strategic concern. In this report, we explore the evolution of enterprise architecture, considering whether EA as an IT practice can be a strategic differentiator. We expand the concept of enterprise architecture to business capabilities architecture and present a new framework for strategy that brings capabilities, rather than simply processes, into the spotlight of the strategy creation and execution process. This strategy framework highlights the importance of capabilities in shaping the organization's identity and in delivering differentiating value propositions that give the organization highly leveraged advantages in the arenas in which it competes.

Architecture is about optimizing across boundaries to achieve system goals; it is the translation of strategy into implementation. Architects are the bridge between the business and technical communities. In our consulting and training work, wherever we make these points, they are met with agreement -- this is the role of architecture and architects. We work with clients across the spectrum, from huge Fortune 100 companies to smaller companies working in niche markets. Despite broad agreement about the role of architecture, the biggest chasm that remains is between the business leaders and the technology community.

The bridge that will span this chasm must be built from both sides. Business leaders need a more effective strategy-setting process that includes high-level architects and takes into account the role of technology in creating strategic advantage. By the same token, technologists need to enhance their strategy skills; they must learn the language and concerns of business leadership so that they can be effective in translating business strategy into technical strategy and in leading the execution of that strategy. Because this is the big frontier that we see in addressing the business-IT alignment gap, and because this is critical to tuning up enterprise architecture so that it can indeed play a role as strategic differentiator, this is the area that we focus on in this report.

BACKGROUND

In this section, we set the scene for the report, briefly articulating what we mean by strategic differentiation and considering the IT context and pressures out of which EA emerged.

What Is Strategic Differentiation?

Product differentiation deals with competitive distinction at the level of a product. It is the domain of product strategy. Strategic differentiation is what differentiates organizations across their products or services; it provides broader leverage than simply differentiation at the point of a particular product.

Strategy leaders are recognizing that constantly looking to edge out competition on a product-by-product, feature-by-feature basis creates an incrementalist perspective that does not make for long-term advantage. It is too easy for competitors to imitate and surpass incremental product improvements. For enduring competitive advantage, the organization needs to seek leverage across its products and/or services and to create strategic capabilities that are hard to imitate because they rely on a mix of process, technology, skills, resources, facilities, culture, and even history.

Differentiation at the company level depends on the capabilities that the company chooses to excel at in order to create a compelling value proposition that surpasses that of each individual service or product release. If we want to work systematically to build strategic differentiation, we have to make it the focus of business strategy and effectively execute that strategy.

Frustration with IT

However, business executives often express concern that IT is not aligned with the business, creating disjunction with the strategic direction. Carr's article [2] got a receptive response largely because it was riding a wave of frustration among business executives at ever-increasing IT expenditures without corresponding increases in business value.

Again and again we hear "It takes 80% of our IT budget just to keep the lights on." It is costing more to maintain systems supporting day-to-day business operations, and, hamstrung by its legacy, IT is not able to adapt to changing business needs in the ever-shortening timescales that are driven by intense global competition.

Indeed, could it be that IT is becoming trapped in its own successes and its very willingness to be responsive to the business and provide value?

Trapped in Its Own Successes

Our problems began with the fast pace of change in the IT space. Much of the technology put in place even a decade ago has become obsolete, though often the business processes that these systems support are still around -- being reshaped, but still around. Even systems that are less than five years old are quagmires, imposing an enormous maintenance burden on the IT organization.

In most enterprises today, change in the environment is perceived and responded to at the grassroots level in the organization. Yes, this has the advantage of being responsive to change -- locally. The typical pattern is that someone recognizes a point problem and requests a point solution. But the same environmental change triggering this point solution is also triggering other point solutions across the enterprise, resulting in a myriad isolated, duplicated, but inconsistent efforts across the business.

Each quickie response to changes in the environment typically results in accommodations to the systems impacted. The result is inconsistent and incompatible infrastructure choices, inconsistent data definitions, and deteriorating software structure, with more and more tight coupling with each accommodation. The combined effect is that change is increasingly hard, thus increasingly slow and costly.

Our very attempts to be responsive to change yield chaotic systems that entangle our business and make it even harder to execute strategic change.

And so it is that we become hardwired to the past, with inflexible, brittle, aging, kludged-together systems. When the information lifeblood of a business becomes clotted in the morass of systems that have been shaped by attempts to keep up with the vicissitudes of our history, it becomes noticeable even at the highest levels.

Then business executives demand that IT be more agile and better aligned with the business, that is, better aligned with business strategy, and more responsive to change at the strategic level (see Figure 1). And so it should be. Ah, but it cannot be, when left to respond in a bottom-up way to demands at the leaf nodes of the organization.

Enter Enterprise Architecture

Enterprise architecture typically begins as a tactical response to a burning need to lay the foundation of technology standards that will allow enterprise concerns like productivity improvements, cost reductions, and system integration to be met. Once in place, enterprise standards still need a vigilant "watchdog" process and roles to keep the organization from chipping away at the progress being made toward simplifying and making the technology environment more coherent. But the opportunity shifts from plugging up the holes and saving the ship, to helping the organization set its course to greater success through a more strategically focused partnership between technology and the business.

EVOLUTION OF ENTERPRISE ARCHITECTURE

In its idealized form -- as in what is promulgated by industry analysts and consultants -- enterprise architecture has evolved during the past decade from enterprise architecture as technology architecture (EA = TA), to enterprise architecture as enterprise-wide IT architecture (EA = EWITA), to enterprise architecture as the architecture of the enterprise, encompassing business architecture along with enterprise-wide IT architecture (EA = BA + EWITA). At the same time, EA groups within leading organizations have moved through the same evolution, shaping the thinking of industry analysts and being shaped by them.

In the sections that follow, we consider the benefits gained as the scope of the EA practice is expanded.

EA = TA

Much of the early EA work focused on enterprise-wide technology (or infrastructure) architecture efforts, including early work by The Open Group Architecture Framework (TOGAF). Projects using this narrow concept of EA focused on establishing technology standards and principles and often extended to attempts to inventory the various technologies in use in the corporation (capturing the "as-is architecture").

In a previous Executive Report [1], we used the metaphor of the creation of the US Constitution. The effort underway to move toward a unified Europe provides another rich source of analogies. Thus, for example, we see the importance of standards in the progress from great fragmentation toward a more unified Europe. One key to the European vision of "a democratic, transparent, efficient Europe working to serve all Europeans" [3] was a common currency -- the euro -- and another was the creation of a common European Union (EU) passport and removal of border-control barriers between the "member states" of the EU.

Some organizations, such as Eli Lilly, have had EA efforts in place for a decade. They started with technology standards and consolidation, moving, for example, from 13 different e-mail systems to one. Even today, organizations just getting into EA tend to start with rationalizing the technology infrastructure of the business. This has tremendous implications for cost savings and productivity improvements, improving purchasing leverage, decreasing training costs, increasing employee mobility between projects and around the company, and so forth. It also lays the groundwork for expanding the scope of EA to achieve even more significant benefits.

EA = EWITA

Despite real gains, it became clear that the goals of EA efforts had to be tackled on a broader front, encompassing information and application solutions architecture, not just technology architecture. This shift allowed the EA team to address IT concerns that cut across business units, such as integration, interoperability, and security. By approaching information and application solutions from an enterprise perspective, we could go after problems like creating a "single view of the customer" as well as further cost savings by reducing duplication across projects through improved application portfolio management.

With this shift, enterprise architects now had the charter to look across projects, across business units, and across the global enterprise sprawl for opportunities to consolidate and reduce the maintenance burden, so that IT resources could be freed up from the time-consuming and costly business of tending to legacy systems duplicated across the business. A lot of "low-hanging fruit" (billing systems, payroll systems, and so on) has sprung up in each locale, each with its own idiosyncrasies, some important, but many that are not.

These may be obvious targets, but bringing them under central control is fraught with organizational politics, borne of vested interests and fears mixed with rational concerns that come with losing direct responsibility for a critical business-unit capability. And then there is the cost of creating the replacement system, which is higher due to the need to understand these concerns, address those that are true differences across the geographies or business units that need to be supported directly in the architecture, and address those that are seated in the human element in a way that brings these entities along rather than disenfranchising them and raising distress and discord.

EA = BA + EWITA

So far, we see a way out of the mess: standards, consolidation, and simplification; more disciplined approaches to system planning, funding, and development; and better risk management with fewer false starts. But to reach the goal of closer alignment between IT and the business, we must broaden our approach to EA still further to include business architecture.

Enterprise systems are socio-technical systems: they are not purely technology; they rely on people. By the same token, business processes are not purely conducted by people. They rely on information technology. This is why business process reengineering faltered until information technology was factored in. Likewise, we have realized that the potential of enterprise architecture is limited unless we incorporate business architecture along with enterprise-wide IT architecture into our approach to enterprise architecture.

Don't be fooled though. A "business architecture" produced by an IT team may document (IT's understanding of) business objectives and business processes and functions but is highly unlikely to be the active design and implementation of changes to the business process and structure. Since the business side of the organization has the charter to structure its people and processes, IT is not going to be very effective in imposing process designs and structural changes. Hence, the EA team needs to include key businesspeople who can lead business process change, along with senior technology architects who can lead significant technology change.

EA Scope Creates Opportunities -- and Challenges

The scope of EA is the enterprise. That is, it encompasses the various organizational units, be they different functions (marketing and sales, R&D, manufacturing, etc.) or business units.

By working across organizational boundaries, EA allows the organization to address issues such as shared access to information, common processes and tools, and reduced redundancy in development in order to lower the overall cost of development and increase the efficiency of the IT organization. These are things that cannot be addressed in organizational "silos" or "islands."

However, every time you work across organizational groups, and the more diffuse these groups are in their vested interests, the challenges inherent in organizational acceptance, politics, commitment, and so on, go up by orders of magnitude! ¹

Taking Stock: Is Enterprise Architecture a Differentiator?

In organizations that have been working to mature their EA practice during the past decade or so, many have reached the point where they have good processes in place for controlling the technology sprawl, introducing and governing standards in the infrastructure sphere, and working toward more architectural discipline in the planning, creation, and evolution of software solutions. They have established business process owners and are working toward partnering more closely with the business.

Now, if all organizations were doing this, and doing it equally well, we could hardly call it a differentiator. To the extent that some organizations have climbed the architecture maturity path earlier than others, they have an advantage at least until the others catch up. Of course, those who start the climb now can leverage the hard-won lessons of early learners and potentially avoid some of the stumbling blocks. Nevertheless, working across different organizational groups with their diverse and divisive vested interests is hard and does not happen naturally, or organically, on its own. It has to be worked at. It has to be invested in. It has to get attention. Some will succeed and have an advantage over those that fail and those that do not try.

An effective EA practice means that the organization has had to transcend its parochial tendencies and find a way to work well across organizational boundaries.

Why Not Centralize Everything? Why Not Decentralize Everything?

Large organizations typically have pendulum swings from increasing fragmentation into customer-focused units to more integration across related market segments. We know from bitter experience that each has its costs and benefits. More fragmentation but higher market-segment focus leads to greater customer intimacy and innovation around the customer but increases duplication, inconsistency, and integration problems. Conversely, while more integration leads to higher synergies across the business, it tends to dilute customer intimacy and slow processes, especially those that rely on building consensus across groups.

Bottom-up decisions optimize the parts because that's the scope of consideration and decision control. But the optimal overall solution for the system is not simply the sum of the optimal solutions for each of the parts working in isolation. Some of the system properties must be addressed at the system level first in order to make system-wide tradeoffs that yield a better overall solution. This is the heart of why we architect, whether it is an application, a solution, or an enterprise. The organizational challenges just go up by orders of magnitude as we increase the scope of the system.

So, enterprise architecture cannot simply be another pendulum swing toward centralized control. We can't do everything as a joint effort! We have to ask: Why do this at the enterprise level? What does it gain us? Is this an enterprise priority? Can we get this by some other means? We have to pick strategically where to focus enterprise-scope collaborative activity.

ENTERPRISE ARCHITECTURE AND BUSINESS CAPABILITIES

Let us back up just a moment and clarify what we mean by architecture. Architecture addresses the overall structure, creating a big-picture view of the system, which in this case is the enterprise. It identifies the primary elements of the system and the relationships among the elements. Most importantly, it addresses the cross-cutting concerns; that is, the concerns that have broad, if not system-wide, impact (e.g., integrated customer relationship management). These are concerns that could not be addressed effectively at a more narrow scope of visibility and decision authority.

What are the elements of the enterprise that make sense to consider, should we be audacious enough to think that the enterprise could be designed or that its design could be consciously and systematically addressed and improved? These elements would include:

• Business processes
• Organizational structure
• Technology/systems and solutions
• Information 

These all come together in business capabilities. Capabilities are not processes -- alone. A process delivers a capability using a mixture of people (knowledge, skills, and talent), technology (computing technology, application solutions, and data), and financial and physical resources (capital, facilities, and so on). The focus of capability design is on the outcome and the effective use of resources to produce a differentiating capability or an essential supporting capability. Differentiating capabilities are those that create competitive advantage; supporting capabilities are those that enable the business to function.

EA recognizes that the organization is a system, composed of constituent elements that interact to achieve goals that the elements on their own could not achieve. You cannot solve every detailed problem at once -- you cannot hold complex systems "in your head." You need to find effective ways to decompose the problem. Focusing on business capabilities that support business strategy first, then delving into the design of those capabilities, forms an effective way to consider people, process, and technology together.

THE RELATIONSHIP BETWEEN STRATEGY AND ENTERPRISE ARCHITECTURE

Business strategy determines where and how we will compete. We cannot do everything, or at least we cannot do everything well. To be great, we have to choose where we will differentiate and decide where we will accept parity with others. This is not settling for mediocrity through compromise, but rather setting our organization up to achieve excellence by paying attention to what matters.

Effective strategy execution means that the choices made in the strategy process guide decisions throughout the organization so that the whole behemoth moves in the direction set by the strategy.

If the business nirvana we seek is alignment between IT and the business, with our technology adapting in synchrony with strategic direction, the technical people need to know what the strategy is. Thus, (1) we need to have one (a strategy, that is); and (2) it must be communicated effectively to the technical community.

But let's bare the bones here. Information technology -- infrastructure and application solutions -- takes huge investments to put in place and huge investments to change. It is not infinitely pliable. And the human component of our sociotechnical systems can be the hardest to change.

Choreographing the dance of change is one thing, and it is hard enough. Teaching elephants to dance [9] is quite another.

The point, then, is that any old strategy that we expect to tune up as we learn more is not sufficient. In the 1960s, Russell Ackoff (pioneer and leader in the field of systems thinking) lamented that executives were driving the organizational train from the caboose. But if we get out and lead from up front, we need to have a clear sense of where to go and how to get there. Our strategy process must produce an excellent strategy, one that is founded on a good understanding of who we are and what we are good at, and one that understands what it will take to become something else or head in a new direction.

That's it! The strategy process needs to be informed by our business capabilities. And it needs to have input from those who have insight into what it will take to reshape these capabilities and introduce new ones. The strategy process needs to be informed by enterprise architecture and enterprise architects!

But, personally, we have worked with a great many architects, from junior to very senior, across industries and geographies. It is astonishing how many do not know what their business strategy is beyond a few objective statements. They have no sense of context, no sense of how the strategy has been shaped by the competitive landscape. Generally this is because the business leaders simply do not see any reason to include the technologists in strategy discussions, nor even to communicate strategy to them in any systematic way. We use a classic Feynman story to make the point here.

When Richard Feynman took over leadership of a team of mathematicians working on critical research for "the bomb," he found that the team had no knowledge of what it was working on. Each member of the team was given a problem, and each took some three months to solve it. Feynman insisted he get permission to tell his team what it was working on. Feynman generally prevailed, as he did in this case, and after the team members were told, their productivity increased to three problems a month! Knowing the context provides motivation as well as a mechanism to make more informed choices.

In a world where technology is a huge component of any strategic differentiation strategy, the exclusion of technologists from the strategy table is an example of history shaping our ability to compete in the future. The strategy is not informed by those opportunities and threats that the technologists are better positioned to perceive, and the technologists have no grounding in the strategic context. That is, the strategy creation and execution process is broken.

To understand why this is a significant flaw, consider this: How long do architectures tend to last in your environment? How long have the major information systems been around? How old are the architectural roots of your principal products? We have already seen that aging systems, with their corroded, brittle architectures, constrain what the business is able to do. Still, we have systems in place because they enable our business to function. Yes, architecture constrains and enables strategy (see Figure 2). We would like strategy to drive architecture, for how else can architecture be the implementation of strategy and the route to better alignment between IT and the business? But we cannot expect this to be the case if there is a gulf between strategy setting and architecture.

Figure 2 -- The relationship between strategy and architecture.

Still, for enterprise architecture to be all that it can be, and for enterprise architects to make the contribution we hope to make, we need to be capable of making a valuable contribution to the strategy process. Our technical backgrounds do not typically equip us with strategy grounding. Which is not to say we should slight our technology backgrounds. Our very depth of insight there is what makes our contribution critical to the strategy process. However, to allow us to segue from technologist to technology-savvy strategist, we do need an accelerated introduction to business strategy, and that is what is covered in the next section of this report.

VISUAL STRATEGY FRAMEWORK

We applied the great architectural principle of "simplify, simplify, simplify" [11] to strategy and came up with an essential framework (see Figure 3). This strategy framework has proven useful not only to architects, but also to the business leaders with whom they partner. Indeed, it provides strategists with a clear, yet integrated, approach to strategy that is highly actionable. It leads very naturally to execution by providing a path to rollout via the management network and the network of technologists. This is the critical chain referred to earlier that is broken and that must be fixed to make strategy execution work effectively.

Figure 3 -- Strategy framework.

Our business strategy determines the unique way by which we will create value and hence competitive advantage. In particular, it establishes:

• Our unique identity -- who we are and what distinguishes us from others
   
• Our differentiating value proposition -- what value will make us stand out in the market
   
• Our differentiating capabilities -- what set of capabilities will enable us to deliver this unique value
   

This framework lays out how our company will compete and what capabilities we need in order to do so. With the business strategy formulated in these terms, enterprise architects have the input they need to design the business capabilities architecture that will implement the business strategy.

In the following sections, we explore the elements of this framework.

Identity

Organizational identity determines the organization's defining purpose, the scope of value contribution, and the essential properties or characteristics of the business. An organization's identity incorporates its fundamental beliefs, values, and norms that underscore the organization's culture, together with the business mission and vision, and the principles we share to guide our behavior in our day-to-day activities so that they are consistent with our larger purpose and value system.

Identity and competitive strategy are not unrelated. If the two are inconsistent, then there will be a battle to see which dominates: will the way we compete shape our identity, or will our identity shape how we compete? As this battle plays out, we will likely confuse customers and employees and others that influence our destiny, such as investment analysts who impact our stock value.

On the other hand, a unique and compelling identity creates tremendous strategic advantage through:

• Strong internal alignment, which means we can grant high empowerment to innovate to everyone in the organization and we can attract the right people.
   
• Strong market alignment, because we simplify the customer's choice in a confusing market, creating strong loyalty. We are also able to better manage our relationships in the value network, strengthening our identity with reinforcing relationships rather than diluting it because our organization and partners do not have a solid sense of who we are. 

Organizational identity is the most stable of the strategy elements, as we do not want to be shifting our identity and confusing customers -- and our own people -- with any great frequency. At the beginning of the strategy process, it is nonetheless important to revisit our core identity because:

• We need to make sure we have one!
   
• Identity gets eroded, especially as corporations expand and diversify. When this happens, even our core identity needs to be revisited and revitalized.
   
• The world changes. From time to time, an organization will need to reshape its core identity to meet a whole new set of challenges. Organizations that succeed last longer than people. Yet, like people, organizations age. In this era, the passage of time brings with it astounding change in diverse facets of the environment, yet aging in organizations is often accompanied by increasing myopia, ossification, and frailty in key systems, as well as growing inertia; our change receptors are dulled, and our ability to respond to change is reduced.

Yet organizations have a capacity for regeneration and renewal that transcends biological organisms. Whether an organization can successfully regenerate itself in the face of a changing environment depends very much on its ability to shift its identity. This is hard to do, but not impossible.

Samuel J. Palmisano, CEO of IBM, tells a story [5] that illuminates both the danger of leaving our core identity unquestioned in the face of a changing world and the role of a stable identity in facilitating adaptations through generations of strategic change. In 1914, Thomas Watson Sr., founder of IBM, established three values called basic beliefs: respect for the individual; the best customer service; and the pursuit of excellence. These values survived through the decades into the age of IBM's early domination of the computer business. But in this age of rampant success, the values became distorted. "Respect for the individual" became job entitlement; "the pursuit of excellence" became arrogance. When the market shifted, IBM was blindsided and almost went out of business. Values had become part of the problem.

Louis V. Gerstner Jr., CEO of IBM from 1993 until March 2002, managed to lead IBM through a renaissance, turning around the business. Palmisano's challenge was to maintain that momentum when he took over leadership in 2002. He recognized the centrality of values. He embarked on a brave adventure -- a corporate ValuesJam on the company intranet, reaching some 50,000 IBMers in which IBM employees around the world were invited to participate in a discussion of what the company represented to itself and to the rest of the world. The result was a revitalized set of values that would help IBM align its very distributed workforce, recognizing that in its service business, employees have to be consistent with IBM's brand promise, and that in its solutions business, employees from distributed, independent business units have to work together to pull off customized solutions. In the words of Palmisano [5, p. 63], "I believe values can once again help guide us through major change and meet some of the formidable challenges we face."

We need to evaluate the other elements of our strategy to ensure that they are consistent with our identity. When we find inconsistencies, we need to reevaluate the more dynamic components of our strategy -- our value propositions and the capabilities we need to deliver them. And we may even have to revisit and question whether our identity needs to be reshaped to better fit the coming generations of organizational reality.

Identity and Competitive Strategy

Identity can be a key element of competitive strategy. To illustrate this, let's look at the printer market, where there are some 52 printer manufacturers. If we restrict our focus to photo-quality printers, there are at least nine manufacturers worth taking a look at; HP alone has 12 inkjet photo printers aimed at the home market. An exhaustive list of options in this market is stupefying. The consumer simply cannot parse and systematically evaluate all the options. But value is in the eye of the beholder. For some, value may be in simplifying the purchase choice set: for example, whether a customer says, "I trust HP to stay with front-runners on innovative features" or "I trust HP quality," the conclusion is likely to be something like "so I can limit my choices to selecting among HP's options for the printer that suits my printing requirements." By creating an identity that is established firmly in the perception and the experience of the consumer, the organization builds customer loyalty and simplifies consumer choices. The HP Way [10] is all about building and sustaining such an identity, articulating core values in the areas of innovation, customer attentiveness, and quality. These values align employee behavior so that the organization creates the products and experiences that underscore consumers' perceptions, and identity-as-intended becomes identity-as-realized in the marketplace (see Figure 4).

Figure 4 -- Identity interacts with value propositions.

If organizations want identity to drive consumer choices, everything they do needs to be consistent with that identity. Slipups on product quality in one part of the business mar the identity and impact all other parts of the business. Businesses are not yet consistently treating a customer as the same customer at all the different points in which the customer is in contact with the business. But customers are already there -- in all of their interactions with the many and diffuse parts of a business, they view it as one business. Shoddy treatment by customer service in one area shakes customer confidence, damaging the customer's purchase decisions in quite different areas of the business.

If organizations want to have a coherent, cohesive identity across the entire business, it cannot be a matter of "whatever happens to percolate up" from the leaf nodes of the organization. This is what outstanding corporate leaders, such as David Packard, cofounder of Hewlett-Packard [10], and Samuel Palmisano of IBM, instinctively understand. An identity that is a rallying point, inspiring consistent behaviors throughout large and diffuse organizations, starts with leadership interventions and builds with employee involvement and ownership of values and principles. These actions make identity not just an idea but a way of living for the entire organization.

Identity and Capabilities

One of the biggest factors being overlooked by a slew of corporate executives in the current business world is the role played by the culture and climate of the organization in enhancing -- or debilitating -- organizational capability. As a result of their oversight, the absolutely critical role of climate in corporate creativity is being highlighted. Once powerfully innovative companies are being hamstrung by a malaise or corporate depression resulting from unpopular executive choices. Depressed organizational cultures result in a quickening death spiral for the organization, as the depression makes results worse, which heightens the sense of executive panic and corporate churn, increasing depression and worsening results.

Value Propositions

Organizations do not just compete for customers -- i.e., for revenue. They also compete for capital and stock value. Further, organizations compete for talent in a world where knowledge work and innovation is ever more critical to business endeavor. This competition for talent has been reshaped in the past few years of corporate pruning, and value partners figure even more prominently than ever before. We are realizing that we have to view the entire value network, including but not simply limited to the supply chain and the channel, as value partners we rely on and compete for relationships with. In all these avenues of competition, beliefs or perceptions play a major role in determining the degree of success, and hence the shapers of belief -- the media in all its various forms from traditional to blogs -- play a striking role too.

To the extent that we compete for capital, revenue, and talent, we need to be able to articulate a compelling and unique value proposition to shareholders, to customers, and to employees and partners in our value network. Specifically, the following strategies must be defined:

• The financial strategy must establish for the strategic planning horizon: what value will we provide to our owners/shareholders?

• The competitive strategy must establish: what unique value will we provide to our customers in each of the market segments we target? In addition, the competitive strategy should also investigate and where relevant establish: what value will be added by other players in the value network?

• The capabilities strategy should investigate and where relevant establish:

  • What value will we provide to our channel partners who help us reach customers in each of the market segments we target?

  • What value will we provide to suppliers who will provide key resources and partners who will provide key capabilities?

  • What value do we offer to attract and retain the talent we need to execute our competitive and/or financial strategy?

Figure 5 shows how these strategy elements relate to the strategy framework. ²

Figure 5 -- Relationships within the strategy framework.

Reaching the value proposition and associated financial goals of the financial strategy relies on an effective competitive strategy, which in turn relies on having the capabilities in place to deliver the customer value articulated in the competitive strategy. The fulcrum on which all this hinges, then, is the competitive strategy.

Competitive Strategy: Differentiating Customer Value Propositions

To create a good competitive strategy we need to understand what is the difference that makes a difference. The following questions must be asked:

• What is basic? In essence, in order to compete at all, what are the requirements we need to satisfy?
   
• What will differentiate us from the competition? What is our unique value proposition?

To create a compelling and unique value proposition, we need to understand what would be compelling and unique from the perspective of our customers and of our industry. That is, what would differentiate our products or services and make our offering stand out from the plethora of other alternatives available to customers?

The first step is being clear about our target market or markets. Just who are our customers, and who do we want our customers to be? Are we targeting the growing number of higher-income professionals in the knowledge economies of the developed world? Are we targeting emerging markets in the underdeveloped world? Are we targeting cost-sensitive segments in mature markets? Are we targeting the high-margin few or the low-margin masses? Being clear about our market focus, and characterizing the customers in those segments, is an obvious precursor to understanding what our customers value. But too often we focus on what we are able and willing to offer, rather than on who our customers are and what they need and value, and as a result we miss the obvious.

To create a compelling value proposition, we need to understand what our customers value: what factors into their decisions as they make their choices in the market? When we change our focus from what we think customers ought to want to what they actually value we are surprised by what we find out. For example, the Royal Bank of Canada (RBC) thought customers wanted convenient banking and invested heavily in products and services to this end, but when the bank went to the customer base to find out what customers valued, it found that customers did not choose a bank based on convenience. What customers wanted was a bank that cared about them, valued their business, and recognized them at their various points of contact with the bank. RBC reoriented itself to focus on delivering this value, with astonishing results [4].

To create a unique value proposition, we need to understand what others are doing: how do we distinguish ourselves, given what our competitors are good at and the value they bring to the market segment? Which is not to say that we should be spending so much time looking over at what our competitors are doing that we fall flat on our face. Our first order of business is to pay attention to what our customers value and understand what our competitors are doing so that we can offer something compelling and distinct from them, not so that we can move a smidge faster or offer this or that incrementally different feature. Competitor imitation and incremental innovation can only be a successful strategy if along some other dimension we offer customers something they find distinguishing, so that our products or services stand out from the complex multitude of options customers face.

In addition, the channel limits the options presented. In the example of shopping for a printer, if I shop at a warehouse store like Sam's Club, my choices are restricted to a selection of printers targeted at small businesses and home offices. If I shop at Wal-Mart, I am restricted to lower-end products from mainstream manufacturers. At the same time, the Wal-Mart powerhouse is notorious for squeezing margins for the privilege of shelf space. If mass distribution through the Wal-Mart engine is the key to revenue in your strategy, running with the features pack and trimming costs at every turn is far more likely to win than trying to out-innovate the competition and running up costs in the process.

We need to understand the role others play in enhancing value to our customers and would-be customers. We also need to understand our own capabilities, so that we can assess what value propositions are within our reach and what would be an uncontrollable stretch for us. And we need to identify and explore industry, market, and technology trends to better assess opportunities to provide novel or enhanced value within the strategic planning horizon.

Hence, to determine the vectors of differentiation we need to understand (see Figure 6):

• Our industry. How is value transformed by the various players in the industry? What changes can be anticipated?
   
• Our customers. What is the structure of our customer base? What characterizes the market segments in terms of what customers value?
   
• Our competition. What is the competitive landscape? What are competitors' strengths, problems, opportunities, and threats?
   
• Our own business. What are our own capabilities and opportunities?
   

Figure 6 -- Articulating our value proposition.

We use a number of tools, with an emphasis on visual models used in graphical facilitation ³ of groups, to support our analysis as we develop value propositions. These include value network maps, context maps, trend projections and scenarios, and strengths, weaknesses, opportunities, and threats (SWOTs).

Capabilities

Once we have articulated what value propositions will distinguish our business and be the basis for competitive advantage, we need to identify what capabilities ⁴ we need in order to:

• Create this value.
   
• Deliver this value.
   
• Capitalize on this value.
   

Strategy maps [6] are a useful tool for exploring what capabilities are needed to support the value propositions in the competitive strategy and the financial strategy. They are also good for communicating the strategy and showing how other organizational elements will contribute to the strategy.

We also find that a Kano-type model ⁵ is as valuable for business strategy as it is for product strategy. Such a model indicates that we need to have in place minimum success factors as well as differentiators to delight customers. The minimum success factors are the capabilities and capability levels that are essential for doing business in our industry. Our differentiating capabilities distinguish us from competitors, and our competitive position is protected if these differentiators are hard to emulate. Strategy needs to take both into account. Ensuring we have the minimum success factors in place simply positions us to play a role in our industry, and we would at best only be at parity with our competitors. On the other hand, if we just pay attention to differentiators, we are unlikely to succeed because we will not have the right basic capabilities in place. Both take resources and attention if we want success to be the result of strategy rather than luck or heroics.

The need to think strategically, that is the need to think about where to go and how to succeed in getting there, has to contend for attention with day-to-day operational pressures. After all, we have to survive the short term to be around for the long term. By identifying the minimum success factors for our business over the planning horizon, and where our current capabilities fall short of minimum levels for competitiveness, we can set strategic direction for changes at the operational level.

Let us illustrate this with an example. If we are a bank, we cannot compete without ATMs. This is so fundamental that it should not even show up in strategic planning, right? Well, what if our ATM system is 20 years old, monolithic, and fragile, yet it is the lifeline to our customers? What if it takes a significant proportion of all our IT spending every year to keep this system limping along? Replacing this system is a matter of life or death for the business. And so, there is the slow choke from the stranglehold of the ossified ATM system versus doing what is quite analogous, both in terms of cost and risk, to an organ transplant if we replace the system. Strategy has to make us pay attention to what's sapping life from the business just as much as it must help us focus attention on invigorating new directions. The choices we make are as significant to our future as the choices we neglect to make.

Strategy cannot assume we are starting afresh. It has to take into account what we need to replace (it is broken), improve (it is working), and do differently. This is not to suggest, for example, that IT portfolio planning is business strategy, but instead that strategy has to set the context for portfolio planning.

By deciding where we will differentiate and where we need to be only at parity with others in the competitive space, the context is set for the next wave of strategic decisions. Direction is provided for IT portfolio planners and enterprise application (solution) architects and technology (infrastructure) architects to distinguish between areas where the company will rely on industry-standard solutions and technologies and where the business will create differentiating, value-adding systems and infrastructure. Remember that strategic decisions (impacting the high-level direction of the company and its path to attaining and sustaining strategic advantage) can be made at any level in the company. If the executive strategy process is ineffective, then decisions lower in the organization can override the business strategy rather than align with and support it. This is true with enterprise systems. If a decision is made without any sense of where the company is trying to maintain minimum capability levels for success in the industry versus where it intends to differentiate, the selection of an off-the-shelf system will determine the best that the organization can hope for -- parity with others that manage a successful deployment, assuming we deploy successfully ourselves.

Strategy has to trade off resources (including executive attention or bandwidth) needed to meet the minimum success factors for the business against resources needed to pursue the next thrust of differentiation in response to market shifts and emerging opportunities.

However, minimum success factors do not just play a role because they require resources and stewardship to keep in place. As the market shifts, the minimum success factors change. Innovations in technology and process render our sociotechnical systems obsolete. As part of our strategy process, we need to update our understanding of the minimum success factors for our business over the planning horizon and include in our strategy regaining parity with other competitors in these dimensions of essential capability.

The business strategy process has to stay many levels of abstraction above the day-to-day drama of business survival with its quagmire of distracting detail. Once in place, the current business capabilities architecture is an essential tool for analyzing the business capabilities and capability levels to establish the minimum success factors and key differentiators for the business over the strategic planning horizon.

By focusing on what high-level capabilities are needed, strategic managers set direction without determining/constraining how the capabilities will be implemented. Business architects can then team with IT architects to create the best combination of process and technology to achieve the capability objectives of the strategic management team.

Leveraging the Value Network to Add Value and Capabilities

The value network is, for the most part, outside our business, so it is outside the scope of our business strategy, right? No! Thinking that we can influence external players to work toward goals we share with them is only degrees more audacious than thinking we can influence our own extensive and diverse set of employees to work toward shared corporate goals. Companies that fail to think strategically about their supply chain (upstream), channel (downstream), and others who add or detract value (e.g., the media) neglect opportunities or threats that would loom large, if they were only paying attention in the right place.

If we limit our strategy framework to financial and customer strategy and internal business processes [7], ignoring the value network, our framework will not prompt us to investigate (and may even lead us away from) a very crucial avenue for enhancing our value proposition and/or operational effectiveness.

In addition to asking "What value does/can our value partners contribute, and how does that shape the way we are able to compete?" we also need to ask, "What capabilities can we outsource, so that we can free up resources or make use of external talent?" (See Figure 7.) When looking to free up resources, we look primarily at outsourcing nondifferentiating capabilities. In knowledge-work areas where there may be scarce/unique talent, it is worth considering whether we can add to our own capabilities by partnering effectively with an outside organization.

Figure 7 -- Considering the value network.

Focus and Alignment Among Strategy Elements

We have to focus. Focus makes our identity clear in the marketplace, and this is a huge benefit in an increasingly complex world. Focus allows us to channel and leverage our strengths.

Focus means we must make choices. We cannot do it all. Remember, that is what strategy is all about -- making choices about direction. Once we have picked key elements of our strategy, then the other elements must be consistent with these key elements. If we choose to differentiate through innovation, we need to align the other strategy elements with this choice. To innovate, we need talent. We cannot innovate at higher rates, in quicker cycles, than our competition if we do not have the talent and drive to accomplish this. We have to offer value to employees to attract, retain, and build talent. This speaks to the value propositions we need to offer them and to the capabilities we need to build.

Capabilities Input Is Essential to Competitive Strategy

An understanding of the capabilities the business has and the opportunities it has to build or integrate new capabilities is vital input to the business strategy formulation process. Today, technology forms the platform for competitiveness across the full spectrum of industries, not just those we traditionally associate with technology. The strategy process needs to be informed by insight into the technology-enabled capabilities that can be leveraged (internally and externally) to maintain parity with competition or to produce advantage.

This insight must come from a source that has an acute strategic sense together with good insight into the technology of the organization as well as industry trends. In more simple environments, executives could hold more of this picture in their mind and integrate a sense of future possibilities. However, the pace of change and the complexity of today's technology platform for business means that specialists are required to pay attention to this aspect of the industry and the enterprise.

BUSINESS CAPABILITIES ARCHITECTURE

We now turn our attention to the business capabilities architecture and its role in strategy execution.

Strategy determines at a high level what business capabilities we need in place to reinforce identity and deliver the value propositions on which the organization competes. The next stage is translation of strategy into an action plan. Traditionally, this has been achieved by cascading the business objectives ⁶ throughout the organization via the management hierarchy, with business units all the way down to projects interpreting the strategy in terms they can act upon. The tendency is toward decentralization, and earlier we pointed out the associated advantages and disadvantages. It is true that "strategic initiatives" based on strategy themes can go some way toward addressing cross-organizational concerns, but this has tended to be a management approach that pushes the point of business-technology partnership further downstream.

With enterprise architecture (as business capabilities architecture) as an intermediate step, the enterprise is treated as a system first, and capabilities that are needed by the whole system are addressed at this level. This allows the organization the chance to decide which capabilities to design as a cross-business collaborative effort and which to delegate to the business units. It also provides a way to bridge the business-technology gap from the top down, interpreting business strategy into technology strategy and rolling technology strategy out through the technologist network (see Figure 8).

Figure 8 -- Pivotal role of the business capabilities architecture (BCA).

Capabilities, in this approach, are the building blocks of the enterprise. The capabilities need to be understood in terms of their elements: business process (activities, sequence, ownership), people (organization, knowledge and skills, culture), technology (infrastructure, application solutions, data) and assets (facilities, funds, etc.) aligned by strategic performance objectives. They have relationships to each other and to the environment, and we need to pay attention to these interfaces and be clear on what responsibilities are being assigned to a capability. This is the central charter of enterprise architecture as business capabilities architecture.

Creating the Business Capabilities Architecture

The enterprise architects take the business strategy as input and explore and elaborate the capabilities required to deliver the value propositions identified in the business strategy (see Figure 9). A business strategy map [7] is a useful visual tool for this exploration and for sharing the strategy with the executive team for validation of the enterprise architects' understanding of the strategy and assessment of how to implement it.

Figure 9 -- Elaborate the capabilities needed to deliver the value propositions.

While the next generation of differentiating capabilities are explored, supporting capabilities that remain fundamental to the business are also analyzed. The full picture is the capabilities architecture the enterprise needs to execute the strategy (see Figure 10). This visualization of the enterprise is supported by an initial analysis of the elements of the capability: performance goals and an assessment of what is required in terms of people, process, technology, facilities, and financial resources. In our enterprise architecture workshops, where we have four days rather than just 20 or so pages, we deal with supporting analyses and views with templates and advice. The paramount advice is to document as you go and to document alternative approaches you decide against, as well as to articulate the assumptions, tradeoffs, and rationale that caused you to make your decisions.

Figure 10 -- Example BCA for a consulting business.

We need to understand enough about what it will take to build the capabilities so we can create an execution plan. The execution plan has to take into account both the in-place (current) business capabilities architecture and the new business capabilities architecture to assess which capabilities need to be built or adapted and which can be jettisoned because they are no longer needed, freeing resources to focus on the strategic choices that set the course for the business.

Taking Stock: Is Enterprise Architecture a Strategic Differentiator?

If we take Carr's line of argument, ⁷ we might fall into the trap of thinking that since every enterprise can create an enterprise architecture, there is nothing inherently differentiating about EA. As we see it, however, the essential question is this: can we use enterprise architecture to create compelling competitive advantage across our businesses and products and services?

We have already seen that through enterprise architecture we can streamline IT; with reduced costs and more effective IT projects we have an advantage over those in the competitive space that move along the architecture maturity path more slowly than we do. If our avenue to competitive success is operational excellence, then this streamlining may be a component of our competitive strategy.

Further, when we define enterprise architecture as the business capabilities architecture and charter enterprise architects with the job of evolving the enterprise architecture in concert with the evolving business strategy, we position ourselves not only to improve our strategy execution process, but also to create more effective strategy. That puts us well on the road to a resounding "yes" in response to the question asked at the start of this section.

A strategy team that understands the current business capabilities architecture is better positioned to create an executable strategy that leverages current strengths and sets achievable targets that do not assume any miracles of transformation on a dime.

By including the chief enterprise architect on the strategy team, we gain the further advantage of dynamic insight into the consequences for capabilities of various choices being considered by the strategy team. Further, the enterprise architect is able to see opportunities and challenges that others would not see, simply because the EA team is paying attention to capabilities and immersing itself in the effort to understand strategy in terms of capabilities. For example, different perspectives on customers, competitors, and value partners emerge as a result of thinking clearly about how to create and deliver differentiating value.

Enterprise architecture is itself a capability. It can be a support capability, for example helping to pare unnecessary costs by streamlining the IT of the company. Or it can be a strategic capability, contributing to excellence in strategy formulation and strategy execution and in doing so, contributing in a very direct way to creating competitive advantage across the products and services offered by the company. To better understand the role in strategy execution, let us return to the question of capability design and rollout.

ARCHITECTING CAPABILITIES

Once we have a business capabilities architecture that provides a good fit with our identity and competitive strategy, our EA team is not necessarily done. The capabilities themselves need to be architected and built or adapted to fit the new strategic drivers (see Figure 11). We believe that enterprise architecture, like any architecture, should be minimalist [8]. That is, it should not include any decisions that could be made by other parts of the enterprise without compromising the enterprise goals, business strategy, and overall business imperatives. So, for each capability, we need to decide if it can be delegated or if it needs to be architected under the leadership of the enterprise team with its unique, overall enterprise scope of visibility, perspective, experience, and decision authority.

Figure 11 -- From strategy to enterprise capabilities.

Some of these capabilities will rely strongly on IT and may even be available as systems that can be acquired. The job then is assessment of the available options against the quality characteristics associated with the capability. These include performance goals as well as process and culture match. For capabilities that will be built or adapted internally, these quality characteristics are also important in driving the capability design process, just as in any other kind of architecture (including building architecture, solution architecture, and application architecture).

The Visual Architecting Process

Whether we are architecting a capability within the enterprise architecture practice or within a business unit, the visual architecting process illuminates how to create an architecture that is:

• Good -- it is technically sound and clearly represented.
   
• Right -- it meets the needs and objectives of stakeholders.
   
• Successful -- it is built and delivering the capability.
   

The visual architecting process (see Figure 12) covers the techniques, including architecture modeling and architecture tradeoff analysis, used in creating a good architecture. It covers architectural requirements and prioritization to create the right architecture together with architecture validation to ensure that the architects and key stakeholders agree that it is indeed the right architecture. And it covers the organizational process steps that help ensure that the architecture is embraced and used in an informed way, so that, ultimately, the architecture is successful.

Figure 12 -- The visual architecting process.

We provide a full treatment of the visual architecting process in our forthcoming book, "Software Architecture Action Guide," 

PRAGMATIC IMPLEMENTATION

We began our last Cutter EA Executive Report [1] with a story. We think it's fitting to end this report with one. We use this story as a metaphor, though indeed the main character, Jaime Lerner, ⁸ is an architect -- in this case a building architect by training and initial practice. At the time this story takes place, Lerner was a "city architect," the mayor of Curitiba, Brazil. His accomplishments were very similar to those of an enterprise architect; he was enhancing the capabilities of his city, and he had to deal with many of the deployment challenges enterprise architects in business face.

When Lerner became mayor of Curitiba in 1971, he wanted to find ways to revitalize the economic life of the city center. In response to a plan to widen streets and build a skyway to support more automobile traffic, Lerner wanted to widen the sidewalks and eliminate cars from the downtown area to create a four-by-four-block pedestrian mall. When Lerner spoke selectively with merchants in the area, he met with a consistent response: merchants liked the idea, but on somebody else's block. Why? The answer was always the same. They thought they would lose business if customers could not drive up and park in front of their shops. Lerner was sure that he was right and that merchants would love it once it was installed, but it was clear they intended to resist, in court if necessary. Lerner asked his public works department how quickly it could do just one block of the mall. Under pressure from Lerner, the department adjusted its initial estimate of two months down to one week. Lerner wondered how much court action a bunch of angry merchants could take in a week and to what effect. Press coverage? Momentum? Well, what if it were three days or even just one? Lerner realized that, in effect, he had to convince the merchants, and he had no time at all in which to do it.

So he arranged with his public works department to have all the equipment and supplies it needed for a one-block mall delivered to the proposed spot at about close of business the next Friday. With help from city employees that wanted some overtime, the department would install the mall, complete with benches, planters, flowers, and so on -- the works -- and be done by Monday morning. And they did.

Lerner spent Monday morning taking the expected calls from angry merchants: "I told you I didn't want this. I've contacted my lawyer. You and the city will be held responsible for lost business. We'll see you impeached," and so on. But by late morning the calls stopped. Why? No, they hadn't all called. They were too busy! But later the phone started ringing again. Now what? Now it was the merchants one and two blocks away asking, "When are you going to do my block?" So Lerner went on to build the four-by-four-block mall ... or at least that's how we used to finish the story. Whenever we would tell this story, we would begin by asking if anyone had ever heard of Jaime Lerner. Generally the answer was no, as was the case a couple years ago at a workshop in Orlando, Florida, USA. But all through the telling of the story that time, one gentleman kept smiling knowingly. By the time we finished the story, burning with curiosity, we asked what he was smiling about. He worked at Caterpillar and while visiting one of the company's plants nearby had visited Curitiba. "It's not a four-by-four-block mall," the man said. Oh no, we thought. Now we're about to be shown wrong. He went on: "It's much larger than that, snaking all over the downtown area." Whew!

Obviously the lesson here is to build support by proving value -- implementing an achievable piece of the solution quickly before resistance has a chance to fester. Another part of the story also has bearing on our enterprise architecture efforts. Cities, like businesses, have diverse constituencies, and resistance can come from surprising quarters. In the case of Curitiba, the automobile association took offense. They decided to hold a car rally that was to pass right through the pedestrian mall to "take back the streets for the automobile." What did Jaime Lerner do? Call in the city police, put up barricades, arrest the drivers? No. His approach was much more elegant, showing keen insight into human nature. He had paper rolled out all over the mall, placed buckets of paint and brushes all around, and invited the children of the city to a "paint-out" celebrating the new pedestrian mall. Needless to say, nobody drove through the pedestrian mall that day.

As we work on building new capabilities that impact diverse groups across the enterprise, we need to keep these lessons in mind: we need to be keenly aware of where our efforts can be derailed and figure out innovative ways to influence and be successful without compromising our personal and organizational integrity.

CONCLUSION

Enterprise architecture is different things for different organizations. This is in part due to differences in when EA is embraced within different organizations and in part due to differences in what organizations are willing to risk. Conservatively, enterprise architecture can play a role in cutting costs, making the technology environment simpler, more effective, better integrated, and better managed. This is important in areas of our business where IT is an element of a nondifferentiating support capability so that we need only match others in the competitive space.

More aggressively, enterprise architecture can be broadened from its IT roots to a full partnership with the business, addressing the capabilities that the business needs to build, adapt, or sustain in order to execute its business strategy. Of course, the enterprise architecture team has to reflect this partnership in its constituency and its reporting relationships; that is, it cannot just be an IT practice any more. The reward is a path to better alignment of IT with the business, and, more importantly, a more effective strategy followed by more effective strategy execution. It allows the organization to consider what capabilities it should build collaboratively at the enterprise level to deliver value across the business and establish strong competitive advantage through leverage and synergies. This is the route to making the enterprise greater than the sum of its parts, which is, after all, the goal of system architecture.

ACKNOWLEDGMENTS

We would like to thank Kristen Sanderson, a chief software architect at GE Energy, who contributed thoughtful suggestions and improvements to this report. We would like to give special recognition to Raj Krishnan and Aaron LaFrenz who inspired and championed the business capabilities architecture as the cornerstone of our approach to enterprise architecture. All the architects we have worked with have played direct and indirect roles in influencing our understanding and approach to enterprise architecture and business strategy. We thank all of you for sharing your lessons and insights with us.

NOTES

¹That is why we personally pay so much attention to these issues in the visual architecting process and in the architect competency development work we do with architects and teams.

²This diagram will also help you relate the Kaplan and Norton [7] strategy process to our strategy framework.

³We highly recommend the work of the Grove Consultants International (www.grove.com). We have used a number of their graphical facilitation guides as a starting point and have added to and adapted these to round out the strategy process.

⁴Though Michael Porter focuses on activities, and Robert Kaplan and David Norton [6] focus on business processes, we prefer to focus on capabilities, emphasizing that capabilities can come from business processes, from technology (built inhouse or acquired using resources), from skills, or from combinations of these.

⁵This section comes from the discussion of strategy on the Bredemeyer Consulting Web site.

⁶Increasingly these are expressed in balanced scorecards, following the approach of Kaplan and Norton [6]. We strongly advocate balanced scorecards to express strategy themes, objectives, measures, and owners. Indeed, we advocate using these throughout the organization to express lower-level objectives and show how they relate to higher-level objectives. This is covered in our presentation on "Choreographing the Dance of Change" presented at the Enterprise Architecture Conference in Phoenix, Arizona, in 2003. The slides are available on the Bredemeyer Consulting Web site (www.bredemeyer.com).

⁷In essence, Carr's argument [2] reduces to the following: since information technology has become a commodity easily accessible to all, it does not provide any differentiating advantage and should be managed accordingly.

⁸If you want a rich source of inspiration, Jaime Lerner is a modern architect and statesman who is well worth reading about. We first heard Bill McKibben being interviewed on National Public Radio about his book on Lerner (Hope: Human and Wild -- True Stories of Living Lightly on the Earth, Hungry [Mind Press, 1995]), and that prompted us to do further research on his story. We have told the pedestrian mall story in our architecture workshops around the world, and every now and then we encounter someone who has been to Curitiba, lived in Brazil, and known of Lerner, and so forth, and so far our story has been corroborated. Nonetheless, we have not interviewed Lerner himself to check the accuracy of every detail of the story we tell. It is at least a good story, with a meaningful lesson for enterprise architects. We do believe it is a true story. But we cannot vouch for this in every detail.

REFERENCES

1. Bredemeyer, Dana, and Ruth Malan. " What It Takes to Be a Great Enterprise Architect." Cutter Consortium Enterprise Architecture Advisory Service Executive Report, Vol. 7, No. 8, August 2004.

2. Carr, Nicholas. "IT Doesn't Matter." Harvard Business Review, May 2003.

3. European Union. "A Constitution for Europe." Rome, Italy, 29 October 2004 (http://europa.eu.int/constitution/download/brochure_160904_en.pdf).

4. Gulati, Ranjay, and James B. Oldroyd. "The Quest for Customer Focus." Harvard Business Review, 1 April 2005.

5. Hemp, Paul, and Thomas A. Stewart. "Leading Change When Business Is Good: The HBR Interview -- Samuel J. Palmisano." Harvard Business Review, 1 December 2004.

6. Kaplan, Robert S., and David P. Norton. The Balanced Scorecard. Harvard Business School Press, 1996.

7. Kaplan, Robert S., and David P. Norton. The Strategy-Focused Organization. Harvard Business School Press, 2000.

8. Malan, Ruth, and Dana Bredemeyer. "Less Is More with Minimalist Architecture." IT Pro, IEEE, September/October 2002.

9. Moss-Kanter, Rosabeth. Teaching Elephants to Dance. Simon and Schuster, 1989.

10. Packard, David. The HP Way: How Bill Hewlett and I Built Our Company. HarperBusiness, 1995.

11. Rechtin, Eberhardt. Systems Architecting: Creating & Building Complex Systems. Prentice Hall, 1990.