Enterprise Planning & Architecture Strategies

The scale and complexity of the enterprise architect’s task can easily be overwhelming. Without careful discipline, enterprise architecture (EA) teams often become minutia-driven and lose the enterprise perspective. Focused EA teams exploit a systematic EA process to define strategic requirements “in the context” of the business and then construct future-state deliverables consistent with real-world priorities.

META Trend: Enterprise architecture (EA) success will be determined by the extent to which corporate and line-of-business managers comprehend, support, and enforce the architecture. By 2007, 15 percent of EA core teams will move out from under the IT organization’s management structure, with direct reporting relationships to either corporate strategy or corporate change management functions. By 2007, 40 percent of enterprise architects will have primary expertise in business strategy or process engineering.

Perfectionism is the enemy of the good. This well-known adage must be learned by every enterprise architect. In our study of EA teams, we often see them lost in the details, missing the forest for the trees. Enterprise architects are often driven by myriad detailed requests from users who expect the EA team to perform as an engineering organization. In their desire to deliver, and consistent with their prior training as engineers, many enterprise architects are happy to oblige. They strive to deliver the perfect set of models, at all possible levels of detail, for all possible audiences. Enterprise architects often exacerbate their situation by succeeding, demonstrating this competency on a particular project and thereby setting a high bar that results in future detailed involvement with all project teams. Enterprise architects must remember that their primary mission is not just to be an engineering center, but to provide a realistic, contextual enterprise basis for strategic decision making and cross-enterprise implementation consistency.

Many EA teams drive themselves to this overly detailed view by mistakenly attempting to fully populate the perfect “map” of models from the very beginning. Striving for “completeness” can disorient teams from their real mission. Despite the many virtues of perfectly complete taxonomies of models, these rarely help architects identify where to start or to determine when they have done enough. High-level model taxonomies are useful when used as a tool for clarifying architectural thinking. Unfortunately, they can leadto large, all-encompassing EA efforts that may not deliver meaningful results to the business before being shut down.

Just as business needs should drive the content of the EA effort, business needs should also drive the process by which the EA is developed. This process must consider business culture issues as well as business drivers (see Figure 1).

Source: Meta Group

Just in Time: First Things First. Enterprise requirements must first be defined through a common requirements vision (CRV), and the conceptual architecture must be developed. Only when these prerequisites have been met should the architecture team focus on detailed architecture model development. A best practice is to focus EA attention first on models that are most critical to the business. Two primary tests can be used to prioritize this work and demonstrate early results from the architecture effort:

Top priority should be afforded to models that can be directly linked to strategic opportunities as revealed by earlier analysis driven by the CRV. Determining the “strategic fit” between business strategies and lower-level details should be a joint effort by enterprise architects and LOB managers. The second test identifies the architecture models that have already been fairly well defined and standardized, even if not widely publicized. Existing principles and standards may require clarification, modification, or re­engineering, but have at least been tested in the real world. Their strengths and weaknesses are understood, and operations personnel have been trained to deal with them. If these principles and standards still have value, incremental migration efforts can yield early results.

As an example, companies focused on expansion into global markets have a strong need for a common global communications environment, cross-regional collaboration, and knowledge management. An EA effort focused on global integration standards, information policy, and collaboration tools can quickly show business value. Companies growing their revenues by acquiring firms in related businesses in the same geographic regions will benefit from cross-business synergies in customer management and target marketing. EA model development strategy should focus first on issues surrounding information management, integration, CRM, and enterprise analytics. Other areas should carry lower priorities.

There are often existing implementations that may already represent de facto standards within the company. Years of legacy investment have led many organizations to create “engineered platforms” that are rigorously documented, stress-tested, and upgraded in a disciplined fashion. The architecture team should leverage this managerial discipline by quickly putting it beneath the EA umbrella. By producing results quickly in a few areas and recognizing and incorporating existing best practices, the architecture team emphasizes the EA effort as one that is intended to produce actionable results linked to real business needs. The EA effort then becomes a two-pronged approach: implementing the defined architecture consistently (through transformation and EA Assurance processes) and the further creation of additional, newer, or more spanning models. Both paths must be managed together for consistency and interdependencies.

Just Enough: For This Company. Culture and the overall acceptance of the EA program drive when, where, and how much EA model detail can be introduced. The EA Process Model defines several dimensions of detail for each model (see Figure 2). It is ultimately up to the business managers to enforce architectural compliance; they will not enforce architectural standards beyond the point where they think they will realize business benefit. Therefore, though EA teams may feel driven to fill in the detail, developing that detail is unnecessary and may be counterproductive.

Source: Meta Group

For example, an aggressive, entrepreneurial company may not define standards down to the configuration level in all areas. For this firm, the perceived value of a standard approach to everything is questionable when weighed against innovation and time to market. By definition, the business model grants a certain freedom to experiment and the culture reflects that. That said, sound business management says to not reinvent the wheel where one exists. Business managers usually agree that common approaches (for example, principles, technologies) are necessary and enforce them in some areas but often do not see the benefit of more detailed specification in others.

Getting to the correct levels of architectural detail is a discovery exercise. The consequence of not having that detail becomes visible as barriers to achieving business objectives. Many companies see this need, hence the resurgence of EA efforts. But counterarchitectural attitudes do not disappear overnight. Successful architecture teams peel back the layers one at a time. The key point is that architectures sometimes fail because they answer questions that no one is ready to ask. By focusing on realistic detail levels in areas directly valuable to the business, the EA effort maintains credibility in the face of skepticism from the business and the IT community.

Just-Enough, Just-in-Time Approach: Risks. This approach is not without risk. By developing models based on business priorities, it is easy to overoptimize the “first born” models at the expense of future models. It is important to follow the EA process and define the early models holistically at the highest levels of detail so the overall picture can be seen and enterprise-level optimization can be achieved.

Business Impact: Organizations that drive enterprise architecture to the correct detail level optimize aggregate implementation to improve enterprise performance, quality, and profitability.

Bottom Line: Architecture initiatives which outrun business requirements and fail to show early, meaningful results cannot be sustained. EA efforts that do not take into consideration long-standing cultural biases concerning discipline and standardization will be ignored.