As an Enterprise Architect, you want to produce architecture designs that are elegant and simple whilst meeting your customer’s requirements. It is very important that each design has proportion and balance.
Consider an artist creating a painting, the artist does not churn out a perfect canvas in one sitting, but starts with a broad sketch to define the outline of the painting before filling in the details.
The same process applies here. Get the “bare bones” on paper and then start fleshing it out. If the big picture does not make sense, fix it before you move on, otherwise it will mean more work to correct later on.
List of articles in my VCDX Deep-Dive series (more than 70 posts)
When you rank your Conceptual Model, Logical Design and Physical Design components together, it should look like a pyramid.
In my experience, you should have similar quantities for an Enterprise-level Data Center Virtualisation Infrastructure Architecture Design:
- Business Goals (non-technical and communicated to you by your customer) – 4 to 5
- Customer Requirements – 10 to 20
- Design Constraints – 5 to 10
- Design Assumptions – 5 to 10
- Logical Design – 50 to 60
- Physical Design – 100 to 120
NOTE: The Business Goals section is not specifically required in the VCDX Blueprint, however it is something that I have added to my methodology since it is important and significant. Following the VCDX Blueprint, your Business Goals can be blended into the Customer Requirements section.
Bad Proportions
“The Inverted Pyramid” – you have hundreds of Business Goals, Customer Requirements, Design Constraints and Design Assumptions in the Conceptual Model, but only a few Logical and Physical Design Decisions. There is no way this design will meet the requirements of your customer.
“The Rectangle” – each layer has a 1:1 relationship between your Conceptual Model, Logical and Physical Design. You could create a design with hundreds of artifacts at every level, but it will not scale and be very difficult to read, understand and update.
Realm of Possibility
Great architecture design is layered and allows a broad range of possibility in the upper layers of the design which tightens to an exact solution in the physical design, which is then complemented with matching supporting documentation (in particular the “Configuration Settings”). The wording of each area should facilitate this.
Some Examples
- Business Goals: Reduce Capital Expenditure, Reduce Operational Expenditure, Increased Business Agility, Fastest Time to Market
- Customer Requirements: No Single Point of Failure, Automated Operations, Optimal Performance & Scalability, Four 9s of Availability
- Design Constraints: Customer has a preference for Vendor X, Latest stable release of vendor software/firmware will be used
- Design Assumptions: Data Center Facilities have sufficient space, power and cooling
- Logical Design: IP-based storage will be used, Leaf and Spine Data Center LAN Fabric will be used
- Physical Design: Vendor A Product B will be used for Storage, Vendor X Product Y will be used for the Data Center LAN Fabric
- Configuration Settings: Table describing how Vendor A Product B will present NFS Volumes with the necessary settings to Hypervisor Z
How Do I Fix It?
All of the “unbalanced” content that you have in your design is not wasted, it merely needs to be relocated. Look at converting improperly placed content into new Logical and Physical Design Decisions or relocating the content to the Justification, Impact or Risk sections of existing Design Decisions.
vcdx133.com 