… or are they?

Every (aspiring VCDX) architect knows design assumptions are the mother of all <….>. Yes, design assumptions are frowned upon and should be avoided whenever possible. But, in certain situations, assumptions can actually be real lifesavers. This blogpost aims to show you how assumptions – when used properly! – can really improve your design and ultimately help you better deliver your project.

Working with assumptions, the VCDX way

If you are on a tight project schedule and there simply isn’t enough time to gather all requirements, have in-depth discussions and workshops over and over with your customer and validate every assumption before having to move forward on your design, assumptions can be an excellent tool of choice. There are some ground rules when working with assumptions however:

1. There must be a valid reason for falling back to assumptions. They are not meant as a quick escape route, or as an easy way out of tough discussions. As an architect, you must be constrained to have to fall back to assumptions. This could be a time/delivery constraint, a knowledge/information constraint, etc. When – after due diligence – you simply cannot validate an assumption within the constraints you have to work with, an assumption is definitely valid to use.
2. An assumption introduces uncertainty in your design. Uncertainty equals risk. As a ground rule, every assumption should be accompanied by a risk identifying and quantifying what will go wrong in the event the assumption turns out to be false. As with any risk, you should always try to architect mitigating measures for this scenario and document them.
3. Assumptions are not to be used to scope certain elements out of your design just to be done with it. If you somehow identified, for example, that the customer is low on rack space or cooling capacity in the data center, and the physical data center is clearly not in your scope, you cannot simply assume there is adequate cooling capacity in the data center. You KNOW it’s going to be a problem. Sure, as an (hired) architect you may be long gone before the <…> hits the fan, but the customer has to clean up the mess. The proper way to tackle something that’s not in your scope is to simply scope it out of the design, identify the risk properly, and document it with a clear and actionable mitigating measure to be picked up by the customer or whoever else is responsible. This way your customer is informed, you have done your due diligence and you can move forward on your design. In this case, the constraint you have to work with is a resource limitation beyond your span of control (such as the cooling capacity).
4. In an ideal world, the customer delivers a well-defined set of crystal clear requirements to work with. In the real world however, requirements gathering is hard work. Architects often need to reverse engineer requirements out of a discussed solution, directly or indirectly feed common requirements into the discussion and generally come up with some decent set of requirements to work with. There is always a risk of the architect introducing specific requirements him/herself based on previous experiences. It is absolutely critical the customer validates these requirements. If the customer does not, cannot or will not validate a requirement you introduced yourself, you move it to your assumptions list and accompany it with a proper risk. In this case, the constraint you have to work with, is the fact the customer doesn’t validate the requirement.

This is how I personally see the relationship between constraints, assumptions and risks:

My personal experience

In one of my more recent projects, we were heavily constrained on time. We had to deliver a full SDDC design in just a few weeks. During the requirements and design workshops we quickly discovered the IT department, being as helpful as possible, would be unable to provide all the necessary details on network capacity sizing, business validated availability and recoverability requirements, throughput figures for L2 bridges and so on. Obviously, this isn’t an ideal situation and the customer’s architects and engineers would have loved to engage in several additional workshops and deepdive sessions but, there simply wasn’t any time. The project was given a strict delivery date by the project sponsor.So, when life hands you lemons, you just have to make lemonade. In this case, the lemonade turned out to be a set of assumptions :-).

We carefully identified every uncertainty in the design, documented them as assumptions and sized the resulting risks of these assumptions together with a number of mitigating measures. We were able to build our SDDC design and the customer knew exactly which risks the project was exposed to as a result of the assumptions that were made.

Conclusion

In an ideal world, each assumption gets validated and every design gets delivered with a clear and validated list of requirements. In the real world however, we often have to deal with uncertainty in our designs for several reasons. When used properly, assumptions are a perfect tool to address these uncertainties in your design.

I would love to hear how fellow architects deal with uncertainty and constraints in their designs. Leave a comment or find me on Twitter!