January 25, 2021
Hot Topics:

The 4C Architecture Blueprinting Process

  • By Jeff Ryan
  • Send Email »
  • More Articles »

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.

IT Asset Disposition Disposition Guidelines
Invest (Green)
  • Strategic assets
  • Investment warranted to improve business or technical adequacy
  • Rationalization target
Hold (Yellow)
  • Adequate from a business and technical perspective
  • Investment not warranted at this time
Sunset (Red)
  • Non strategic assets
  • Asset dependent upon end-of-life platforms
  • Inadequate from a business or technical perspective and investment not warranted
  • Application to be rationalized due to redundancy

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 5th 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 6th 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.


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!


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.

Page 2 of 2

This article was originally published on February 11, 2008

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date