VCDX Part 2 – Building your Design

By | October 31, 2017

Building your Design

How do you start? There is plenty of advice available already on selecting a design and what makes a good design, but essentially a real-world design with customer inputs for requirements and justification, will help tremendously in being successful.

In terms of putting a design together, the architecture document, I had a few challenges and it also took me some time to find a structure that I was comfortable with that covered all the blueprint areas. To begin with, my design was based on a real customer design, but I only had a set amount of days within the PSO engagement to put the design and documentation together.

There is much talk around using templates or SETs available from VMware, the advice already out there stands, in that these documents are not tailored to the requirements for VCDX. I did start with a template (SET), but eventually cut this down to leave only the front page, contents, version control, content, Purpose and Overview section, plus the Appendix.

I structured the customer design, in terms of conceptual, logical and physical sections, which enabled me to take the design after the engagement and modify this against the blueprint. This approach definitely saved some time, but the level of detail required for the VCDX versus what the customer expected, is quite different. Also, I didn’t have months to put this together for the customer, so it was about balancing out the level of input for the customer and making sure I could take this forwards.

After I had finished the design for the customer, I needed to take this to the next level and match the blueprint. I had covered some of the areas for the customer design, but other areas I was lacking. I wrestled with actually finding a flow and storyline to my design, which was readable and made logical sense, rather than throwing the reader around to different areas of the design. I’d partly done this from my customer design, but needed to make some more changes for the blueprint.  This blog post by Johan van Amersfoort really helped in focusing on this requirement. It also helped I was aiming for the same track (DTM) as Johan, so I could relate to his storyline.

Personally, I used the above blog post for guidance to assure I was on the correct track, but continued to make my own changes. This is important because it means you are writing in your own style and customising based on your interpretation of the blueprint, instead of purely copying someone else’s layout.

To provide a sample, my Architecture document looked something like this (not everything is covered).

  • Version History
  • Contents
  • List of Figures \ Tables
  • List of Logical Design Decisions
  • List of Physical Design Decisions
  • Purpose and Overview
    • Audience
    • Design Approach
    • Design Qualities
    • Executive Summary
    • Business Overview \ Drivers
  • Conceptual Design
    • Business requirements, Constraints & Assumptions
    • Risk Analysis
    • Design Dependencies
    • Desktop Assessment
    • Use Case Definition
    • Conceptual Architeture Blueprint
  • Horizon View Architecture
    • Conceptual Blueprint
    • View Pod – Logical \ Physical
    • Desktop Pools – Logical \ Physical
    • Virtual Desktops – Logical \ Physical
    • Design Summary
  • Desktop Management Infrastructure
    • Compute – Logical \ Physical
    • Storage – Logical \ Physical
    • Network – Logical \ Physical
    • Databases – Logical \ Physical
    • Design Summary
  • Desktop Resource Infrastructure
    • Compute – Logical \ Physical
    • Storage – Logical \ Physical
    • Network – Logical \ Physical
    • Design Summary
  • End User Experience
    • Application Integration – Conceptual\Logical\Physical
    • Profile Management – Conceptual\Logical\Physical
    • Endpoint Devices – Logical\Physical
    • Design Summary
  • Business Continuity and Disaster Recovery
    • Service Definition
    • Logical Design
    • Design Summary
  • Security
    • Logical\Physical
    • Design Summary
  • Systems Monitoring
    • Choices
    • Logical\Physical
    • Design Summary
  • Maintenance and Upgrades
    • Choices
    • Logical\Physical
    • Design Summary
  • Appendix
    • References
    • Bill of Materials
    • Service Accounts
    • Anti-Virus exclusions
    • Network Ports

Sample – Logical Design Decision

This is fairly standard based on other samples provided by the community, however I wanted to include an Impact table that clearly showed the positive or negative impact of each design choice, against the corresponding design qualities.

For me, this helped demonstrate a comprehensive analysis of the impact of my design choices, and showed why one design choice may be better than the other. The option highlighted in green reflects the selected design choice.

This particular design decision only had a minor risk, however other decisions had major design risks, and these were stated and referenced back to the risk analysis table (i.e. RK013)

Sample – Physical design decision

Shown below with a reference to the logical design choice (AC.H7.11). At this stage, I didn’t feel the need for an additional Impact table as above, as this is shown in the logical design choice.

Sample – Design Summary

At the end of each section, I provided a design summary table. This isn’t absolutely necessary, but I picked this up from the community and thought I’d add this into my document, to conclude each section with a compact summary, more for a refresher if needed. Some of the sections were quite lengthy, so this rolls up the table into one small, easy to consume table of information.

Sample – Design Decision Tables

At the top of the document, I created two indexes to all my logical and physical decisions. This helps the reader target a particular area or design decision if needed.

I had around 60-70 Logical decisions in total.

I had around 70 physical decisions in total, although I wrapped a number of different configuration items such as vSphere HA settings, into one table and made that one design decision. Partly this was down to the format of table I selected, as I could have doubled my total page count by using a different design reference and table for every single setting.

The VCDX reviewer only has four hours to review your architecture design, plus supporting documents, therefore being efficient and as compact as possible is recommended.

Conclusion

Hopefully this provides some guidance on putting the architecture document together, which is really a personal preference in terms of layout, formatting and style.  Also, another obvious statement, but version control is critical here, in case the document or formatting gets in a twist! I had to wrestle with good old Word a few times, fortunately the Word version is about 10 times better than the Mac version! You should end up with several versions of the document by the end and a backup in different places (local SSD, NAS, USB and cloud!) 🙂

Leave a Reply