Judging by the growing interest in enterprise architecture and the proliferation of frameworks, such as TOGAF, DoDAF, IAF, and EAF, the benefits are real. It has become a way to build relationships among business units and to revitalize processes and capabilities to make companies more flexible and more efficient in managing change.
But business executives often consider the cost of implementing enterprise architecture as dauntingly high and see the business benefits as elusive and risky. The term enterprise architecture means little to most of the executives. To many, EA looks like just one more in a stream of abbreviations from the IT industry that rarely deliver all of their promised business benefits.
Even among IT practitioners and self-proclaimed enterprise architects, misconceptions continue to swirl around the definition of enterprise architecture and what it really delivers in terms of business benefits. This causes further ambiguity in their attempts to explain the value to business users.
In my work with numerous companies across the Nordic countries, I have often observed that initiatives that look promising or necessary do not get approved because their benefits cannot be made relevant to business executives. Other times, they simply don't believe that the selected approach will work, or sometimes, the enterprise isn't mature enough yet. I have come across initiatives in which EA was deployed inappropriately or superficially, so it led either to implementation plans that encountered too much skepticism to be feasible or that were based on superficial high-level principles with unclear economic logic. Other initiatives never get off the ground because there is a huge gap between those who designed the enterprise architecture and those who must be accountable for its implementation.
Finally, EA is sometimes done according to a prescriptive approach that delivers it as a complete and architecturally detailed description of what the enterprise should look like, ideally, with plans for moving from here to there. In enterprises where managers subscribe to a more incremental approach where integrating the experiences at each step is important, this approach doesn't work well.
To avoid such missteps, enterprise architects must take a pragmatic, business-oriented approach to explaining the virtues of enterprise architecture, one that clearly and carefully balances the risks and business benefits. They must also be sure to align the design and implementation process with the strategy, governance, and architecture processes, thereby reflecting what is important in that culture, whether that is incremental learning and predictable outcomes, or creativity and big-bang transformation, and so on. And they must understand and respect the inherent diversity in governance, architecture, measures, organizational structure, and strategy.
These considerations are often foreign to enterprise architects. What they see are corporate customers who interfere and undermine their approaches to designing architecture. Nonetheless, enterprise architects must tailor their designs to deliver consistent quality at sustainable costs. And they must do that in a way that reflects their organizations' norms for strategy and architecture, as well as the existing capabilities, structures, and governance accordingly.
Enterprise architecture emerged as a field of interest along the trail of developments in strategy and organizational design that began occurring by the mid 1980s, and interest in it has steadily intensified since. There are at least seven interconnected forces that are sustaining this trend.
The first is an accelerating rate of change, or clock speed (Fine, 2003; D'Aveni, 2004). It has been steadily increasing in industry after industry since the early 1980s, driven by deregulated and globalized markets.
An increasing rate of change means that the enterprise must be able to respond faster to changes, thus must be able to reconfigure capabilities and even structures. It also means that the enterprise must be able to develop new products faster.
Resource reconfiguration, for instance, can be a matter of reconfiguring flexible manufacturing technologies to changes in market demand and at a pace that keeps up with the clock speed of changes. This ability manifests itself differently in different industries, however. In property and casualty insurance, for instance, resource reconfiguration can be the ability to launch new insurance products to niche customer segments, testing responses, and deciding whether the products should be pulled back, adjusted, or marketed to a wider segment. In production of fast-moving consumer goods, it can mean implementing new market and branding strategies for product families faster than any competitors or retooling the production system to handle additional, related products.
Resource reconfiguration is usually focused on creating an integrated information flow across the supply chain. The goal is to detect demand signals at the customer-facing stages of the supply chain and configure the production stages accordingly.
One challenge is how to integrate information relevant to different value activities at different stages of the supply chain. In instances where activities in the supply chain are executed in specific business units, EA becomes a matter of designing and implementing how activities, resources, and information are shared among these different organizational units. For example, marketing, selling, and delivery might be in country-specific organizations, but with customer service in shared service centers.
Greater information density means that customers increasingly base their decisions on price and features. This leads to higher transparency for price and quality differences, thus to increased buyer power.
Therefore, increasing density of information means that products are continuously at risk of becoming commodities. Hence, business leaders must ensure that their companies' products remain differentiated, and this leads to a need for faster innovation and, consequently, for reconfigurable product architectures. But it also means that enterprises can assimilate and act on information about their customers and competitors. EA serves as a vehicle for tying different sources of information together across organizational boundaries. This results in options to respond in a consistent manner.
Growing information density also intensifies competition and lowers entry barriers, because trade secrets become harder to protect, and product and service replication occurs faster. Lower entry barriers are further assisted by the trends toward deregulation, the rise of free market zones, globalization, and the accelerated growth of the service economy that have characterized especially Western economies over the past couple of decades.
The third factor is personalization expectations, because customers increasingly demand goods and services that are tailored to their preferences yet expect them to be delivered quickly. This is especially important in service industries, such as government, retail banking, insurance, and telecom or cable, where services are delivered almost entirely by information technology. In these industries, the number of mass-customized products has increased considerably.
Personalized products are often the result of combined products and services, where unique or special service and product bundles are configured according to the customer's preferences. Examples include IBM's Global Business Services, which sometimes augments its traditional Software Group products with complex systems integration services. Other examples are GE Medical System's Performance Solutions, which offered consulting services packaged with imaging equipment (Ranjay, 2007) and A. P. Moller-Maersk's APM Contract Logistics services to augment its traditional container shipping services.
Because so many products are supported by applications and IT-enabled services, bundling often requires the ability to combine them with services. Any inability to do so will require changes to individual applications and to how applications are interconnected. For instance, if a container shipping line wants to integrate contract logistics services with standardized shipping services, it needs to do this in a way that considers disparate applications within different business units. In this example, that means the contract logistics business unit and the container shipping business unit must integrate their operational and customer service systems and data to be able to create an integrated customer experience.
Disintegration of industries was in vogue during the 1990s. The objective was to improve the competitiveness of firms within an industry. Results of a study at the Japanese Research Institute of Economy, Trade and Industry (Takizawa, 2003) argue that the stagnation in the Japanese economy then was caused by the modularization of industrial architectures within economies that competed with Japan during this period. Similarly, the report tries to demonstrate that the revival of the US economy during the same period was caused by modularization.
Jacobides (2005) noted that gains from industry disintegration occurred only when two necessary conditions were in place:
- First, the interdependence among cooperating firms had to be made easier by the availability of standardized service interfaces (leading to coordination simplification and, hence, lower coordination costs).
- Second, the information exchanged among the cooperating firms had to be standardized into simple, transmissible, and universally understood messages (standardization of information).
Industry disintegration is caused by seemingly evident gains from trade and specialization. In both instances, organizations in the disintegrating industry must be able to specialize and coordinate the activities in their value chains in different ways. This creates a need to be able to model and specify service interfaces for the primary business activities, and then to optimize those activities within the context of the entire industry, considering the potential for gains of trade and specialization. It is this need for modeling and service specification and for optimization within an entire ecosystem that makes enterprise architecture worth considering.
Further, if leaders of an organization believe that future specializations might occur within its industry and value chain, they might decide to develop a capability to coordinate the exchange of information with external partners and complementors. For example, one of the world's leading producers of enzymes used in the production of detergents and soaps uses "business connectors" to link its forecasting and planning processes to those of its primary business partners around the world. They then have up-to-the-minute access to standardized information on near-term as well as long-term demand.
Due to globalization and patterns of relatively low growth in the EU, Japan, and the US, managerial focus has shifted from how to achieve high growth to how to achieve a competitive advantage. Although independent business units might have been suitable for capturing growth initially, a more competitive environment means that enterprises now seek out new opportunities for competitive advantages. They also seek improvement in how they coordinate business unit strategies, share resource commitments, and exploit untapped synergies.
Customers, also under pressure, are often a force for coordination. Increasingly, they consider the entire portfolio of services and goods that they purchase as a basis for volume discount negotiations. They also demand that services be integrated across business units, for instance in terms of integrated invoices, horizontal discounts, and so forth.
Since the end of the 1970s, the way that firms grew through diversification and the way that they diversified their geographical and functional units within a business unit have changed markedly. Most enterprises now favor related diversification, where entire business units, as well as geographical and functional units within business units, are related or similar in terms of how they share value activities, such as procurement, R&D, design, manufacturing, and so on. This has gradually led to the formation of more business units that increasingly are asked to share resources and value activities. For example, an international conglomerate had diversified its business activities into three groups: transportation, energy, and retail. Each group included multiple business units and each group tried to achieve interrelationships among its business units by having them share business activities, data and applications.
This increasing interest in being able to share resources, data, systems and activities through shared service centers (e.g. customer service) or shared departments. (e.g. HR, Procurement, IT) is within the sweet spot of EA.
Faster product innovation is an objective when competing in fast-moving markets, such as media, consumer electronics, or software. Product clock speeds are measured in months and sometimes weeks, and the ability to continuously develop and market new products contributes to the firm's competitive advantage.
Fast product innovation is usually based on reuse of architectural assets with well-established or standardized interfaces. New products are created on the basis of a dominant design and consist of modules, where one module can be enhanced or upgraded more or less independently of the other modules. As long as product innovation is incremental or modular relative to the dominant design — meaning that it preserves the dominant design and its basic form factor — the design of a new product can occur relatively quickly if the underlying production technologies can accommodate the necessary changes.
These production technologies are typically connected to component procurement activities that connect to external suppliers, to testing activities to ensure that the end product is adequately tested to quality, environmental, and consumer specifications, to product packaging activities, to marketing activities that will promote the product, and so on. Increasingly, when the design occurs within the enterprise, the product will be produced by a collaborative and multidisciplinary process, called three-dimensional concurrent engineering (3DCE), whereby design, engineering, and manufacturing changes are performed concurrently rather than in a sequence. Furthermore, when the product is the result of design, engineering, and manufacturing collaboration between the enterprise and one or more suppliers or complementors, the 3DCE process requires external connections to the related activities in other enterprises. This concurrency of activities mandates high sharing of information and sharing of product design, engineering, and manufacturing planning among different functional units.
The combined outcome of these drivers is that cost pressure has become permanent. Internal activities must now be coordinated among related business units, such as procurement and operations, so the advantages scale across the entire organization.
Under all of these different objectives, enterprise architecture must be considered a managerial discipline and competence for building shared capabilities across organizational boundaries. The discipline of EA must also coordinate these capabilities.
In the 1970s, the view emerged that business units should operate autonomously and be measured mainly on profit and loss (P&L). This emergence of business units for structuring the enterprise was based primarily on the notion that if these units were active in different and counter-cyclical industries, they would be able deliver a more predictable income stream.
Through the 1980s and 1990s, this view was broadened to consider the synergies that result from having related business units that operate with shared core competences (Prahalad and Hamel, 2003). Essentially, it became attractive to be able to coordinate procurement of component parts or services or R&D investments for capital-intensive areas, such as information technology or technology platforms, in order to improve overall cost efficiencies.
Many, if not most, EA projects begin with the objective of reducing the capital intensiveness of IT by sharing licensing, development, and operations activities across business units.
Enterprise architecture deals with the following key challenges, some of which are part of the discipline and some of which are rooted in the enterprise:
Alignment of the organization's capabilities and strategy with the environment in which it operates is a key consideration for enterprise architecture.
Enterprise architecture can play a role in realigning organizational structure and information-based capabilities to create a better strategic fit with the environment. It can also play a significant role in changing the organizational design, where structural fit with the strategy is considered important.
Achieving better alignment in the form of better strategic and structural fit remains a tricky balancing act. Too much emphasis on constant alignment can lead to rigidity, because the focus can be too much on stability rather than flexibility, from fear of upsetting the balance. However, misalignment can be costly because the enterprise might not possess the capabilities that are necessary to react to changes in the environment.
Capacity varies across organizational units. Absorptive capacity that allows new initiatives or ways of working to be acquired, integrated, and disseminated can be very different, because the same initiatives can lead to high resistance in some units and be readily accepted in others. Given the resource commitments already made by the units and their total capacities, resource capacity can constrain the enterprise architecture implementation plan.
Diversity can be high, and the ability to take on enterprise architecture and to consider it relevant and important is influenced by a several drivers: governance, architecture, measures and incentives, organizational structure, and strategy. When diversity is high, the business units respond differently to enterprise architecture. This is especially the case when enterprise architecture is prescriptive and when it emphasizes enterprise standardization and integration. Yet, typically, this is in the nature of enterprise architecture: to prescribe how all parts of the organization should subscribe to the same technical standards and policies and how they should agree on the same set of pre-integrated business processes.
Complexity originates in the idea of structural fit, whereby an organization periodically reorganizes to match environmental influences. It is also caused by growth, whether organic or inorganic. When the organization grows, it expands into new markets and geographies and adds organizational units to ensure local presence and sensitivity to local demands. The result of expansion and reorganization over time is that complexity increases. This makes even medium-sized organizations relatively complex.
Complexity is on the increase. Multi-product, multi-divisional or matrixed organizational structures are often overlaid with processes or internal hybrid structures that focus on growth initiatives. Furthermore, the organizational structure might be asymmetrical or not consistently applied throughout the enterprise. Some business units might be organized according to a functional multi-product structure, while others might be structured around products. Divisions might further structure their international presence in different ways, some by a single international division, and others by regions or country organizations.
So to reiterate: complexity is the result of governance or growth, whether organic or by acquisition. When the enterprise is active in multiple markets and along multiple growth trajectories at the same time, its complexity grows.
Coordination is becoming a crucial organizational competence for responding to changes in the environment. One reason that complexity has increased is a deeply held belief in many firms that organizational structure, and consequently restructuring, is the answer to many business problems that originate in changes in the industry or market. However, a growing number of firms now organize themselves into network structures and use coordination competencies to insulate organizational structure from external change, and they are still able to respond effectively and efficiently. A company such as IBM, for instance, frequently uses internal hybrids. These are temporary product or service lines that operate on top of the organizational structure without changing it. They are created to focus the company on new market opportunities and to take market share in the initial stages of new technologies coming to market. When successful results are achieved, these internal hybrids can be dismantled without any change to the underlying structure.
Coordination competence is typically measured by an organization's ability to coordinate its business activities across business units by using technology, as well as by the ability to align key performance indicators (KPIs), incentives, job roles and skill sets to those needed by the internal hybrids.
Relevance is a frequent challenge to many EA programs. Too often, enterprise architecture initiatives focus on modeling that is seen as lacking relevance to many parts of the business community.
Rigidity is a hallmark shared by many complex organizations. Because the organization consists of many different business units or functions, and they coordinate their activities to deliver products or services, it is difficult to change individual parts without ripple effects. Also, because complex organizations tend to be larger, they also tend to rely more on complementary assets and scale for their competitiveness, and their abilities to coordinate assets and sustain their scale require certain stability. It becomes important for the enterprise architect to understand how rigidity can actually be considered a necessity for competitiveness. It is also important to identify the sustaining interfaces within the organization that are paramount to its competitiveness.
Logic is related to relevancy but takes its own form. Many enterprise architecture initiatives are transformational by nature. Consequently, they might have poorly understood business cases. However, in a survey of several large European organizations, such as AstraZeneca, Vestas, Carlsberg, Maersk, and Nokia, the initiatives with clear and well-focused objectives tended to have a better economic logic and, consequently, improved relevance. In one instance, a large pharmaceutical company had used enterprise architecture as a method for building a dynamic capability that enabled it to move its discovery experiments among its different wet labs around the world, depending on where the most capacity was available.
When considering a pragmatic approach, it is necessary to consider not just what is practical from the standpoint of the architect and the technology. Instead, we must consider what is practical from the standpoint of the enterprise, given the decision-making processes, preferences, and perspectives on strategy, governance, and architecture.
Many EA methodologies and frameworks implicitly assume that EA can be approached similarly to how we have approached discrete systems architecture or multi-system architecture for decades. The assumption works well when it occurs within a smaller, clearly governed unit of the firm with well-established and rational decision-making procedures.
However, there are more facets to enterprise architecture and sometimes more complexity than there are in discrete system architectures. For enterprise architecture to win acceptance, to become practical and relevant in its form and expression, the architect must take many strategic and organizational factors into consideration and reflect most of these in the approach.
Many EA methodologies are based on the assumption that the enterprise operates with centralized or at least rational decision-making and strategy processes, that people are interested in improvement and transformation, and that they subscribe to or at least accept an architectural perspective on how to implement that improvement. In fact, most available EA frameworks and methodologies work relatively well under these assumptions.
However, over the past 10 years, we have worked with firms (even among the savvy and sophisticated Global 500 firms) that are multilocal, complex, emergent in their strategy orientation and yet highly conservative in their perceptions of architecture. For these partitioned and emergent players, prescriptive and overly architectural approaches to EA are a poor fit, and those approaches are usually greeted with skepticism.
So how should the enterprise architect respond to these challenges?
First of all, there seems to be little need for challenging or even changing time-honored models and methods for enterprise architecture. Nevertheless, several basic activities must be integrated into the process:
- Express of the value clearly
- Satisfy stakeholder needs (localize the architecture)
- Tailor the implementation
- Explain the trade-off decision
- Safeguard future options
- Reconcile different perspectives
For an EA project to show early successes, and thus convince decision-makers on the business side of its benefits, it needs to demonstrate clear and tangible advantages. So first, it is critical to select an appropriate context for its implementation.
EA can be especially useful in situations where horizontally defined goals must be met across different organizational and technological domains, such as across multiple lines of business or business units and application areas. There are also common needs that are difficult to meet without engaging in enterprise architecture:
- The need to be able to reconfigure resources faster and better
- The need to be able to deliver personalized products
- The need to be able to deliver customer-focused solutions
- The need to be able to engage in fast product innovation
- The need to be able to coordinate advantages and share activities across business units
In heterogeneous and horizontal environments that have grown on an ad hoc basis over several years, EA can help considerably in removing the technological barriers to business-driven innovation, such as high complexity, high costs, and slow time to market.
EA initiatives should begin with a clear sense of how value can be created, captured, or delivered, and it is important that this value is modeled and maintained throughout the project. However, although there is often an implicit sense that EA can produce long-term benefits and even that it might be necessary. Benefits and their risks are rarely quantified or expressed in an economically logical way that can be used to guide decision-making processes.
Too often, the argument is that the value of EA is captured over time. CIOs and enterprise architects can make the argument for investing in EA much easier if they concentrate on the ability to meet strategic, nonfinancial goals affordably, such as reduced time to market, better coordination, improved customer focus, and reduced internal cost of reconfiguring resources.
This brings us to an important realization: Although some initiatives are easy to justify in financial terms, some can be justified only in terms of managerial gut feelings and assuming a long-term view on benefits. If the enterprise operates with high internal rates of return, the NPV (net present value) of enterprise architecture initiatives tends to be difficult to justify when compared to doing nothing.
Therefore, the enterprise architect has to be clear about how to calculate or estimate the value of programs, including the value of the EA at different levels of the organization and be able to estimate the financial outcomes of improved resource flexibility. The enterprise architect must understand whether management is conservative in its financial practices, because the more conservative it is, the more demanding it will be to justify enterprise architecture below the level of the CEO. In these situations, the EA can typically be justified in terms of the new capabilities that it will enable and that without the initial investments in the architecture, those capabilities will be, at best, costlier, more time-consuming, and more difficult to build.
This means that the financial justification for enterprise architecture might have to look beyond the architecture and its scope. You can do this by integrating likely future scenarios and capabilities and by pricing and calculating returns based on these capabilities compared to not building the architecture at all. In other words, approach the financial dimension beyond the pure assumed cost of implementing the architecture. Instead, apply options valuation or scenario-based cash flow and NPV analysis. In essence, the argument is that the enterprise architecture buys the enterprise the option to make future investments at less cost.
For example, a widely used tool for enterprise architecture, IBM® Rational® System Architect, includes support for business intelligence reporting and analysis for modeling and maintaining an overview of financial benefits and associated risks of the enterprise architecture itself. This capability assures that business leaders who support the project will have the proper information to help guide decisions about where to transform, how to achieve the maximum business impact and ROI, and where to steer clear of high-risk areas.
The semi-autonomous units that are within the EA scope and that will be sharing activities, infrastructures, and so on must be "sold" on the idea and value of EA before, during, and after the EA has produced results. One of the most effective ways of ensuring that this happens is to build a stakeholder map with each business unit, and then appoint a local enterprise architect to ensure that the key stakeholders within each unit continually understand and accept the premise and purpose of the enterprise architecture. When results are produced, they must be localized to each unit and expressed in value propositions and costs that are relevant to each unit.
This localization of the enterprise architecture is typically not part of the engagement plan. This represents one of the paradoxes of many enterprise architecture projects. Because the architecture deals with the enterprise, or at least with cross-cutting concerns that require coordination among the units, it is often approached and designed at a level above the business units and justified by enterprise-level economic logic, rather than predicated on local economic logic.
It is necessary for the enterprise architecture to legitimize the diversity of the units and to communicate ("sell") the enterprise architecture in a language that is understood by people in each of the units. Therefore, value propositions must reflect a deep understanding of each unit's governance, organization, measures, architecture, and strategy (including their different industry and market positions).
One of the weakest points in any enterprise architecture is its ability to lay out a clear and persuasive plan for implementation. The enterprise plan is vital for bringing the EA from the level of conceptual design to the level of implementable activities. In doing so, the plan must reflect the resource commitments already made by each of the units and the available capacity for initiating new activities. Frequently, it becomes a plan that evolves in several tempos and at different levels. Ideally, it must be viewed from an enterprise perspective, as well as from the perspective of each unit.
This type of enterprise plan — with multiple views, multiple levels, and multiple tempos — is difficult to structure and execute. It requires strong project management skills plus strong governance of design decisions and design rules, and it must provide for knowledge transfer across business units.
Even when the value is clear and stakeholder needs are satisfied by persuasive, localized value propositions, EA always carries certain costs. It is these costs that lead to the trade-off decision that is a central part of the economic logic for the enterprise and for each of the units.
Because EA is coordinated across semiautonomous units, it often leads to higher coordination costs, compromise costs, and inflexibility costs within the units and across the enterprise. These costs are often the source of resistance to many EA initiatives. They are often poorly understood at a rational economic level yet clearly sensed at the intuitive level.
For instance, if the EA establishes standardized information models that enable the enterprise to reap gains of trade and specialization within its industry, these information models can lead some business units to feel restricted and might lead to costly changes in their data and applications. Therefore, the potential gains of trade and specialization that result from the EA must be traded off against this sense of feeling restricted and feeling like the organization's autonomy is being invaded, as well as the units having to make direct capital expenditures for needed changes to systems and data.
Enterprise architecture can be considered an organizing logic for a set of processes and architectures, or it can be viewed as a managerial discipline that addresses specific organizational problems, such as how to improve scale efficiencies in procurement or product development or how to deliver joint services.
When EA is viewed as a managerial discipline for solving specific business problems, it tends to come with a clear purpose and value proposition. But when EA is viewed and started as an organizing logic initiative, based on the classic city planning or urbanization metaphor, its real value might be difficult to capture and articulate.
In this situation, EA must be conceptualized as a "future options platform" that delivers the ability to harvest future competitive advantages at less cost than would otherwise have been possible. This turns the economic logic into one that is predicated on "the cost of non-investment," and it positions enterprise architecture as a transformative meta-architecture that paves the way for and coordinates future initiatives.
If these future initiatives are known and already planned, it is clearly possible to appreciate their advantages and costs with and without the enterprise architecture. However, if they are not known yet, EA will typically have to unfold as an unfounded initiative, usually within the boundaries of the IT organization. The economic logic will be predicated on how EA can be used to organize and prioritize IT initiatives and projects, and then on how it can ensure higher quality and lower cost if these projects are brought into compliance with certain design rules and standards.
Implementing enterprise architecture isn't just a matter of designing and implementing the architectural changes within the different business units. The business processes affected and the organization itself must also be changed sometimes to achieve the desired coordination competence and flexibility.
In enterprises with a highly evolved coordination competence and strong governance practices, it is easier to coordinate architecture initiatives without resorting to changes in the organizational structure. The opposite tends to be true in enterprises with poorly developed coordination competences. Therefore, it is important that the enterprise architect appreciates the level of competence that is present within the organization — the organization's ability to coordinate its information, as well as financial and human resources across organizational units — before embarking on the design of the architecture. This is simply to understand what is feasible and what might turn out to be too difficult or costly.
Senior managers in some organizations are reluctant to share resources or information across organizational units, because incentives and performance measures are poorly aligned or because the units operate with very different purposes or strategies. In these situations, it will usually be easier to make effective changes to governance than to make changes to the organizational structure. However, when changes to the governance model are needed, changes might also be needed in the organization's incentive structure (and performance measures), its mission (strategy), and its ability to share knowledge. These supporting changes tend to take a long time, not only just to agree on but also to get to a working level where they are applied daily.
The London Business School conducted an empirical study of how several large European and US companies managed to integrate their organizations, based on common issues (Ghoshal and Gratton, 2002). Results suggest that four factors (see Figure 1) must be present before this is possible without organizational restructuring:
- Shared knowledge
- Common bonds of performance
- Shared purpose and identity
- Shared infrastructure (common to the other three elements)
Figure 1. Four factors necessary for integrating the organization
Source: Adapted from Ghoshal S. and Gratton L. "Integrating the Enterprise." MIT Sloan Management Review, Fall 2002, and Weill P., Subramani M., and Broadbent M. "IT Infrastructure for Strategic Agility." MIT Center for Information
Systems Research Working Paper No. 329, April 2002
IBM has used this model in a variety of situations with multi-divisional and multi-brand enterprises. It tends to inspire sound debate and agreement among senior executives. Without a shared purpose and identity and without some commonality among performance measures and incentives, it is immensely difficult to coordinate internally. Hence, it is difficult to agree on, let alone to implement enterprise architecture. If organizational units are measured solely on local profit and loss, they might resist efforts to partake in enterprise-wide investments that might produce only longer-term effects, such as global systems implementations.
In multi-local enterprises, where local performance measures are typically purely P&L based, common bonds of performance are frequently nonexistent. This leaves two avenues open to the enterprise architect:
- Either senior management must be persuaded that changes to the incentive structure are needed, in the form of common measures that can promote enterprise integration or enterprise sharing of resources
- Or the different units must be motivated to agree to the enterprise architecture and its actual implementation on the basis of a localized view of the architecture, a localized risk and consequence analysis, and a localized business case
Table 1 summarizes the potential problems that result from variability in the enterprise's strategy, governance, and architecture perspectives and offers ways to respond.
Table 1. Problems and practical solutions
|It is assumed that the enterprise is centrally governed and that those who govern are able to make centrally directed decisions||Perform your due diligence initially.|
Understand the enterprise-level perspective on strategy, governance, and architecture.
Most enterprise executives are empowered and expected to make resource commitments in a multi-local manner, for their own units, more than for the enterprise. So the EA must be made relevant to the units.
|Senior executives or the CIO are skeptical about the value of EA methods||Understand whether management favors incremental approaches and stable outcomes.|
Reshape the methodology by using versioning and modular and incremental architectural innovation.
Focus on how to generate revenue for the enterprise and the local organization, not just on how to deliver the enterprise architecture.
|EA is difficult to justify in financial terms||Focus EA on real business problems. Refrain from justifying EA only in terms of the city planning metaphor.|
Apply option valuation to future initiatives. Calculate NPV of future initiatives with and without the EA.
Create a compelling economic logic behind EA from the outset, not as an afterthought or midway in the initiative.
|Management has a difficult time making enterprise-level decisions||Understand how the enterprise is governed. Is there strong central leadership? Do different organizational units get a lot of autonomy, or is there a federated form of governance, where joint decisions are governed by a well-understood model? The more autonomy that local units have, the more emphasis must be put on the economic logic at the level of the units and the more nuanced and tailored the implementation must be to the needs of the units.|
Consider re-scoping to individual units, Otherwise, the EA engagement must make changes to the governance perspective, which will include changes to incentives, purpose (mission), sharing of knowledge, and infrastructures.
|It is difficult to make the transition from design to implementation||The EA must be localized, meaning made locally relevant and concrete.|
Chart key challenges, issues, and points of resistance within each local unit.
EA design should be expressed in versions and mapped into a road map, letting the EA develop in smaller chunks.
|Management is reluctant to make big leaps||People in the organization might prefer making architectural decisions that are in a natural continuation of decisions that they have made in the past, so they might be reluctant to part with the past. For instance, they might prefer to let local units continue to select their own technology standards rather than use enterprise standards.|
If this is the case, the enterprise architect can continue to invest in understanding current design patterns, technologies, and practices. Then, resort to proposing modular and incremental changes to existing design patterns that lead to gradual transformation and longer-term preservation of investments already made.
|The EA develops within the IT organization and with limited contact with the business side||Consider re-scoping EA to be concerned with coordinating licensing and IT costs, as well as with achieving scale advantages for IT investments across domains.|
- Citations in this article:
- Bartlett, Christopher A. and Ghoshal, Sumantra. Managing Across Borders: The Transnational Solution. Harvard Business School Press, 1989.
- Thomas, L.G. and D'Aveni, Richard. The Rise of Hypercompetition from 1950 to 2002: Evidence of Increasing Industry Destabilization and Temporary Competitive Advantage. Working Paper, Version 2.8.1, October 2004
- Fine, Charles H. Clockspeed: Winning Industry Control in the Age of Temporary Advantage. Basic Books, 1998
- Galbraith, Jay. Building Organizations around the Global Customer. Ivey Business Journal. September-October 2001.
- Ghoshal, Sumantra and Gratton, Lynda. Integrating the Enterprise. MIT Sloan Management Review, October 15, 2002.
- Marcus, Lars. On Architectural Knowledge. Umeå University, School of Architecture, Royal Institute of Technology, CERUM Working Paper 26.
- Porter, Michael E. Competitive Advantage: Creating and Sustaining Superior Performance. Free Press, 1998
- Prahalad, C. K. and Y. L. Doz, Yves L. The Multinational Mission. Free Press, New York, 1999
- Explore the IBM Enterprise Architecture Solutions and Enterprise Modernization web pages.
- Find out more about managing EA with Rational System Architect software.
- Visit the Rational software area
on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Subscribe to the developerWorks weekly email newsletter, and choose the topics to follow.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Watch developerWorks on-demand demos, ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
Get products and technologies
- Download a free trial
version of Rational System Architect or other Rational software.
- Evaluate other IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
- Join the Enterprise Architecture and Business Architecture forum to ask questions and participate in discussions.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Join the Rational community to share your Rational software expertise and get connected with your peers.
- Rate or review Rational software. It's quick and easy.
Jan is IBM's Executive Architect and Client Technical Adviser for the State of California, where he serves the public, healthcare, and educational sectors. Previously, he was the Enterprise Architecture and Technology service area leader for IBM in Northern Europe, served on IBM's Worldwide Enterprise Architecture Council, and was the Application Innovation Services leader for IBM in the Nordic countries. Before working for IBM, Jan worked in a series of positions as adviser and enterprise architect for private and public sector companies in the Nordics.