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.1 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).
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).
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.