Definitive Media Library (DML) - Revision history

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T15:17:24Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

User at 16:22, 14 January 2021

2021-01-14T16:22:18Z

User at 16:21, 14 January 2021

2021-01-14T16:21:58Z

User at 16:19, 14 January 2021

2021-01-14T16:19:09Z

User at 16:15, 14 January 2021

2021-01-14T16:15:14Z

User at 16:11, 14 January 2021

2021-01-14T16:11:24Z

User at 16:08, 14 January 2021

2021-01-14T16:08:39Z

User: Created page with "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..."

2021-01-14T16:07:38Z

Created page with "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..."

New page

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|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.<ref>Definition - What is Definitive Media Library (DML)? [https://wiki.easyvista.com/xwiki/bin/view/Documentation/CMDB+-+Definitive+Media+Library EasyVista]</ref>

[[ITIL (Information Technology Infrastructure Library)|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.

@@ Line 1: / Line 1: @@
-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|software]] and software packages) are stored and protected, together with their path. The aims are as follows:
+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|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 monitor and [[control]] software installed in the organization.
 *To ensure that the same version of software will be installed on every workstation.<ref>Definition - What is Definitive Media Library (DML)? [https://wiki.easyvista.com/xwiki/bin/view/Documentation/CMDB+-+Definitive+Media+Library EasyVista]</ref>
@@ Line 6: / Line 6: @@
-'''The Definitive Media Library & CMDB in the context of the Release Management Process'''<br />
+'''The Definitive Media Library & CMDB in the context of the Release [[Management]] [[Process]]'''<br />
 [[File:DML.jpg|500px|The Definitive Media Library & CMDB in the context of the Release Management Process]]<br />
 source: Wikipedia
@@ Line 12: / Line 12: @@
 == Scope of Definitive Media Library (DML)<ref>Scope of Definitive Media Library (DML) [https://en.wikipedia.org/wiki/Definitive_Media_Library Wikipedia]</ref> ==
-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.
+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 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:
+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
+*[[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)
+*Gold builds (clients, servers, [[network]] and storage devices etc)
-*System images
+*[[System]] images
-*Across multiple technology stacks and distribution technologies (e.g. Wintel, UNIX, ORACLE, mainframe, network, storage etc)
+*Across multiple technology stacks and [[distribution]] technologies (e.g. Wintel, UNIX, ORACLE, [[mainframe]], network, storage etc)
@@ Line 29: / Line 29: @@
 There are several benefits to having a DML. A well-designed DML supports:
 *Release & Deployment Management from a centralized storage area
-*Availability and Service Continuity by providing the source of all packaged applications and raw media for use in service restoration and disaster recovery procedures
+*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 rationalization
+*Automated [[server]] provisioning and rationalization
-*Asset Management by providing metadata records and license keys relating to software license provision.
+*[[Asset]] Management by providing metadata records and license keys relating to software license provision.
 *Cataloged request fulfillment, whether it’s a one-off request or a repeated request for updates to the same service.
-Having a DML in place may at first seem like a lot of work for little reward, but it really streamlines processes in the Service Transition stage and acts like a security blanket during change management, configuration management, and release management. A DML is a useful ITIL tool that will help an IT service provider to keep records of all their definitive media items in one centralized place where there is complete control over the items in the library. When checking the items into the library, they can be checked for compliance with the company standards. This adds a security checkpoint which ensures that only tried and tested configuration items are used to act on change requests. This helps avoid situations where releases go into the DML and subsequently implementation that are insecure, unlicensed, not supportable by the operations team.
+Having a DML in place may at first seem like a lot of work for little reward, but it really streamlines processes in the Service Transition stage and acts like a security blanket during change management, configuration management, and release management. A DML is a useful ITIL tool that will help an IT service provider to keep records of all their definitive media items in one centralized place where there is complete control over the items in the library. When checking the items into the library, they can be checked for [[compliance]] with the company standards. This adds a security checkpoint which ensures that only tried and tested configuration items are used to act on change requests. This helps avoid situations where releases go into the DML and subsequently implementation that are insecure, unlicensed, not supportable by the operations team.
 == References ==
 <references/>

@@ Line 7: / Line 7: @@
 '''The Definitive Media Library & CMDB in the context of the Release Management Process'''<br />
-[[File:DML.jpg|400px|The Definitive Media Library & CMDB in the context of the Release Management Process]]<br />
+[[File:DML.jpg|500px|The Definitive Media Library & CMDB in the context of the Release Management Process]]<br />
 source: Wikipedia

@@ Line 6: / Line 6: @@
 [[File:DML.jpg|400px|The Definitive Media Library & CMDB in the context of the Release Management Process]]<br />
 source: Wikipedia
@@ Line 34: / Line 34: @@
 *Cataloged request fulfillment, whether it’s a one-off request or a repeated request for updates to the same service.
 Having a DML in place may at first seem like a lot of work for little reward, but it really streamlines processes in the Service Transition stage and acts like a security blanket during change management, configuration management, and release management. A DML is a useful ITIL tool that will help an IT service provider to keep records of all their definitive media items in one centralized place where there is complete control over the items in the library. When checking the items into the library, they can be checked for compliance with the company standards. This adds a security checkpoint which ensures that only tried and tested configuration items are used to act on change requests. This helps avoid situations where releases go into the DML and subsequently implementation that are insecure, unlicensed, not supportable by the operations team.

← Older revision		Revision as of 16:19, 14 January 2021
Line 4:		Line 4:

	[[ITIL (Information Technology Infrastructure Library)\|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.		[[ITIL (Information Technology Infrastructure Library)\|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.
		+
		+
		+	[[File:DML.jpg\|400px\|The Definitive Media Library & CMDB in the context of the Release Management Process]]<br />
		+	The Definitive Media Library & CMDB in the context of the Release Management Process<br />
		+	source: Wikipedia

← Older revision		Revision as of 16:15, 14 January 2021
Line 19:		Line 19:
	*System images		*System images
	*Across multiple technology stacks and distribution technologies (e.g. Wintel, UNIX, ORACLE, mainframe, network, storage etc)		*Across multiple technology stacks and distribution technologies (e.g. Wintel, UNIX, ORACLE, mainframe, network, storage etc)
		+
		+
		+	== Benefits of a Definitive Media Library<ref>Benefits of a Definitive Media Library [https://blog.masterofproject.com/definitive-media-library/ Master of Project]</ref> ==
		+	There are several benefits to having a DML. A well-designed DML supports:
		+	*Release & Deployment Management from a centralized storage area
		+	*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 rationalization
		+	*Asset Management by providing metadata records and license keys relating to software license provision.
		+	*Cataloged request fulfillment, whether it’s a one-off request or a repeated request for updates to the same service.
		+	Having a DML in place may at first seem like a lot of work for little reward, but it really streamlines processes in the Service Transition stage and acts like a security blanket during change management, configuration management, and release management. A DML is a useful ITIL tool that will help an IT service provider to keep records of all their definitive media items in one centralized place where there is complete control over the items in the library. When checking the items into the library, they can be checked for compliance with the company standards. This adds a security checkpoint which ensures that only tried and tested configuration items are used to act on change requests. This helps avoid situations where releases go into the DML and subsequently implementation that are insecure, unlicensed, not supportable by the operations team.

← Older revision		Revision as of 16:11, 14 January 2021
Line 4:		Line 4:

	[[ITIL (Information Technology Infrastructure Library)\|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.		[[ITIL (Information Technology Infrastructure Library)\|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)<ref>Scope of Definitive Media Library (DML) [https://en.wikipedia.org/wiki/Definitive_Media_Library Wikipedia]</ref> ==
		+	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)

← Older revision		Revision as of 16:08, 14 January 2021
Line 3:		Line 3:
	*To ensure that the same version of software will be installed on every workstation.<ref>Definition - What is Definitive Media Library (DML)? [https://wiki.easyvista.com/xwiki/bin/view/Documentation/CMDB+-+Definitive+Media+Library EasyVista]</ref>		*To ensure that the same version of software will be installed on every workstation.<ref>Definition - What is Definitive Media Library (DML)? [https://wiki.easyvista.com/xwiki/bin/view/Documentation/CMDB+-+Definitive+Media+Library EasyVista]</ref>

−	[[ITIL (Information Technology Infrastructure Library)\|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.	+	[[ITIL (Information Technology Infrastructure Library)\|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.