I used to think that the most difficult part of creating a complex infrastructure design was fretting over the important technical choices that would affect the configuration of deliverables. Once those were sorted then I could get on with listing the order in which elements needed to be implemented, and producing a list of all the technological resources needed to implement them.
Over time I’ve come to realise that this is actually the wrong way round. Often design choices are the easiest stage, partly because many infrastructure components work best when following vendors’ best-practice configuration guidelines (or even just set up as they come out of the box). Also, because most configuration is soft, its easy to make such choices at the last minute and still deliver it right and on time. The more important elements to get right up front, however, are those that require the time and the money, also known as dependencies and resources.
Dependencies, or prerequisites, are important to get right in infrastructure deployment, because the solution is often distributed over many components. This is especially the case when there are separate work packages that inter-depend. In order to make progress a design has to assume that someone else will deliver certain necessary items. If different people are involved in designing each package, then it is especially important to drill down to a granular level of detail of who depends on what and whom for when.
However resources are the most critical thing to tease out of the design first. The reason for this is simple – someone has to first pay for everything and then make sure it gets delivered. Don’t underestimate the delays that either of these can cause. Chances are that the project will have been costed and have an agreed budget. Any nasty surprises that come out of the woodwork during detailed design will need more money from somewhere, and the battle to get someone to agree to stump up that cash can often be protracted. And what’s worse, is that delivery lead times only start from when someone finally agrees to pay. Both of these are reasons for you to make sure that no assumptions are left on any resources, and especially not until you turn up on site ready to configure them.
- Resources my design consumes
Get the complete list of ALL resources your services will consume. Start with hardware and software (and people), but don’t forget the small but ESSENTIAL items like power and cables, ALL connectivity ports, addresses, consoles, rack space, and so on. Present each class of resource in a uniform output from all the designs so its easy to add up the full shopping list for each resource class. You might find it easier to assign (host-)names up front to each new component, as a handy way to relate the resources back to where they are needed.
- My interdependencies with other designs
Not everything you need comes from suppliers – you will also need services providing by other designs across the solution, or even from the host environment you are deploying into. It is important to draw attention to these early on – partly to set the expectation of what you need, but more critically to be clear about when you will need it. Likewise other designs might have dependencies that they place on you, which you must effectively treat as requirements to satisfy in your solution. Again the timing is important, because someone may depend on a component of your solution before your complete solution is really due. Often the sequence of these dependencies flowing in an out of each design can be the biggest driving force in scheduling complex implementations.
- Design choices that affect configuration
Once you’ve gotten those other two out of the way then you can get on with exercising your specialist subject, and truly delivering a solution that meets the requirements placed upon you. However, bear in mind that as you drill down into your own detail you may unearth new interdependencies, so periodically check that your inbound and outbound dependencies have not changed. Also, because certain choices you make might end up affecting the list of resources your services will consume, its worth revisiting that list at least once before you finalise your design.
Never forget how long it can take to go through the bureaucracy of project change controls and procurement. The last thing you want is to find yourself standing in the datacentre on a deadline – and all that’s standing between you and successful delivery is one more stupid socket to plug your simple little power cable into…