Architecture Planning

Finding Balance and Adding Value to Projects with Enterprise Architecture

We are often asked what an architecture plan is and why it is important. As with most things, there isn’t a simple answer to what an architecture plan is. There is no standard template for an architecture plan. Every organization is different, and the nature of the architecture plan changes depending on an organization’s specific needs. As to why it is important, the success of any architecture is dependent on delivering value, and the plan is the means by which the delivery of this value can be managed and measured.

INTRODUCTION TO ARCHITECTURE PLANNING

Once you understand the objectives of your architecture initiative, planning is key to ensuring that you deliver a successful architecture program. There are two aspects to any architecture plan:

1. A schedule for building the organization’s architecture capability
2. A definition of how and when architecture benefits will be delivered

Getting the plan right is often the starting point to success. This article focuses on the nature of architecture plans and how to create them.

PLANNING FUNDAMENTALS

The focus of architecture planning can be split into two elements. One part is concerned with building the capability to define and maintain your organization’s enterprise architecture (EA); the second determines how the EA will provide benefit to projects in supporting decision-making processes. If the balance of these is wrong, you can end up with either an ivory tower that delivers no value, or with a project support service that makes project-level architecture decisions rather than taking into account the enterprise perspective and doesn’t, therefore, realize the benefits of enterprise architecture.

Organizations can often fall into the trap of focusing on only one of these aspects at the expense of the other. The two extremes of this can be characterized by the following scenarios:

“IF YOU BUILD IT, THEY WILL COME”

This refers to situations in which an organization decides to build its EA capability by delivering and populating an EA framework. While the organization is focused on the long-term objective of having a fully populated, broad, and deep EA model, often, little thought is given to the projects, or the fact that they will not comply if there is no immediate benefit to them.
This trap often occurs when an organization is starting out from scratch, with no previous experience of EA or perhaps even architecture-driven project delivery. The problem is that, in most cases, this approach will make the EA a long, protracted initiative where confidence and support can erode before the EA begins to show any value to the organization.

“JUST DO IT!”

This refers to organizations that focus solely on delivering models to support a particular project. In this situation, organizations fail to consider how these models will be kept updated and integrated with decisions and other models resulting from other projects and initiatives.

This trap occurs when there is a desire to show the benefit of EA as quickly as possible. Unfortunately, although short term buy-in is achieved, the EA quickly becomes uncoordinated and difficult to manage.

A good architecture plan will deliver a coherent EA by balancing the effort required to build and populate an EA framework with the effort to provide effective project support. These two things are not mutually exclusive as the former provides the framework within which projects can deliver consistently and more quickly, and the latter is a mechanism for populating, testing, and evolving the EA.

Relationship between the architecture plan, projects, and the overall architecture capability

KEY PLANNING QUESTIONS

To achieve the required balance between EA capability development and short-term benefit to projects, there are some key questions that the architecture plan must answer.

Scope: What is being delivered by the EA?

EA can be broad, so the focus must be on the key elements that will deliver value. The output must be of use to projects; the projects should be spoken to, and the areas of need that EA can support identified.

Each element of the architecture must be justifiable. Why is this element important? Is it saving money? Is it shortening project delivery times? If it is not possible to explain the concept sufficiently well to get buy-in from projects, then, although it may be the right thing to do, it should be dropped in the short term in favor of an element that has clear benefit. It can be re-introduced when the architecture initiative is embedded and fully bought-into.

Timing: When are the elements of the EA to be delivered?

To reiterate, the architecture plan needs to meet two objectives. One, deliver an EA; two, deliver value to projects. The latter should be seen as a mechanism for delivering and populating the former, and it is also key to gaining traction for the EA.
A large amount of the output must fit with the time scales of when projects require it. The plan needs to identify the architecture information that projects require and that is also of use to the EA effort. It needs to understand when the information is required by the project, what role (if any) that enterprise architects will play in the projects, and how the output will be captured in the EA model. The important thing for the architecture team to do is to focus on delivering value to projects, as this will prove the benefits of EA and give it traction.

Above is a section of a high-level view that was used at a global financial company to show the project/architecture split of responsibilities in a major initiative.

Maintenance: How is the EA to be kept up-to-date?

There needs to be a defined process for keeping the EA information up-to-date. If the culture is not geared to doing this, then it may initially be a centralized EA team exercise. However, the aim must be to introduce a process into the project activities over time. There needs to be an activity in the plan to define this process, execute the process, and provide updates and reviews. The nature of the organization will determine when this activity appears in the plan, not whether it appears.

The diagram above illustrates the project updating the architecture and also the architecture keeping the project informed of related decisions or changes elsewhere that have an impact on the project. A process to ensure that this happens must be defined and monitored.

KEY DECISION FACTORS

Architecture plans are not off-the-shelf, one-size-fits-all exercises. The creation and development of the architecture plan requires some careful thought because it has to fit with the demands of the organization, and it will be influenced by a number of factors.

Culture

If the organization is not geared to following processes, procedures, and rules, all of which are important in any architecture effort, then, typically, the enterprise architects will find inconsistency in the information and detail that projects deliver—both in the level of information captured and the way it is presented. Without some formality, population of the architecture can be difficult. The plan needs to reflect the maturity of the organization in terms of processes, procedure, etc. EA success is harder to achieve if you try to impose a large amount of formality on an immature organization.

As an aside, it can be a good opportunity to demonstrate the benefits of EA, as organizations that behave in this way tend to have a lot of EA opportunities.

Previous Experience with EA

Any previous attempts at EA by an organization will heavily influence how receptive projects are to a new plan and its associated architecture. If previous attempts at EA were seen as a hindrance to projects, then buy-in will require careful thought. If it was seen as a good idea but an ivory tower, then a different approach may be needed. If a previous EA initiative is being superseded, then planning needs to involve people who had previous experience and who have views on what worked and what didn’t.

Existing Projects

Any project will benefit from some degree of architecture support. The plan needs to make sure that the architecture is delivering outputs that benefit both in-flight as well as planned projects. It also must ensure that the architecture is populated in line with the project outputs. If it does not deliver value to projects now, then it will quickly gain the ivory tower tag and lose credibility. It is critical to understand what the projects need, what their time lines are, and what the EA can do to support them.

Communication

Communication is an essential factor in the successful delivery of any plan, and EA is no exception. Your plan must include a communication plan considering the following: who the stakeholders you need to communicate to are, how you plan to communicate with each of these groups, what you will be communicating to each group, and when you will need to communicate this information to them. Remember that communication is an ongoing exercise from the initial selling of the concept, through the benefits and successes to gathering feed-back for improvements.

SUMMARY

When creating an architecture plan, an organization should initiate two streams of work. One identifies the framework within which enterprise-level information will be captured and shared, and the second focuses on identifying the key areas of need for projects.

A successful plan that achieves the correct balance between these two elements ensures that each project gains some benefit from the EA and promotes the view within the organization of EA as an aid to project delivery and change. In addition, the delivery of the EA framework must proceed incrementally through each project, changing the way the organization works over time until a full EA is in place. This is a long-term plan that will need many updates and iterations from inception to completion—completion being an enterprise architecture that is fully integrated into the project life cycle and day-to-day running of the business.

The key to success is in correctly defining the balance between these two aspects of the plan. By assessing the culture of the organization, its EA maturity, the experiences it has had to date with EA, and the projects that are in its portfolio, this balance can be found. This will enable you to identify which elements of the architecture should be focused on initially and produce a meaningful communication plan to engage both the senior management and the project teams, and enable them to understand the short- and long-term aims of the architecture plan.

Successful architecture plans achieve the right balance between the ability to build and populate a long-term usable framework and the need to provide real value to projects.

by John Mayall