What is a Blueprint?
By pmonday on May 31, 2007
Software blueprinting processes advocate containing inspirational activity (problem solving) as much as possible to the early stages of a project in the same way that the construction blueprint captures the inspirational activity of the construction architect. Following the blueprinting phase only procedural activity (following prescribed steps) is required.
Of course, Thomas Edison may argue with this, saying that "Genius is one percent inspiration and ninety-nine percent perspiration", which would beg the point of why blueprint at all?
My interpretation of a "Blueprint" after much reading and many years in the "(software) architecture" field is simply: A blueprint documents the set of requirements and constraints that need to be fulfilled for a particular solution along with the materials and instructions that implementors would need to solve for the requirements consistently and repeatably. A "good" blueprint will go further to enumerate requirements that the blueprint does not address as well as the specification for materials so that an implementor could safely choose other materials and instructions than were originally specified in the blueprint.
Where blueprints often come into heated debate is in "What form does a blueprint take?" as well as "How deep should the requirements be?". There really is not a simple answer here. In physical construction, the blueprint is a time-honored carbon-like thing with strict rules around elevations and material specifications...I remember this from my 11th grade architecture class and lots of head scratching when I have tried to build out a basement. For software and systems, the answer becomes more complex and is often determined by the tier or layer of the application for which the architect is building the blueprint for as well as the intended audience for the blueprint. A GUI application may have wireframes and look a lot like a physical construction diagram, with border widths and behaviors of the areas of the form. A model or data access tier will likely have table specifications and/or UML modeling involved. A "system" or a "server" (single box) will have a detailed schematic, much like a building architect's blueprint.
Things become more complex with blueprints for solutions that incorporate multiple audiences and types of components (software, systems, cables, cards, etc...). A blueprint for a SAN or a Storage Server would have deployment diagrams, hardware component specifications and software specifications involved.
The blueprint documentation itself must spend considerable time on the requirements and specifications for which the blueprint was constructed and will, hopefully, create a linkage between the requirements and specifications and the materials and instructions used to construct the solution. This documentation helps a user determine if the blueprint meets their needs and where they should concentrate on modifying the blueprint if it is a close match.
For example, I may build a system blueprint for a storage grid built with off the shelf servers. In the requirements and specifications, I concentrate on a a few simple requirements:
- I must be able to add capacity without downtime, from 100MB to 1 Zetabyte
- All storage must be available in a single namespace
- All storage is represented as files
- A storage node must be able to fail in place
I now give you a blueprint for this solution that gives you information about the hardware to use, the software to use, the cabling, the configuration, and more. It looks fantastic.
You easily reproduce the solution from the blueprint. BUT, the result is that you get 1MB throughput with a 5 second latency on a file lookup. This would be the equivalent of giving you instructions to build a house, but not telling you the house is 5" with a total of two square feet space. Ouch. 1% inspiration, 99% perspiration.
Check out some of Sun's Blueprints, they exist for software, hardware as well as solutions. Maybe they'll solve some of your needs. Further, with a little collaboration, maybe we can make the blueprints better by being broader or narrower...or simply more complete have better specifications in areas to aid you in selecting different components or meeting different requirements.
Here are a few interesting blueprints for you to take a look at:
- Tokyo Tech Tsubame Grid Storage Implementation
- Architecting Availability and Disaster Recovery Solutions
Here are some locations at sun.com to find blueprints:
- Sun BluePrints Program - Self described as "Technical best practices, derived from the real-world experience of Sun experts, for addressing a well-defined problem with Sun Solutions.".
- Ajax BluePrints