Definitive Media Library


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 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 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, 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.

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. 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 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.

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 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 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 or actively. All finished products, however, in their authorised deployable form should be stored within the central DML.
Typical CIs that a DML will store include:
The media release lifecycle steps are:
  1. Demand for new service or product arises.
  2. Decision is made to make or buy the product 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. 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.
  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.
  10. Completed media package 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.
  12. DML entities are archived as soon as:
  13. #CMS or CMDB indicates that packaged release is no longer in use at any location and
  14. #The DML entity has been removed from the technical or user catalogue as a selectable item

    Distribution

Even though the DML as an authorised store for media implies a degree of centralisation, Local Media Libraries 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, 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 software, as packaging allows software to be configured to run efficiently on a particular platform or environment. Even a slight change in this platform can prevent a package from successfully deploying so retention of the raw media version of software is critical as this will be needed should the packaged version no longer deploy e.g. following the upgrade or replacement of the operating platform.

Benefits

The DML supports;