Definitive Media Library (DML)

A Definitive Media Library, or DML, is a set of secure storage areas in which an organization's definitive, authorized versions of application configuration items (CIs) (software and software packages) are stored and protected, together with their path. The aims are as follows:

• To monitor and control software installed in the organization.
• To ensure that the same version of software will be installed on every workstation.

ITIL defines a Definitive Media Library (DML) as the place to store "official" versions of all media, including software, documentation and licenses. In order to begin a Definitive Media Library (DML) you will need to first set a definition for what you want in the DML. Once you have your definition, you need to identify all specific instances of “definitive media” that fits your organization’s definition. Once identified, place them under your control by adding information and attributes about the media into your DML tool. For physical copies of boxed or purchased software, gather those together for storage in a locked physical location (cabinet, etc.) Once you identify and control then apply your regular Change, Configuration and Release processes to the media. The DML was previously called the Definitive Software Library (DSL) in ITIL versions earlier than Version 3.

Scope of Definitive Media Library (DML)

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)