Issues Faced

Delivery of these services involves the deployment of a sophisticated and complex Technical Infrastructure comprising, inter alia, computer systems, road-side telemetry equipment and interfaces to third-party systems.  This technical infrastructure is subjected to continuous change for a number of reasons:

1.  Continuous improvement
2.  Fault correction
3.  Change in business requirements
4.  Substitution of obsolete (or unsupported) technology

Additionally, the approach to managing changes to the Technical Infrastructure is also affected by the characteristics of this infrastructure, which are:

• Complex
• Distributed (thousands of units of road-side telemetry equipment)
• Highly coupled (significant system interdependencies)
• Required to be available 24x7x365 with high costs associated with system outage
• Developed by third parties
• Supported by third parties
• Pre-existing

NTCC Objectives for a Configuration Management System

The primary business objectives for a Configuration Management system were to minimise the risks associated with change (by promoting visibility) and to mitigate the risks associated with change (by establishing traceability).  Traceability was seen as crucial as this would provide the means by which detrimental change could be isolated and regressed, and such regression could only be achieved if previous versions of Configuration Items were retained.  Therefore, the key objectives were identified as:

• The establishment and maintenance of a Configuration Management Database (CMDB) comprising technical elements and their configuration.
  
  
• The tracking of changes to the Configuration Items and baselines over time.
  
  
• The establishment of top-level Configuration Item relationships.

The above key objectives were to be met by the introduction of Configuration, Change and Release Management processes managed by one system.  Additionally, longer-term goals were for the system to be able to manage Incident and Problem Reports, provide a Knowledge Base and provide Help/Service Desk functionality.

Problem Context

We carried out a study of how we dealt with change, which resulted in the identification of numerous home-grown spreadsheets, databases, documents and COTS applications which provided us with defect tracking and a high-level form of change control.

Although the processes in use met business needs, there was scope for improvement as they provided poor reporting mechanisms, were non-centralised, difficult to cross-reference and were poor at providing complex information.  As a result, a decision was taken to improve business processes and implement a unified configuration management system.

Configuration Management (CM) Tool Selection

Requirements

A CM System requirements matrix was set up and it was determined that the CM tool should have the following attributes:

• Be capable of managing the volume, nature, and variety of NTCC CIs.
  
  
• Provide workflow functionality to assist the implemented NTCC CM processes.
  
  
• Support tracking and traceability of CIs throughout the project life cycle.
  
  
• Possess the functionality to support access over a number of site locations.
  
  
• Contain administration features that allow routine and operational management to be carried out without recourse to specialist resources.
  
  
• Support NTCC CM activities by servicing the reporting needs of the project.
  
  
• System interfaces that allow data to be exchanged with other NTCC enabling systems.

Additionally, as the majority of CIs to be held in the system were to be pseudo CIs (in AllChange terms CIs/parts with no actual file associated with them) used to hold hardware configurations, most users of the system would not be carrying out traditional software development related tasks.  Therefore, a traditional software development tool, with its associated licensing and support costs would not be suitable.

Ultimately, the flexibility, configurability and cost of AllChange made it a clear winner in the ‘beauty’ contest.

Selection of AllChange
 
I had carried out an evaluation of AllChange on a previous project I had worked on and it had been chosen as the right solution for the project.  Unfortunately, the day I raised the PO was the day that the decision was made to cancel the project.  Therefore, when I had to carry out a tool evaluation again, against similar requirements, AllChange was the first tool I thought of.

AllChange was evaluated alongside a number of other similar products and of the ten products in the initial paper-based evaluation, three were chosen for a more in depth look, and evaluation copies were downloaded and installed.

A well defined, existing business process was chosen to test the ability of the tools to re-produce the process.  AllChange proved so useful that its use even helped to focus the mind on how to improve and further develop the existing process and aided the design of new processes.

My perceptions of AllChange, through a limited (although, extended by Intasoft) evaluation period were that it was the only product being evaluated that could provide the process unification that was required, at an affordable cost.

However, I still needed to satisfy myself that the product could do all I would ask of it and not rely on my beliefs arising out of the evaluation; consequently I invited Intasoft to attend a meeting at which I would delve deeper.

I was immensely impressed with the configurability of AllChange, particularly as I didn’t intend to use it primarily for software development.  At the first meeting I could see that AllChange had moved a long way from the version I had first seen and all of the change was positive.  Intasoft’s representative, Tony, was obviously enthusiastic and knowledgeable about the product and was able to demonstrate, using an out-of-the-box installation, functionality that I had been unaware of.

Following the decision to purchase AllChange, Intasoft could not have been more helpful - arranging activation prior to payment and arranging attendance on user and Admin courses at short notice.

AllChange in NTCC

Implementation

The challenge was to introduce, incrementally, the various aspects of AllChange whilst continuing to provide the many outputs that the current, fragmented system provided.

A strategy was devised that would result in the provision of Incident, Problem, Configuration, Change and Release Management (and, longer term, Asset Management and a Knowledge base), with AllChange at the heart of the system as the definitive source of data and providing the workflow mechanism to manage the processes.

This strategy took a phased approach with the introduction of AllChange during October 2005 to a small number of software developers and using a simplified RFC process.

Following this there was a gap of several months while detailed configuration and coding of the AllChange out-of-the-box ITIL solution took place, to enable the further rollout to be NTCC specific.

Once the bulk of the process design and implementation was completed, a go-live date was selected and a training and education programme initiated (not only on the use of AllChange but also on the concepts of ITIL and the five Service Support processes).  This ensured that all users would be able to carry out their business area specific tasks within AllChange immediately following their training and would be able to familiarise themselves with AllChange using a training database.

On the go-live date AllChange was rolled out to the remainder of the business and hit the ground running, providing Incident, Problem, Change and Release Management, and an element of Configuration Management, from day one.

AllChange Use

AllChange is now used throughout the business and one of the key benefits that users have commented upon has been the visibility and communication of forthcoming changes.  In terms of reporting, it is now much easier to identify failed changes in a release and compile trends showing number of releases per reporting period, percentage of a release that succeeded, etc.

As any member of the NTCC can access AllChange, we have a variety of types of users, the majority of which are what AllChange terms as cr only.  In essence, this gives a user the rights to raise Incident Reports, Problem Reports and RFCs and view and track their progress.  Configuration Items are hidden from most users but even if they are available, sensitive information can be hidden on a per user basis.  The use of AllChange Roles and User Groups provides tremendous flexibility in determining who can do/see what.

So, primarily we use AllChange to manage Incident Reports, Problem Reports and RFCs, all of which are linked to underlying Configuration Items, from which we can determine the current configuration of our Technical Infrastructure for contractual and business reasons.

One of the main areas of concern was that software being delivered to us by a third-party would fail on a regular basis and we had no real visibility of the changes being delivered in each release.  AllChange was utilised to provide standard Change and Release Management procedures with the exception that the source code was not held within AllChange but was controlled by the third-party supplier using their own version control system.  By creating pseudo CIs, which equated to the software subsystems that would be delivered, we could link IRs, PRs and RFCs to the CIs and put them through a release cycle (bypassing the build stage), culminating in a Release Note providing details of what changes would be in a release and what CIs were affected by it.

Additionally we have a group of users carrying out software development in the more traditional sense and checking source files in and out of AllChange.

Until now, the focus has been on control of our Technical Infrastructure - our live, operational system, used to provide our contractual services.  Further uses of AllChange are planned, including the Configuration and Change Management of our business systems (people/infrastructure/processes used to support the Technical Infrastructure) and the further development of Asset Management data and processes.

AllChange Customisation

Having a development as well as process management background the implementation and use of AllChange has suited me well, and I make great use of the ability to write my own code to influence how AllChange behaves.  To be honest, this was the biggest selling point for our business.  The flexibility provided means that complex business processes can be mapped into AllChange and all the necessary controls implemented using either the out-of-the-box solution or by specific coding.

As previously mentioned a lot of customisation of AllChange has been carried out; details of some of the customisations are:

• The creation of business specific workflows, mapped to business specific processes - I would imagine that most businesses would do the same.  The out-of-the-box workflows provide a very useful starting point but most would need some alteration to fit business needs.
  
  
• From past experience of having database records changed with no auditing of who has done what or when, it was important that very tight control was placed on a user’s ability to change data and that any changes were recorded.  By careful use of roles and groups, customisation of various entry and exit conditions and command condition and actions it has been possible to deal with a wide variety of circumstances and allow or disallow user actions.  Additionally a specifically written function records all changes either to (depending on the nature of the change) an Audit Trail text section or to AllChange’s Status Log.
  
  
• Normally, copying a part, cr or baseline would do just that - create an exact copy of the item.  However, our business needs dictated that any item copied should just be a ‘shell’ and that fields and text sections should be cleared out.  Therefore, various functions were written to cater for this.
  
  
• The attachment functionality was customised to prevent a user adding an attachment that was already attached, as what this did was overwrite the original attachment with the new one.  The customisation enforced unique attachment names.

Currently AllChange is not integrated with any other products (with the exception of MS Outlook) but the integration possibilities were one of the reasons it was chosen.

I have dealt with many software houses in the past and I have never been more impressed with the support on offer than I am with Intasoft.  Even before purchase the support of the evaluation product was excellent.  Support is carried out by developers and in my experience they are able to solve 90% of my queries within the day.  What is also unique about the support is that, because administrators can write their own functions to provide specific functionality, a lot of what is being asked for is business specific and the support team seem to relish tackling new problems.

As part of the licence option chosen by NTCC three days consultancy was included.  Although this was intended to be used during the initial setup period I found that it wasn’t needed until much later and was able to use my last day almost 18 months after first purchasing AllChange.  Intasoft personnel that provided the consultancy were highly motivated to solve any problems encountered and let me, the customer, dictate the content of each of the days.

We have used Intasoft’s training services, both on-site and Public training courses at Exeter.  I found them very useful and, given the small number of delegates, the tutors were able to adapt their planned training to meet the needs of the delegates attending.

AllChange will certainly continue to be used for the IT Service Support processes it currently supports.  Because, as I tell my colleagues, AllChange can be made to do almost anything (I’m still working on it producing a bacon sandwich for me on a Friday!) several people have been thinking of other processes they would like to put into AllChange and it will more than likely be put to use in other areas of the business.

Back to top