Benefits of a Definitive Media Library (DML)

It is critical to ensure that only authorized software is allowed into the production environment. To accomplish this, release and deployment leverages the DML that is managed by the service asset and configuration management (SACM) process.

The DML is a secure library where software that has been properly reviewed and authorized is stored. While ITIL makes a point of describing a physical repository, it could also be a carefully secured network storage system as well. Furthermore, depending on an organization's needs, there could be multiple physical and logical DMLs, but what is important is that there needs to be well defined procedures for managing the DML.

Technically, configuration items (CIs) are what is stored in the DML. In this case, “CI” refers to software, release packages, patches, system images, etc. The data record for each CI in the DML would identify the appropriate category as well as other data including vendor, license key, IT owner, date entered into the DML, approved usage, and so on.

Only CIs can be checked into the DML if they meet organizational standards, have been properly tested and are legally licensed. The review of new CIs to place in the DML is also an ideal control point to review what is needed and a way to reduce variation—reducing the number of database server builds to as few as possible, for example.

To enhance standards and overall control, an acceptance checklist should be followed. This list details what requirements must be met and requires authorization(s) from the necessary stakeholders such as the configuration librarian, security manager, development manager and the operations manager. Only after the acceptance form is completed and the necessary authorizations obtained can new CIs be added to the DML.

One objective of the acceptance procedure is to ensure the appropriate parties have a chance to review and either accept or reject a new entry into the DML. This helps avoid situations where releases go into the DML, and subsequently production, that are insecure, unlicensed, not supportable by the operations team and so on. This doesn’t negate the need for Change Management and Release and Deployment Management, but it does help by ensuring the base foundation of CIs used to build releases are valid.

Using DML Stored CIs

An important control is to give the operations staff strict instructions that releases into production are only to be built using CIs stored in the DML and they are to update the necessary data records in the configuration management system (CMS).

Some organizations take this to the extreme and only allow new systems to be built in a clean room. Engineers are not allowed to take any media into the clean room and all builds must be done from CIs stored in the relevant DML. This control virtually eliminates the chances of a release being created with unauthorized software.

Also, some organizations will only allow copies of the CIs to be checked out. The configuration librarian literally will make copies and only allow a person to check out a copy and set when the requestor must return the copy. This strict control reduces the chances of losing master copies of CIs and creates a check and balance to better make certain that the DML and CMDB records are accurate.

Overall, the change management process is responsible for making certain that the relevant records in the CMS are updated accordingly. By doing this we know what CIs were drawn from the DML to create what production systems and we understand the exact configuration of what is in production. This is very important information because it helps virtually all the other processes including Incident, Problem, and Asset because they must know exact what is in production at any given time.

A given DML will grow with time. In the same way that procedures are needed to add CIs, there also needs to be DML procedures for the review of contained CIs. In certain cases we will want to keep only the most current copy of a given CI and for others we may want to store all versions. At issue are the level of storage space required and also the need to reduce human error around using obsolete versions. There needs to be a checklist to decommission CIs from the DML and appropriate disposition including long-term archives, deletion, and so on.

In closing, the DML is a very useful ITIL concept. By defining proper procedures and controls, the risks associated with unauthorized software entering production can be greatly reduced. The implementation of one or more DMLs coupled with solid Change and Release and Deployment Management processes create a solid solution for groups looking to gain control of what is released into their production environment.

George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.