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 is a primary component of an organisation's release and provisioning framework and service continuity plan.
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).
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.
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:
(see "definitive media library and configuration management database in the context of the release management process" diagram above)
The media release lifecycle steps are:
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.
The DML supports;