Strange Bedfellows: Enterprise Architecture and Urban Planning

City plans and zoning boards. Building codes and inspectors. These concepts are quite familiar in the field of urban planning. Do they really apply to enterprise architecture?

Surprisingly, the answer is yes.

An architecture blueprint is an important enterprise architecture deliverable that creates a city plan for an organization’s IT assets. The blueprint enables the architecture team to perform architecture governance. The governance function is akin to a zoning board, which determines whether development or purchase of new IT assets is in accordance with the blueprint.

Likewise, reference architecture defines the building codes for new assets. When architects use the reference architecture to assess IT assets, this is akin to the role of a building inspector. Reference architecture is also used in an architecture blueprint as a lens to understand the current state of the architecture portfolio of assets and to map the architecture transition to a higher quality, simpler, and lower-cost future state.

In this article, you’ll learn about a four-step process for creating an architecture blueprint or city plan. Following this process will enable you to create an invaluable tool to guide your enterprise in making thoughtful architecture decisions regarding its IT investments.

Introduction to the 4C Architecture Blueprinting Process

Collect. Classify. Cluster. Consolidate. Repeat. These are the steps of the 4C architecture blueprinting process.¹ Let me briefly review these steps before you examine them in more detail.

The 4C architecture blueprinting process begins with collecting information about an IT portfolio. This information is classified into relevant zones of IT assets. The cluster of assets in each city plan zone is assessed and given a disposition. An architecture transition plan is developed to consolidate the assets in each zone. This process is repeated at regular intervals to refresh the blueprint and to ensure it remains relevant to the enterprise mission.

Step 1: Collect

Step 1 of the 4C architecture blueprinting process begins by collecting information about your organization’s current IT portfolio assets.This step provides the raw inputs to be analyzed in the classify, cluster, and consolidate steps that follow.

The collect step gathers information, in whatever format is available, regarding all applications critical to your enterprise mission. The content for each application should include the user community, functions performed, service level agreements, transaction volumes, architecture, environments, platforms, resources, recurring costs, in flight projects, and so forth. This information can be gathered from existing architecture documentation, budgets, and interviews with key staff members.

Step 2: Classify

In Step 2 of the 4C process, a scheme to classify an organization’s assets is devised, and the assets are mapped into that classification scheme.

Defining the Classification Scheme

The classification scheme defines the high level city plan zones relevant to your organization’s mission. This scheme, in whole or in part, might come from accepted industry models or leading vendors that focus upon your industry vertical.

A simple scheme I’ve found useful is the function/data/platform classification. This scheme defines the high level functions, data, and platforms essential to an enterprise. Functional zones include the functions across the business value chain such as account management, product management, and billing. Data include all of the major subject areas such as customer and product. Platforms include all of the software and infrastructure needed to run the business such as databases, application servers, operating systems, and hardware.

How does it all tie together? Consider the example of a financial services firm. To run its business, it requires an account management system (function) to maintain customer information (data). The account management system requires an application server and a relational database (platform).

Mapping Assets

Once a classification scheme has been devised, the organization’s assets are mapped to the function, data, and platform classification zones. This provides a useful picture of the organizations IT assets. This data may be collected in a spreadsheet, or in an enterprise architecture tool.

Note that many assets will map to multiple zones. A good example is a Customer Relationship Management (CRM) System. The CRM maps to the account management functional zone. Its database maps to the customer data zone. The system-to-human workflow and integration capabilities inherent in the CRM map to the business process and service bus platform zones.

Step 3: Cluster

Step 3 of the 4C process examines the cluster of assets in each classification zone in detail and determines the business and technical adequacy of the assets. Coming out of Step 3, each asset will be given a disposition of invest (green), hold (yellow), or sunset (red).

Assessing Redundancy

Once assets have been mapped to zones, new insights into the IT portfolio will be evident. You may discover that you have three applications providing account management functionality, that customer information is stored in five different places, and that you have service bus functionality being provided in four disparate places.

Because IT assets were created without a blueprint in the past, you shouldn’t be surprised to find many redundant functional, data, and platform assets.

In many cases, multiple assets within a zone can be quite rational. There may be clear guidelines for using the workflow capabilities in a CRM versus an enterprise business process management (BPM) tool. A division may require autonomy because it may be sold and it doesn’t want its IT assets entangled with those of the enterprise. A merger may have just occurred and the driver behind the blueprint is to assess the assets of the new combined enterprise.

In other cases, multiple assets within a zone can be quite irrational. Lack of an enterprise architecture function may have led to decisions in the past that may have made sense given the myopic view of an individual project, but clearly not for the enterprise as a whole.

In enterprise architecture, application rationalization is the process used to simplify the assets within a zone. In mathematics, rationalization is about simplifying an expression so that it still produces the same result. Application rationalization is similar in that it tries to simplify the assets with a zone while still providing the same business function and level of quality.

Assessing Adequacy

Each asset should be assessed for business and technical adequacy. Adequacy can be assessed by interviewing business and technical subject matter experts, through surveys, service level agreement reports, and through mapping the asset to the relevant reference architecture or building codes.

Business adequacy should be measured by parameters such as functions performed, cost effectiveness, and usability. Technical adequacy can be measured by a quality attribute assessment of how well an application is meeting its design and runtime quality goals. Mapping an application to the relevant reference architecture is useful in the assessment by providing a pictorial view of the assets in layers. Certain qualities, such as maintainability, can be understood by the underlying architecture, budgets, and timeliness of changes.

Determining Asset Disposition

The final part of clustering is determining the disposition of each asset in the cluster. The disposition of each asset will be invest, hold, or sunset. The figure below provides some guidelines for how assets should be rated.

Figure 1: IT Asset Disposition Guidelines

Step 4: Consolidate

Step 4 of the 4C architecture blueprinting process determines the consolidation approach for each cluster through an architecture transition plan.

Architecture Transition Plan

The architecture transition plan uses the reference architecture or building codes to determine the current state of the zone, the rationalized future state, and the series of steps required realize the future state. Multiple options might be outlined to replace assets marked for sunset.

The benefits of transitioning the architecture can easily be articulated due to the business and technical adequacy assessments done previously. However, execution of the architecture transition will be dependent upon investment in rationalization projects or through funded business initiatives.

Step 5: Repeat

The city plan zones will stay stagnant in many enterprises. However, the assets within them will vary. The blueprint must be refreshed on a regular basis to remain relevant.

City plan zones will need to be updated to reflect:

• Newly acquired assets
• Updated business and technical adequacy assessments of current assets
• Updated architectural diagrams reflecting the changes to assets by the execution of architecture transition plans
• Retired assets

Putting the Architecture Blueprint to Work

An architecture blueprint is an invaluable tool to guide an enterprise in making its IT investments. The blueprint, like any tool, does no good sitting in the toolbox. It needs to be taken out and used regularly.

If there were a 5^th C in the blueprinting process, it would be communicate. The facts learned and the insights gained from the blueprint will be of interest to key business and IT stakeholders. The blueprint will help guide the enterprise in making fact-based decisions about its future.

If there were a 6^th C, it would be commitment. Once understood, the blueprint should be committed to by business and IT stakeholders to use it as a guide and to keep it up to date. The thought put into the disposition of assets and architecture transition plans will make decisions easier going forward.

The architecture governance board will perform its zoning function using the blueprint or city plan to guide the evolution of the IT portfolio toward a higher quality, simpler, and lower-cost future state. Proposed investments that are not in alignment with the blueprint will have a difficult time getting governance approval to proceed; for example, investments in assets marked for sunset. Investments in alignment with the blueprint and architecture transition plans will be accelerated.

An architecture blueprint is a deliverable that helps crystallize the IT strategy. Investing the time and effort to create one helps an IT organization to better serve the business that is always looking for ways to improve quality, agility, and to reduce costs. The blueprint helps IT to be a better steward of the organization’s IT assets. With the architecture blueprint in hand, IT is well prepared to be a trusted partner when business strategy efforts begin.

Summary

You discovered that an architecture team can learn a lot from urban planning. An architecture blueprint is essentially a city plan of an organization’s IT assets. Reference architecture represents building codes for new assets. Architecture governance performs a zoning function to guide its overall city planning responsibility and to ensure newly developed assets are created in accordance with defined building codes.

The 4C process for creating an architecture blueprint collects information about the IT portfolio, classifies it into relevant zones of assets, examines the cluster of assets in each zone, and develops an architecture transition plan to consolidate the assets in each zone. This process is regularly repeated so that the blueprint will continue to be relevant.

Does your architecture team have an architecture blueprint to enable it to guide the evolution of the IT portfolio over time? Does it have a governance board to perform its city planning responsibility? Are relevant building codes for new assets defined through reference architecture? If not, consider creating an architecture blueprint using the 4C process as your guide. The rest is up to you!

References

1 The term 4C was coined by my colleague and friend, Mike Stevens, who is known for his books on Enterprise Architecture and SOA. Mike and I co-developed the 4C blueprinting methodology and employed it at a major financial services company.

About the Author

Jeff Ryan is an enterprise architect with over twenty years experience architecting and implementing thoughtful solutions to business problems. Jeff co-developed the architecture blueprinting process described in this article and led architecture blueprinting efforts using the 4C process. He has published over twenty articles on enterprise architecture, SOA, XML, XSLT, Java, and other subjects.