Whether you’re trying to rationalize your technology portfolio, properly manage your software vendor relationships, or address federal compliance or Information Security concerns, the accuracy of the data you maintain related to the software provisioned, deployed, maintained and used by your enterprise will be critical to your success. For this reason, more and more enterprises are ramping up their efforts to establish and maintain their Software Management Life Cycles (SMLCs) so that they can more efficiently and effectively collect, maintain, and publish Software related data to anyone in the enterprise who might require it for their own work (e.g. Developers, Procurement, Contract Management, Vendor Management, Support, etc.). This leads to the question of, “Where do you put all this data and how do you share it so others have access to it, when they need it?” The answer is a Software Library or a Definitive Software Library (a.k.a. “DSL”).
DISCLOSURE: Interactive examples of the DSL use our own product, NOUNZ, to demonstrate concepts within this post and are not intended to imply that our Library is the only tool that can be used to implement the contained concepts.
Definitive Software Library Definition
The Definitive Software Library, often referred to as the DSL, is a tool that facilitates and is used for the inventorying, cataloging, and indexing the software that an enterprise deals with. Data and Information about specific Software and Software Versions within the DSL are embedded in Software Data Records that act as entries within the library.
In very mature enterprises, entries in the DSL also point to physical copies of the Software they represent that exist in Software Repositories (SRs). (See a Definitive Software Library Example / DSL Example.)
NOTE: For reasons that will be discussed further on, please note that our own examples of a Definitive Software Library (DSL) are integrated into a broader Enterprise Digital Library (EDL).
Synonyms for DSL
The term Definitive Software Library (or DSL) is synonymous with the term Software Library (or SL) and, often, the two are used interchangeably.
Purposes and Benefits of the Definitive Software Library
The general purpose of the DSL is to house, manage and govern data about your Software, including all relevant inventories, supporting data and relationships between data.
Once in place, the DSL fits into the broader Software Management Life Cycle (SMLC) for an enterprise and can facilitate functions such as but not limited to:
- Software Inventory Management
- IT Asset Management
- IT Financial Management
- Software Scanning
- Software Development
- Software Deployment
- Software Administration
- Software Support
- Audit and Compliance Requirements (especially for Software Vendors)
- License Management and Lease Management
- Mergers & Acquisitions (M&As)
- Information Security
Ownership of the DSL should sit with your Information Technology (IT) organization, specifically with one or more resources that are held accountable for the collection, publishing, and maintenance of your enterprise’s Software-related inventories. Examples include but are not limited to your Technology Architecture Organization or your IT Operations and Infrastructure Organization.
The Definitive Software Library vs. The Definitive Software Repository
The Definitive Software Library is separate from and should not be confused with a Software Repository (SR) or a Definitive Software Repository (DSR). The DSL is where an enterprise stores, publishes, and finds or looks things up about Software, while the repository side of the equation is where an enterprise stores actual versioned physical copies of the software (e.g. Source Code, Binary Libraries, Binary Executables, Scripts and Electronic Documentation).
Also, the Software Repository is a structured storage location and is not to be confused with a Source Code Control System (SCCS), which is used for versioning of Source Code Files.
NOTE: The idea of one single “Definitive” Software Repository (and we stress the word “Definitive) is difficult to implement and possibly not worth implementing for larger enterprises that have many offices in different geographic regions. Instead, larger enterprises often should and do maintain Federated Software Repositories (FSRs) that are not considered “definitive” because each repository may and often does contain redundant copies of software, across them. For example, your business in the U.S. might use one set of Software while your business in Italy might use another set of Software. Each region’s repository often contains just what is important to that region. In such a geographically federated example, the DSL (which is a “Library”) acts as a wrapper that tells you what Software you own and important details about that Software, such as what Software Repositories hold which Software. Think of the Library as the gateway to the physical copies and to details about those physical copies.
Why have a separate Software Repository? Because people and tools will need to get to the Software to perform many operational tasks that require access to the physical software (e.g. Software Deployment Functions).
Definitive Software Library Contents Structure
At a minimum, the DSL should consist of:
- A catalog that leads to different Indexes of Software views (see Example of DSL Catalog)
- A default full view index of all records for all software that shows all data for all software records, which is accessible from the DSL Catalog (see Example of Default Full View)
As your DSL matures, it can also contain more advanced indexes such as:
- Alphabetic summary views (see Example of an Alphabetic Summary View)
- Indexes by data dimensions such as Type, Strategic Disposition, Owners, etc. (see Examples of textual indexes on DSL Catalog Page)
- Charts and dashboards that provide visual breakdowns of indexes such as Type, Strategic, Disposition, etc. (see Example of DSL Dashboard and Charts)
Best Practice: Make Your DSL a Part of Your Enterprise Digital Library (EDL)
Too many libraries implemented in different and separate tools will often confuse your enterprise stakeholders, make it difficult for them to work, raise data integration complexities, and raise costs. When you have and manage too many libraries, it becomes difficult to organize them, link them together, and coordinate their data records, their data elements, and any contained content across those libraries. Also, as the data in your DSL matures, you will have to link your software data to other data types (e.g. People, Organizations, Hardware, Cost Centers, Vendors, etc.).
It’s for the above reasons that it’s considered a best practice to consolidate all your Libraries, together in one fully integrated solution, and implement your Software Library as part of your broader Enterprise Digital Library (EDL) or Digital Library (DL). Having everything in one place will, ultimately, help drive down complexities and costs while making it easier for people to get to what they need and explore relationships to and from other key data in other Library areas.
NOTE: If you properly follow the above advice, you’ll find that you also have the beginnings of an elaborate but cost effective Configuration Management Database (CMDB), which is intended to show relationships between important data. In other words, your DSL and your CMDB can be the same tool, if you implement your DSL correctly. This is because your DSL will hold all Configuration Items (CIs), and the Semantic Relationships between them (and other critical data). (See Example of Software Relationships in Tabular Form, Example of Software Relationships in Visual Node Cluster Form, and Example of Software Relationships in Visual Filterable Component Form).
At a minimum, your DSL should contain data records about Software. If the goal is to make it a Definitive Media Library (DML), it will also contain media (e.g. videos and images). The entry point Taxonomy for your DSL might look like:
/[ROOT_NAME]/Software/COTS (implying any software acquired through vendors)
/[ROOT_NAME]/Software/OpenSource (for any Open Source software)
/[ROOT_NAME]/Software/Custom (implying custom built and/or modified internal software development & Engineering products)
As the maturity of your enterprise evolves, your DSL will also contain data records about things (i.e. Data Types) like:
- Software Versions
- Software Instances
- Software Licenses/Leases
- Semantic Relationships between all of the above and other important data elements, such as but not limited to: Hardware, Environments, People, Organizations, Facilities, Cost Centers, Vendors/Suppliers, Documents, etc.
Clearly the more data types you put into your DSL, the more powerful it becomes.
The data records in your DSL should be broken into structured data attributes or data fields that help you capture and publish critical data and information about each records. For example, in the case of Software, you might want to capture things like:
- Long Name
- Short Name
- Abbreviation or Acronym
- Software Provider
- Build Classification (Purchases|Internally Constructed|Open Source|Other)
- Strategic Disposition
- Primary Purpose
- Primary Business Owner Resource
- Primary Business Owner Organization
- Primary IT Owner Resource
- Primary IT Owner Organization
Please note that the examples, above, are meant to be representative examples and not an exhaustive list of data attributes/fields.
DSL Governance Concerns
It’s important to govern the data within your DSL as well as the data it points to or integrates with. Anyone who has tried to inventory and track Software in very large enterprises knows just how difficult this can be. For this reason you should consider common Data Governance processes and procedures to collect, cleanse, and maintain your DSL’s Software data. And, since Software data changes often, your enterprise may want to consider the following tips:
- Set up enterprise policies that all data must be stored in the Software Repository and registered in the Definitive Software Library.
- Have a team like your Architecture Organization track and manage your Software and related data.
- Reconcile and update data about Software as it gets deployed to and used in each of your different Operating Environments.
- Reconcile your proactively collected Software data with your reactively collected Software Data (e.g. the data that comes from Auto-Discovery Tools and Monitoring Tools)
- Automate your Deployment Functions to tell you what Software they use and touch.
- Have your operational Development, Administration, Testing, and Support teams provide regular feedback and updates to your Software data.