Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
This is the second posting in our “EA Roadmap for success” series. In this posting we zoom in on the use of enterprise architecture in organizations. More specifically, we confront a top-down / strategic approach to architecture with a bottom-up / emergent approach.
Top-down / strategic architecture
For many organizations, Enterprise Architecture is seen as a strategic discipline that helps to link strategy to execution. The idea is simple:
The scope of the architecture effort is the whole enterprise
Various points of views are considered and linked when trying to answer the strategic question “how should we organize ourselves?”
Consensus is built by linking perspectives with a model-based approach
Using a structured and model-based approach improves the quality of realization / implementation projects
Adopting the top down approach, strategic choices lead to a new vision for the enterprise. These strategic choices can for example pertain to the positioning of the organization, the business model, or even the operating model. The new vision is fleshed out in more detail in a “baseline” and a “target” architecture, which leads to a high-level roadmap with several courses of actions that should be pursued using a portfolio of projects or programs.
The courses of actions and programs from that result from this first iteration are often too broad and too high-level to directly translate into actionable pockets of work. Especially in larger, more complex organizations. A second iteration is needed to further detail the baseline and target architecture and resulting gaps that need to be addressed. In this second iteration the focus is on the level of segments, in TOGAF defined as “a detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity”. This iteration leads to projects at the level of individual capabilities. Eventually these capabilities are implemented, resulting in the actual implementation. This fragmentation in a strategic, segment, and capability level is depicted in the figure below.
In the top-down approach the architecture capability of an organization is involved in the future of direction of the enterprise, making high-level, strategic decisions about organization structures, processes spanning organizational structures as well as IT.
This contrasts heavily with a bottom-up approach to architecture. As the name suggests, this approach is much closer to actual operations. Indeed, we see a lot of organizations adopting an approach where the primary goal of architecture is – paraphrasing one client we recently helped – to “make sure that projects behave as they should”. In practice this implies such themes as:
Standardizing architecture output (models, deliverables e.g. an architecture definition document) for the various domains involved (business, data, application, integration, infrastructure etc.)
Defining architecture standards and setting up a standards base
Managing compliance with the standards base through projects
Guiding implementation projects with impact analysis and Project Start Architectures (the TOGAF name for this artifact is the Architecture Contract)
The underlying logic is solid: getting to grips with project management is a pre-condition for doing “bigger things”. Indeed, we see that this approach leads to less scope creep, less overrun of budget and time, and higher acceptance / success rate of project deliverables.
With architecture firmly embedded in the project / change management discipline, the goal is to slowly grow, one step at a time. Typically this means that architects get involved in prioritizing projects, help to define portfolios of projects, and work on a set of principles that are used for strategic decision making about change. In this perspective, principles are frequently used as a basis to guide projects (normative restriction of design freedom), to guide decision making about technologies and standards and so on.
Top-down or bottom-up?
Ultimately, both approaches cover similar topics. It is mainly the roadmap that is different: one starts ‘at the top’ with roadmaps and works its way down, the other starts with standards and compliance, and slowly works its way up to the strategic level of the organization. Both approaches have their merits, and many examples can be found to argue the case for one or the other.
Which one of the approaches to use depends on many variables: complexity, scope, size, maturity level, level of formality, culture, history etc. Recently one of our colleagues posted a series of blogs on implementing an enterprise architecture function in different types of organizations. Experiences from our consulting practices described there could be an interesting source of inspiration as input to choosing the right approach.
For organizations that start with architecture, or are ready to bring their architecture function to the next level, the world is not black and white though. The focus should be selecting a topic where architecture can quickly add value, and go from there. Once a theme for the near future is defined, architects should work with management to agree on a set of KPI’s for which they are accountable so that success becomes visible throughout the organization. Once this is achieved, one can start thinking about the next step.
In our next posting we zoom in on embedding architecture in the organization, and link the discussion to these KPI’s, so stay tuned!
If you’d like to know more, please leave a comment. The next post in this series covers embedding the EA practice. It is scheduled to be posted on the 10th of December.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: