Many people think that working in infrastructure is a very different field from working with applications. From the commercial perspective you are not a revenue generation tool, you are further from business because you merely support other applications, technologically you operate the lower level platform, and users only ever know about you when there is something wrong. Hmmm, that doesn’t sound as exciting as some web-based CRM tool that make financial executives’ eyes light up, especially when they see it on shiny hand-held devices.
However, if you are trying to approach infrastructure configuration in a vastly different way from how you would approach an application system development project, then you are almost certainly making a rod for your own back.
If you are doing it right, you will:
- have a separate set of sandpit systems for development
- keep configurations under version control
- not release anything until it has been properly tested
- consider using an established framework,
- be able to mirror your live back into test for diagnostics
- be closely involved with key business decision-makers,
- have a reason for every change you make
- inform people when you make changes that may affect them
Hmmm, tell me how that differs from applications. And when it comes to applications, you must make sure you get the requirements properly set out in the beginning. Equally so, with infrastructure, requirements must be the starting point for everything. And you should be able to trace back to your requirements so that you understand why things are as they are. If somebody changes one of those requirements you should be able to see how the effects of that change ripple through your systems design down to a final configuration change that you can validate in test.
This is why I propose a cause and effect chain to keep hold of your requirements, and to show what effect they have. This is a typical order for this cause and effect chain…
- business, functional and financial requirements
- defined standards (where relevant)
- environmental / non-functional requirements
- technical constraints
- assumptions (stated in lieu of other reasons)
- design choices
- implementation detail
This is not definitive nor prescriptive, you might find your ideal chain is defined slightly differently. But its not a bad starting point.
Some people think that system design is some kind of conjuring trick, where a 100 page document is needed to describe the fantastically complex solution that only a quantum physicist would be capable of deriving. Well, actually, complex solutions are more likely to be costly, risky and very difficult to manage going forward.
Don’t get me wrong, I personally love the design part of my work, but all it boils down to is the simple matter of following logical outcomes. If you follow down the cause and effect chain, the right result just pops out at the bottom. And that’s the magic – its simple, like the beautiful magic of nature – its not some black magic, hocus pocus, obscure set of incantations from someone trying to shroud themselves in mystery to occult the fact that they are not really sure how they are managing to make it work.
And the other great thing about the cause and effect chain that stems from requirements is that you can write it all down. State what the item (requirement, constraint, choice or outcome) is at each stage, and which preceding items it depends upon, and you allow any capable person at any time in the future to make any alterations that are relevant for the new circumstances. Structured, yet simple.
Just remember to use Plain English, not some arcane hieroglyphics, nor the latest technobabble.