An Infrastructure Architecture system: Concept Overview

This article is the first in a series that discusses the design, implementation and use of a free Infrastructure Architecture system to monitor, improve and automate your infrastructure. It records my experiences of building such systems for various clients.

Mission

The aim of my Infrastructure Architecture system is to reduce cost and risk from IT organisations through risk identification and automation of repetitive tasks, and to improve service quality and availability through better informed management of existing resources.

The system is intended to be built from common commercial off the shelf products. Setup and use require capabilities that IT System Administrators already posses within timescales that will not impact upon daily duties.

Common Problems

Many organisations that I have worked with over the years have common IT problems, including:

• The desire to automate repetitive IT tasks to reduce costs, improve quality and free-up staff. However, due to constraints of time and skills, organisations often deliver piecemeal automation projects (if at all) that lack integration and limit reusability. Over time, this drives complexity and can actually increase overall support effort and technical risk.
• The desire (or requirement) to achieve and maintain a standard of quality. We all know that a consistently well configured environment will suffer less downtime, fewer support calls and have a better perception of service quality and availability amongst users. Furthermore, regulated sectors may be required to demonstrate a compliance against objectives concerning security and accountability.

Common (and often Poor) Solutions

Native Tools are not designed for the job

As IT Professionals, it often falls to us to find solutions to that automation and quality requirements described above, and typically we turn to the native administrative tools already at our disposal in the first instance.

However, this is rarely a good solution in practise; consider the practically of using AD Users and Computers to compare the configuration of 10,000 users, or explaining to a senior manager how to run a lengthy PowerShell command to generate an Infrastructure compliance report. This is not a fault of the tools; they are simply not designed to be used in such a way.

Third-Party Tools are only a partial fit

Next, IT Professionals typically seek third party administrative and reporting tools. Many exist, and some may well satisfy an extent of automation and reporting requirements. All require investment in skills, infrastructure and licensing. Further effort is needed to configure automations and reports.

Some organisations may find such tools a acceptable fit but in addition to their cost, they are typically limited in capability by their requirement to satisfy general and common requirements of their target marketplace. In practise, this means such tools suffer a capability gap, providing adequate solutions to easy requirements, but missing specific and often difficult needs.

Consequently, I believe a different approach is required, as set out by the concept below.

Concept Statement

The purpose of an Infrastructure Architecture System is to collect, store and relate information about your IT Infrastructure. By doing so, the user can detect and correct problems, build automations and demonstrate compliance.

Benefits

The Infrastructure Architecture System will:

• Use software and skills you mostly already posses
• Provide a single common repository for infrastructure configuration data.
• Relate previously unrelated data in diverse systems to create new insight into infrastructure.
• Capture business intelligence through the way the data is related and projected.
• Provide a common source of data upon which to develop automations.
• Provide a common source of data to report upon, to:
  • Identify and correct misconfiguration and other errors
  • Demonstrate compliance
  • Inform decision making
  • Identify and reduce risk

Disadvantages

Nevertheless, an Infrastructure Architecture System will not be without certain drawbacks:

• You will need the skills to build a system, or a willingness to acquire them.
• You will need to time and desire, build and operate the system
• Selling to value of a system to peers and managment may be challenge.