A few days ago we facilitated a passionate discussion on the subject of Blueprints (ah, the joys of an emerging market). The gist of the conversation was focused on deciding where limited marketing resources should be applied, and during that exercise a surprising insight came to us. It seemed so counter-intuitive at first, then as we kept exploring it became so blindingly obvious that we questioned our intelligence for not thinking of it before.

What was this revelation, you ask – and more importantly, why should you care?

An Architect doesn’t need a Blueprint.

Let’s step outside IT for a moment and use the analogy of a Blueprint for a building to illustrate this point, since no one questions the value of either an Architect or the Blueprint in that context. The Architect has the smarts; with years of experience they interview the client to gather requirements and constraints, show possible designs and articulate tradeoffs, and then eventually labor to codify the design decisions into a complex multi-dimensional Blueprint. If all goes well the client signs off and, unless there is a problem when the structure is being built or the client changes their mind, their job is done.

But the Blueprint is just getting started...now it gets handed off the general contractor, who in turn provides relevant pages to the subcontractors that do everything from excavating the foundation, to installing plumbing and wiring, to interior decorating. The general contractor also provides the Blueprint to the relevant inspectors, who reference the Blueprint as they audit the facility to ensure its compliance with building codes and other ordinances. And once the structure is completed, the Blueprint is provided to the party responsible for operating the building, where it’s consulted whenever a change is proposed or when trying to diagnose a difficult problem. In this context, it’s pretty clear that the while the Architect creates the Blueprint, they are the ones who use it the least. However, the Blueprint is essential to communicate what’s going to be built by a number of different groups, to audit what’s actually been built, and to serve as the authoritative reference when a change is proposed or when a complex problem is observed.

If we bring this back to the realm of IT there are strikingly similar parallels. We have an Architect assigned to design an environment to support a new application/business function, or perhaps to replace an existing one. Step one entails an interview with the business user or their proxy to understand the purpose of the system, and to capture requirements and constraints. The architect then does their work, selecting from enterprise standard technologies and assembling them in a manner that they believe will meet the requirements. They draw diagrams, create a document with cost and time estimates, and then go back to the business user for approval. Assuming that approval is granted, the service request is then fired off into the enterprise process for procurement, engineering, and system builds. Many different groups, many different processes, many dependencies – all trying to provide the system the business needs, but frequently ‘interpreting’ the request based on their view of the world and without a clear understanding of the impact of changes or delays in their work to the overall process.

In most environments we have seen, the diagrams and document originally created are filed in the appropriate repository but each group has their own documentation process and thus uses the original specification approved by the client as ‘input’ to their process. When it finally makes it through the QA/test function to production, the Operations team is given a handful of documents to keep track of (typically stored in different places), so they too create a document suitable for their purposes using ‘input’ from the others. Have you ever watched a group of young children play the game “telephone”, where a message is whispered from child to child? The final message rarely resembles the original. Is it any wonder that IT continually fails to meet business expectations?

Now to be fair to Blueprints, they offer a lot of benefits to the Architects as well. They provide a common language and template for communication that all parties involved recognize and understand. They also provide a great starting point when designing a new widget with similar requirements as one they created in the past. And they certainly help a journeyman Architect perform at a much higher level than they might otherwise, which provides both scale and consistency benefits.

But in the end, does the Architect really need a Blueprint? No. But everyone else sure does.

• The Enterprise IT Economic Model Blueprint for the Cloud
• Building the Cloud Blueprint for Enterprise IT