Much of the value of the enterprise architecture process is derived from the artefacts created during the complete process -- the definition of enterprise business strategy, enterprise business architecture (EBA), enterprise information architecture (EIA) and enterprise solution architecture (ESA). Therefore, organisations that take "shortcuts" to the final definition of their enterprise technical architecture (ETA) will lose much of the value to be gained from the architecture process.
"It is vital that architects and their partners begin the architecture process by understanding what is `driving` the organisation and articulating the broad outlines of business strategy," says META Group analyst Richard Buchanan. "This should be done in business language, which means defining the enterprise in terms of the enterprise`s market and competitive space, threats and opportunities that the enterprise faces, the competencies that the enterprise must develop for the future, and the regulatory and other challenges that the enterprise faces. Achieving such an understanding requires creative collaboration between IT professionals and business decision-makers."
Once business strategy is articulated, it becomes the basis for defining a set of future-oriented change requirements. This is the start of the process of defining a common requirements vision that links forward-looking business strategy and the actual processes, information requirements, and, ultimately, solutions and technical requirements that the enterprise must address.
The common requirements vision contains the answers to why the enterprise needs to invest in technology, such as new applications or shared infrastructure services. It links these IT investments back to the business strategy. Developing a common requirements vision is a key success factor that links strategy and the plans for executing it.
In addition, a coherent set of architectural principles for enterprise business, information, solutions and technical architecture needs to be developed. This conceptual architecture phase provides guidance to developers, engineers and business process experts, encouraging them to employ best practices in their work.
A common error is to identify the enterprise architecture process with modelling exercises. Detailed modelling is only possible, and should only start after the previously mentioned initial phases are under way. However, architects should not get bogged down in too much detail, either at this or any other level of the exercise, to avoid the risk that the architecture never catches up to the fast-changing business environment. The underlying goal of enterprise architecture -- successful (and timely) business transformation -- should never be forgotten.
"We need just enough architecture just in time," says Buchanan. "Rather than seeing the enterprise architecture effort as an attempt to paint a portrait of the world, architects should focus on the 20% of major threats and opportunities that will have 80% of the impact in the business portfolio."
The relationship between EBA and EIA is particularly close -- they may be seen as complementary images. The EBA describes business strategies in terms of the specific processes, functions and organisation structures that must be leveraged to achieve the strategy. The EIA defines the information that must flow across these processes, functions and organisational structures to make them executable.
In the real world, business processes and related information cannot be separated, but during the architecture analysis phase, they must be logically distinguished to clarify thinking and identify innovative ways to engineer business-relevant computing systems. The architectural team may start with EBA, but it will quickly find that it must define the associated information with each process, making this an iterative exercise.
In fact, all architecture efforts are iterative, organic and evolving. Ultimately, the architectural team must go back and build out all these "architectures" (EBA, EIA, ESA, ETA) to a deeper level of detail, resulting in a series of interlinked, harmonious, detailed models. The team must keep all these models and their links to the higher-layer abstraction of the common requirements vision in harmony, over time, as business conditions and strategies change to guide IT in its efforts to support those changing strategies.
The result of this process is an audit trail of linkages that shows how each IT investment decision relates directly back to enterprise business strategy. This is important for both justifying IT expenses to the CFO and senior management, and providing a clear guide for adjusting those investments as business conditions change.
User Action:
Enterprise architects should start the architectural effort by understanding what is "driving" their organisation and its business strategy. They should then develop a common requirements vision that identifies the business, information, solutions, and technical "change requirements" implied by the business strategy. By adhering to key principles articulated in a conceptual architecture, modelling "just enough architecture, just in time" will be possible, enabling architects to grapple with profoundly important, broad dynamics -- not microprocesses.
META Group analysts Richard Buchanan, Robert Handler, George Paras, Val Sribar and David Cearley contributed to this article.
Share
This article previews one of the topics being discussed in depth at META Group`s worldwide METAmorphosis 2003 conference series -- at seven locations worldwide between February and May. Richard Buchanan, one of the authors, will present at METAmorphosis South Africa 2003. Click here for more information.
Editorial contacts