Facing the contradiction

A path towards sane policy for change around enterprise systems.

Introduction

Every large organisation has IT policies. They vary from place to place in terms of the number, length, and degree of adherence they command, but they all influence the way in which enterprise software functions. This article focuses on one particular topic - change control.

Analysis

There is a fundamental conflict between flexibility and reliability within IT in the enterprise. Systems which are set in stone and not touched, but merely expected to continue to do tomorrow what they did yesterday, rarely go wrong, even if they were poorly written and badly implemented.

Conversely even the best designed and implemented systems will behave unexpectedly sometimes when changes are made, and furthermore, the changes which cause the biggest problems are often not the ones you might expect. We all have war stories of the time when a major upgrade to a complex global system went off without a hitch, only for the whole edifice to come tumbling down a month later when someone made a minor change to the firmware of a router.

This conflict typically leads to two separate patterns of behaviour within the firm.

In order to preserve the reliability of core systems, complex processes are introduced around change. These can involve for example:

• Requiring multiple sign-offs before any changes are made to production systems.
• Limiting such changes to certain times of day or week.

In addition, you can easily find that for every one system in productive use, there is a requirement for many others in order to provide:

• Separate systems for development and engineering
• Isolated test setups
• User Acceptance environments
• Warm standby to protect against local failure
• Disaster recovery equipment to protect against major incidents

Quite aside from the cost implications, it can be almost impossible to ensure that changes to the 'real' system are properly reflected in these others, and as a result, they can often render more likely some of the very issues they exist to prevent.

Meanwhile, in order to preserve flexibility, individuals develop personal tactics and working patterns to allow them to deliver despite what they perceive as an annoying bureacracy. These working parterns can include:

• Being 'economical with the truth' in describing the intended impact of a system, so as to get it out as a pilot or proof of concept.
• Finding ways to give the business long-term access to a test or development setup and letting them do real work on those systems.
• Making spurious promises about the temporary nature of some undesirable short-term implementation.
• 'Our own team will look after this - we know what we're doing, so don't worry about it'
• Just not bothering to tell anyone what's going on till it's too late.

And senior management, who almost certainly know full well that such things are going on, have limited scope to prevent them because:

• Ultimately, you'd need to sack someone to prove you meant it.
• The people you'd have to sack are typically those who are perceived as effective by their business sponsors, precisely because they 'get the job done'
• And if people did start towing the line in strict accordance with the rules, you'd be in REAL trouble!

Answers?

Policy matters, and there is no substitute for coming up with a policy which translates into the actions and decisions you want to see in practice. A boilerplate policy is unlikely to capture the nuances of your organisation, which are important in ensuring its credibility and fitness for purpose. But a custom policy produced from scratch by a committee of well-meaning middle managers is also likely to degenerate into a large and unwieldy document whose main function is blame avoidance rather than, as it should be, risk management.

A better approach is to identify a single author to produce something concise and enforceable which can then form the basis for detailed procedures and processes. Of course, the author must work closely with appropriate representatives of all the groups affected - if these policies could be defined in a vacuum, you could just pick up a boilerplate for free. An external perspective can be valuable in offering ideas and in facilitating the discussion.