One of the changes made last year by the VCDX program team is the need to document your changes if you are resubmitting for another attempt. It also mentions that minor changes can be addressed in the next defense presentation slide deck and significant changes are made to the design, the candidate will be required to submit a full change log showing all changes.
Now, I would agree that it’s a bit unclear and confusing to understand what is a “minor” and what is a “significant”. I think a reasonable way of looking and handle with this one will be straight forward common sense. Let me try and explain by using my own design resubmission.
For my second shot, I had to change few things. Most of those changes were minor ones but there few that I considered significant changes. During my prep, I discuss it with several people and wanted to know what they think the level of details in the change log should look like. On one hand, one may think “I don’t want to give too much so I won’t be asked about it” but is that really the VCDX way – I think not!
If you did any changes and document those in your log, you should be able to stand behind it and, well, defend it – isn’t this what it’s all about?! Yeah, maybe you will catch a break and no one will ask you about the change you made but that’s not really the point. As an architect, you should be able to document changes coming as a result of new requirement / constraint / risk / assumption.
Let me share with you a couple of examples from my change log. One I considered being a minor one and the more significant.
Without going too deep into the details, in my design I had a small cluster with a single host. To avoid unnecessary potential discussion around availability, I’ve decided to add an additional host. For me, this is considered to be pretty minor but still, you can see the impact on the change log.
The second example is what I consider a more significant change. Again, without going too deep into the details, for my second submission I changed my vCD OVDC Resource Allocation Model from “Allocation Pool” to “Pay-As-You-Go”. For those of you hanging with vCloud Director, you know what impact it can have on a design. Like many other design decisions, this also had a butterfly effect on my design.
I hope that by now you understand what is the approach I took with my second submission. Don’t hide and back up your design decisions, rather on paper or in the defense, this is what makes you better prepared for VCDX.