Definitive Media Library

The Definitive Media Library & CMDB in the context of the Release Management Process

A Definitive Media Library is a secure Information Technology repository in which an organisation's definitive, authorised versions of software media are stored and protected. Before an organisation releases any new or changed application software into its operational environment, any such software should be fully tested and quality assured. The Definitive Media Library provides the storage area for software objects ready for deployment and should only contain master copies of controlled software media Configuration Items (CIs) that have passed appropriate quality assurance checks, typically including both procured and bespoke application and gold build source code and executables. In the context of the ITIL ^[1] best practice framework, the term Definitive Media Library supersedes the term Definitive Software Library referred to prior to version ITIL v3.

In conjunction with the Configuration Management Database (CMDB), it effectively provides the DNA of the data center i.e. all application and build software media connected to the CMDB record of installation and configuration.

The Definitive Media Library (DML) is a primary component of an organisation's release and provisioning framework and service continuity plan.

Background

In a controlled IT environment it is crucial that only authorised versions of software are allowed into production. The consequences of unauthorised software versions finding their way into the live environment can be serious. Typically, in a mature organisation, stringent Change and Release Management processes will exist to prevent this occurring, but such processes require a place where the authorised software versions can be safely stored and accessed. The solution put forward by ITIL in its third version is called the Definitive Media Library or DML (replacing the previously named Definitive Software Library or DSL in version two). ITIL proposes that the DML can be either a physical or virtual store and there are benefits and drawbacks with either method. Clearly, however, there are key factors in the success of any DML solution i.e. software required to be deployed into production should be rigorously tested, assured and licensed to perform and also packaged in such a way that it will safely and consistently deploy. Also, the DML should be easily accessed by those, and only those, authorised to do so. In this way, a virtual (electronic) storage area will almost always provide a superior solution, meaning the DML can be centralised and accessed remotely or outside normal business hours if the need arises (see distribution).

Scope

The DML plays a critical role in supporting the transition from development to production phases and DML solutions should be distinguished from other software and source code repositories e.g. Software Configuration Management or SCM (sometimes referred to as Software Change and Configuration Management) that supports the development or software evolution phase. This is an important distinction and often causes some confusion. In essence, whereas SCM tools or repositories store and manage all development versions and revisions of code (or work products) up to but not including the final authorised product, the DML stores only the final authorised versions of the code or product. This is analogous to a high-street product lifecycle where the product moves from design house to factory, through to warehouse and then shop, i.e.

records (metadata) are kept about how a product is designed developed and built. This enables the tracking down of which process is to blame where faulty products are discovered either during quality control or even in later service.
records (metadata) are kept in a CMDB about where the software is installed and deployed from the DML and into the production environment. Each installation or deployment should be authorised by a corresponding production change request and the resulting change recorded in the CMDB as a relationship between the DML artefact and the platform where it has been deployed.

In a more mature or evolved state there is no distinction drawn between the two forms of configuration management and the process is continuous supporting the whole service delivery and service operation lifecycle. This has been referred to as Enterprise Configuration Management. Even here though the development-based artefacts should still be distinguished from and kept separate from the management of quality assured, definitive master versions available for deployment. In an outsourced or multi-vendor arrangement the existence or otherwise of a consistent and secure form of supplier access will dictate whether or not the software configuration management is performed passively (externally by suppliers adopting their own SCM tools and then delivering the finished product) or actively (overseen internally with suppliers utilising the centrally hosted SCM tool). All finished products, however, (application software) in their authorised deployable form should be stored within the central DML.

Typical CIs that a DML will store include;

Packaged in-house application software
Commercial off-the-shelf (COTs) raw media
Customised COTs software (containing enhancements, tailored configuration etc)
Release packages
Patches (see patch (computing))
Gold builds (clients, servers, network and storage devices etc)
System images
Across multiple technology stacks and distribution technologies (e.g. Wintel, UNIX, ORACLE, mainframe, network, storage etc)

Media Release Lifecycle

(see "Definitive Media Library & CMDB in the context of the Release Management Process" diagram above)

The media release lifecycle steps are:

1. Demand for new service or product arises.
2. Decision is made to make or buy the product (service, build or application) based on functional requirements extracted from the requirements traceability tool. Product is created or selected from the service/ product catalogue in accordance with architectural design policies (Service Design). COTs product is procured and stored in the DML with asset status ‘procured’. If new, the product is added to the Approved Products Catalogue. In-house created application source code is managed directly in the software configuration management repository.
3. If COTs product or gold build is being packaged, media is extracted from the DML.
4. Product is packaged or developed and packaged (in which case add-on functionality is treated in the same way as in-house applications and builds).
5. Stub records or original baselines are created in the software configuration management tool.
6. Development code revisions and package revisions are recorded in the software configuration management tool throughout development.
7. Unit testing is carried out.
8. Packaging is completed to create the release package.
9. Product package is quality assured (inc testing, staging and any rework).
10. Completed media package (build, service or application) is lodged back in the DML as authorised media ready for deployment.
11. Following Change Management approval, product is released to the estate via the appropriate distribution system with logical installations being recorded via due process in the CMS (CMDB).
12. DML entities are archived as soon as;
a. CMS or CMDB indicates that packaged release is no longer in use at any location (a period of grace is required following the last decommission or upgrade to allow for any necessary regressions) and
b. The DML entity has been removed from the technical or user (service) catalogue as a selectable item

Distribution

Even though the DML as an authorised store for media implies a degree of centralisation, Local Media Libraries (LMLs) will be required in order to achieve a global model. In this way, release and deployment of physical instances of media can be achieved in country in a timely manner by avoiding constant downloads over the global network. Replication of authorised media in non-prime windows would make required packages available locally as required, but the DML would remain as ‘master’ for process control reasons. The DML/LML hierarchy is synonymous with the master/secondary distribution layers seen within many distribution technologies and package management systems. However, whereas distribution tools tend to be biased towards a particular technology stack (e.g. Wintel, Unix, Mainframe etc), one of the main benefits of a DML is its technology-agnostic nature and a true central store for all authorised software. In this way, the distribution tools would connect to the DML to obtain the software package. Application packaging involves the preparation of standard, structured software installations targeted for automated deployment. Packaging is also required for bought-in (COTs) software, as packaging allows software to be configured to run efficiently on a particular platform or environment. Even a slight change in this platform (such as the swapping-out of disk) can prevent a package from successfully deploying so retention of the raw media (ISO) version of software is critical as this will be needed (often in an emergency) should the packaged version no longer deploy e.g. following the upgrade or replacement of the operating platform.

Benefits

The DML supports;

Release & Deployment Management as a foundation and the central storage area for all releasable deployment packages
Availability and Service Continuity by providing the source of all packaged applications and raw media for use in service restoration and Disaster recovery procedures
Automated server provisioning and rationalisation through the storage of gold builds
Asset Management by providing metadata records and licence keys relating to COTs software licence provision. Instances of media and the authorised media set stored together with licences and licence conditions will allow optimised management of software allocations and external compliance in terms of Sarbane-Oxley and BSA recommendations.
Catalogued request fulfilment, either in terms of single-user client-end product requests or repeated requests for deployments of an existing multi-user service/application to other hosting locations.

References

↑ Shirley Lacy and Ivor Macfarlane (2007). ITIL Service Transition. The Stationery Office. ISBN 978-0-11-331048-7.