The value of standardisation and documentation


Having differentiating factors from your competitors holds a certain amount of value. One way to achieve this is by providing customised solutions to your clients. When it comes to IT, the case for customisation becomes harder to make. The history of large ERP rollouts has shown that an organisation can gain more benefits by adopting the solution’s standard processes than trying to make the software fit the existing (sub-optimal) processes.

While it is a good thing trying to avoid “vendor lock-in”, an organisation should limit the extent to which they do this. Hardware (especially server hardware) has become very much alike, so what benefit is there in having different servers from different vendors for different projects? In most cases, the hardware will (hopefully!) run a small set of the same operating systems on top of this mix of hardware. In addition, every vendor will have differences in setup, support and management of the equipment to make life just that little bit more difficult for the Operations team.

Moving on from hardware – the same applies for the number of operating systems in use, their configuration, the installed tools, the way they are protected, and so on. Every additional item will add complexity and this is likely to increase the risk of something going wrong. Your Operations & System Management team should be able to manage the environment, so how and why would you want them to be experts in e.g. five different monitoring tools and four backup solutions?

Standardisation across an organisation has proven very beneficial (the metric system just being one example); equally, it should apply within a company’s IT environment. A good start is the definition and documentation of a technical service catalogue, which provides information to all groups and teams on the services, components and equipment which are available. The definition of a service item allows us to document at a minimum the following items:

  • Time to deliver
  • Effort to build
  • Technical specifications
  • Costs

To expand on this an organisation can include documenting how to deliver the item(s). Done well, this approach does not reduce the flexibility in building the right solutions, as it provides a choice to either:

  • Select existing building blocks (with defined costs and effort), or
  • Develop a new service item, or
  • Develop a custom solution (for a rare one-off use case)

A next step can be the documentation of how to run the newly built (standard) environments through the use of runbooks, Wiki pages or as a precursor to automation.

Diaxion has been involved with a number of clients in all phases – from the initial assessment of what should constitute the service catalogue to the creation of runbooks.