Given how hard it can be to show compliance across a portfolio of hundreds or thousands of software titles, each with their own fine print, some IT executives are lulled into a false sense of security that the challenge is so daunting, they couldn't possibly be liable for not being ready on a moment's notice to show compliance for any or all titles. Relative to all the hair-on-fire projects, they can't cost-justify proactive software asset management. And without executive support, a SAM project is almost doomed to fail.

The Good Faith Pirate's "failure of imagination" is enabled by some common myths:

Myth #1: There's low risk of us getting caught up in a software compliance event.

Gartner says the risk of an audit for any given company is 40% in a two year period, and getting more likely all the time. So if you follow the law of averages, within five years you're pretty much guaranteed to face an audit from a vendor or their agents: the BSA or SIIA in the US, FAST in the UK, or CAAST in Canada.

Myth #2: I can just uninstall the software if I get wind of an audit.

From the second you open an audit letter, you are legally obligated to cease and desist all changes to any software being questioned, lest you be guilty of tampering with evidence. An external audit that uncovers signs of removed software or a pattern of re-imaged systems can lead to greater fines or even criminal penalties for obstruction of justice. (Tip from IAITAM: prevent a fishing expedition into all your software by quickly asking the auditing entity to specify which software they feel you are out of compliance with. You are only obligated to provide them with data on software titles for which they have credible evidence you are in non-compliance.)

Myth #3: I just can true up if and when they catch me.

True-up costs are just the tip of an iceberg that can include:

• Fines and penalties. Fines and penalties can vary based on what law is being applied. For Title 17 of Federal Copyright Law (invoked by the BSA or SIIA) civil penalties can include up to four times the retail cost for all unlicensed software, plus up to $150K in punitive damages. This is for companies that cooperate. Those that don't may be presumed to be Bad Faith Pirates and hit with up to $250K in criminal penalties and up to five years in prison.
• Emergency self-audit costs. If you don't have automated systems in place, producing the right documentation with right level of reconciliation will be time-consuming. And given the time pressure (remember, you can't make any software changes from the time you receive the letter), you'll pay dearly for getting so much done so quickly. This alone can easily cost hundreds of thousands of dollars in internal and external labor.
• Business disruption. As mentioned, you are legally obligated to cease and desist all changes to any software once you get the letter. Think that might disrupt your business operations?
• Public reputation. Getting caught and fined could appear in a public financial report. SOX auditors can, and increasingly will, include software license compliance among the Section 404 controls they audit.

In addition, most companies underestimate true-up costs. First, you'll have to true up at a higher unit cost than your original agreement. Second, even if you really did purchase enough licenses, if you cannot produce documented proof of purchase reconciled with all that's discovered in your environment, you'll need to rebuy those licenses.

Myth #4: We're an $X billion company, these fines are small compared to our IT budget and are an acceptable risk and a cost of doing business.

Reading BSA and SIIA press releases, it would appear that only small companies get picked on, with fines of tens of thousands of dollars. Well, larger businesses do have an advantage: they have enough money to pay larger settlements to keep them out of the press. But they're paying, and they're paying big – fines and penalties scale up with the size and number of violations. And don't forget the emergency self-audit costs and disruption to business.

Myth #5: We have a large software budget and leverage with our software vendors. Their audit threat would be just a negotiating ploy (they'd audit me at their peril).

Software vendors created the BSA and their ilk as separate entities to chase after revenues that declined after Y2K. The thinking was that these independent auditing groups would insulate vendors from ill will among their customers. But they may have created a few monsters. Offering rewards of up to $200K for internal whistleblowers, they are getting a steady stream of tips on where to target their letters asking for proof of compliance. And they don't make it easy, or even clear, on what level of documentation will satisfy them. Their sole mission in life is to find and make examples out of companies, and those who lack software asset management programs are a soft target.

Myth #6: We negotiate enterprise agreements for all our major software, so we don't need to track compliance at a detailed level.

There are many restrictions on and cost implications for how your enterprise licensed software is actually deployed and used, and if you're not aware of these and tracking them, you're at risk. Also, not all the software you buy is licensed this way. And what about the software you don't know "you" bought, or that no one did? Think your employees aren't downloading and installing applications (or .mp3's) from the Internet? Think again. If you don't have a SAM program, how would you know?

Myth #7: Software audits are voluntary; I can just ignore the letter if I get one.

The BSA operates with the authority of their vendors' license agreements, which are protected by Title 17 of Federal Copyright Law, among other laws. If you decide not to cooperate, Federal Marshals can show up with an injunction and seize all your computers. Yes, this really happens!

Myth #8: We can beat it in court.

Almost no one goes to court over software license compliance. Even law firms who initially thought they'd fight a compliance audit decided to settle once they sized up their challenge. Why?

• The cost of winning is huge: trials can drag on for years, making legal costs far higher than just settling from the outset, not to mention the time commitment, disruption to business, credibility damage from the public exposure
• The chances of winning are slim because software license agreements put the burden of proof on the consumer, which makes proving compliance very difficult.
• The cost of losing is even worse: fines and penalties are more severe, and there is a risk of criminal jail time for officers of the company.

So, we're all guilty until proven innocent, with no affordable day in court to prove our innocence. Software asset management pays many dividends beyond compliance, but at a minimum it can make you a much harder target with continuous, cost-effective proof of innocence.

While it is possible to use the same discovery tools to populate separate repositories (an asset repository for ITAM, a CMDB for Configuration Management), this would not only create redundant efforts and opportunity for data conflicts, it would also deny a golden opportunity to connect ITAM to other ITIL processes. Because there is a significant overlap between what you will deem worth tracking as CIs and as assets, you can benefit from a unified approach to IT component tracking, whereby objects in the CMDB can be managed as both CIs and assets — without duplication of investments and messy integrations between separate repositories.

In this case, IT Asset Management – just like Change, Incident and Capacity Management – can be just another process consuming and contributing data to the CMDB, creating value by taking actions based in part on CMDB data.

But as we have already seen, there is not 100 percent overlap between assets and CIs. And more importantly, different kinds of data must be related to the IT components depending on how they are being managed (e.g. costs and contracts for ITAM, relationships and configuration detail for ITIL). So the question arises, what data belongs in the CMDB?

First, you may free yourself from the daunting task and paralyzing thought of starting a CMDB implementation where every discoverable attribute of every component and relationship in your enterprise must be catalogued in the CMDB. To do so you will need to intelligently apply the following principle: Populate the CMDB with the minimum amount of data needed for maximum value. This requires that you start with a clear understanding of your business objectives, followed by an analysis of what processes need to interact with which data to achieve those objectives. So long as your CMDB is architected for growth over time in both breadth (number of CIs and relationships) and depth (attributes of CIs and relationships), you can make decisions incrementally on what CIs and assets to manage and at what level of detail, gradually adding more as your processes mature and expand.

For example, you may decide to start CMDB population based on an IT Asset Management project with desktops and servers, or your change management effort with only servers, or your service impact initiative with CI relationships within a single critical business application. As you become comfortable, based on real-world experience, with the level of CI attribute and relationship detail needed in the CMDB to support your core asset, change or service impact requirements, you can expand to more manage more assets, CIs and relationships at the appropriate level of detail.

To maintain CMDB scalability and focus on the IT production environment, assets not in the production environment (e.g. a network switch on order from a vendor, or toner cartridges in a stock room) need not be entered into the core CMDB. Until they are received or scheduled for deployment, these asset records can be stored in a logically (if not physically) separate asset repository, which should ideally share the CMDB’s data model to facilitate easy migration of asset inventory records to the production CMDB.

Software license management may not spring to mind when we first think BSM, but it can similarly benefit from a cross-functional approach using a common business context. Here, the common business context is the ITIL Definitive Software Library (DSL) and the linked processes are change management, software configuration management and asset management.

Horses out of the barn

Think about how software license compliance has been done traditionally (note: when software guys like me say ‘traditionally,’ we don’t mean Victorian times, we usually mean just a few years ago).

Many companies start with a discovery-oriented approach that simply reports on deployed software. These snapshots can show how many deployments of software you have so you can determine if you are within contractual entitlements. If your contract with Adobe entitles your company to 100 installations of Adobe Acrobat Professional, you at least want to see whether or not you have 100 or fewer deployed instances. If you see significantly fewer than 100 and don’t see requests on the horizon for many more copies, you can sleep well that night. If you see much fewer (say, 20 deployments), you may curse the day someone bought too many licenses and wasted the budget, but at least you’ll be compliant.

But what if you have 105 deployed? Your discovery tool has notified you (after the fact) that you are non-compliant. Assuming you have only a discovery tool, you are faced with three courses of action:

Let’s call this phase of maturity, ‘Hey, the horses are out of barn!’ This is at least better than a lot of companies who have no compliance approach at all. They often find out their compliance profile the hard way, after they’re audited, penalized, fined, tarred and feathered.

But shouldn’t you automate some response to more optimally rectify out-of-compliance situations? A true asset management tool with an integrated procurement function could help you efficiently true up and buy more licenses. This is kind of like buying a new barn and putting it wherever the horses happen to be.

Maybe your end-user deployments were telling you that you really needed another barn. But this can become an expensive way to manage compliance. Let’s say there is no business desire or justification for more licenses. Then what?

Re-barning the horses

The next phase of maturity could be called, ‘Hey, get the horses back in the barn!’ Here, the idea is to automate reactive enforcement to a non-compliance situation. If you have a tool that can report on software usage, i.e. which desktop installations of Adobe Acrobat Professional haven’t been used in the last six months, you can automatically generate a list of candidates for deinstallations, also known as ‘license harvesting.’ This can be a fair gauge of business demand – those who aren’t using it have demonstrated a lack of demand for it – rather than an all-or-nothing approach where everyone in a certain group gets and keeps a software asset whether they use it or not because company policy says they are to get it.

If you have some integration with software deployment tools, you can go further and automate de-installations. This is more efficient than running around from machine to machine and doing uninstalls. And it’s certainly better than leaving it to the end user to take this action (in which case DLLs or other remnants could be left behind and counted as an installation during an audit). Just remember to consider and communicate a corporate policy of when and how software may be uninstalled, in case end-users are surprised at what they may perceive to be a heavy-handed Big Brother approach to compliance.

Taking action based on thresholds rather than waiting until you’re truly non-compliant is one way to make this reactive approach a bit more proactive. If I set a threshold of 90 percent deployment against contract as my ideal and regularly monitor the situation, I can set 90 percent or 95 percent as a trigger for evasive maneuvers such as true-ups or true-downs. The threshold gives you headroom for quick growth in demand and a margin for error in case growth came between reporting intervals. You are still reacting, but you have a better chance of doing so before you are non-compliant.

Keeping horses in the barn

Now we get to the BSM approach to software license management – more specifically in the case of desktop software, a Closed-Loop Client Management approach. Rather than making software license compliance a sporadic report-and-react activity, with BSM it becomes an integrated part of a continuous process for managing desktops, laptops and PDAs – clients. (Note: the benefits of closed-loop client management go far beyond software license management.) The key is weaving license management into the process of maintaining desktop software configurations. And as I hope to briefly explain, the keys to that are a DSL and CMDB.

The practice of closed-loop client management gets its name from closed-loop processes tying together planning, executing and verifying changes made to client devices. This is accomplished through integration across change management, software configuration management, asset management and discovery, and ultimately, identity management. The two lynchpins in this integration are

1. Workflow integration across the various tools that manage desktops (e.g. change, service desk, asset, software provisioning, discovery, identity)
2. A common business context; more precisely, data shared by these tools that agree on
3. • - Which desktops are deployed with which configurations today (CMDB)
   • - Which software is authorized for distribution (DSL)
   • - Who is using which desktops, and what are their roles in the organization (Identity Management)

The workflow, DSL and CMDB integrations work together to ensure that software configuration changes are executed only as authorized by the change management process. Change requests, for example, include targets (configuration items, or CIs) from the CMDB that are to be changed, and locations for software (from the DSL) that is to be deployed or changed. Once the change request is approved, the software configuration management tool can automatically execute the change because it understands – from the same CMDB and DSL used by change management – exactly what software changes to make to which desktops. When discovery and CMDB confirm that the actual state of the CIs in question matches the desired state as approved by the change management, the change request is closed and an audit trail of the entire process is recorded.

So what does this have to do with software license management? We’re almost there. The idea is to take software license usage into account when creating policies and approving distribution of software based on user roles. That requires change management, software configuration management and asset management to have a common view of software license information, which is the function of the DSL.

The DSL is a reference of all ‘golden master’ software authorized for distribution. ITIL isn’t descriptive on how a DSL should be automated, so for our purposes let’s consider that the DSL perform three key functions. First, the DSL should tell us where golden master software is located, whether on an auto-deployable package or CDs in a filing cabinet. Second, the DSL should include some mechanism for normalizing software title descriptions, so there is agreement among tools and decision-makers on which software we’re talking about at any point in the process. So rather than having four different records of the same deployed software recorded in the CMDB as Word.exe, MS Word, Microsoft Word XP, and Microsoft Office, we should see four instances of Microsoft Office XP.

Third, the DSL should indicate which software is licensed from third parties. This is the heart of software license compliance. Software deployments added to the production environment by change and software configuration management are discovered, their descriptions normalized by the DSL, recorded in the CMDB, and then recognized and counted against contractual entitlements in asset management. Because change, asset and software configuration management all share the same software information and deployment results, tracking is automated.

But we’re not proactive yet.

The shared DSL, CMDB and workflow integration allow change managers to easily see the software license status for a given title before they approve a change. If the proposed change would result in a non-compliance situation, a task could be created to purchase more licenses prior to approving the change. Or the change request could be denied and modified to a smaller list of targets that would maintain compliance. This is one aspect of proactive management of software licenses.

Another is the use of automated policies. If I have information on which user roles are entitled to which software (which the asset management should know), and know which users actually have what software deployed (which discovery and the CMDB can tell me), I can create automated policies in my software configuration management tool to continuously enforce this desired distribution. I can be notified of exceptions (especially where a user has software they are not authorized to have) and decide how to handle, or if I’ve clearly communicated a policy, I may automatically remove the software whenever the exception is found. Such policies can be submitted through change management for approval, to better coordinate and understand the ramifications of a proposed automated policy.

If I find myself with a software license count approaching or exceeding some threshold, I may propose the removal of that software from some specific set of targets. If this software is in the DSL and my software configuration management tool is familiar with its components, I can automatically remove all traces of the software, leaving behind no stray DLL or other content that could be counted against me in an audit.

These are just some of the ways that software license management can be conducted more efficiently, effectively, and proactively using a BSM approach: tying together disparate disciplines and tools through a common business context.

And a way to keep the horses in their barns.

“An effective IT asset management practice is an essential part of any disaster recovery plan. The ability of the IT organization and the business to re-provision infrastructure resources depends on the availability of accurate asset information for installation services and insurance claims. To ensure that your business can survive a disaster, you need to include the entire computing infrastructure in recovery plans.”

• CMDBs are about relationships, documenting how different technical components inter-relate to support business services.  (Topology discovery tools are also essential in populating and maintaining this relationship data into the CMDB.)
• Configuration data for a given asset (CI) is richer than a basic asset repository.  For example, a CMDB can tell you not only what servers you had but also what OS and application software was on them and how that software was configured.
• A CMDB can also be related to a Definitive Software Library (DSL), providing an authoritative source on information on where your “golden copies” of software are. 

Whether a given item should be recorded as an "asset" or "CI" -- or both -- depends on how one plans to manage that component. If you plan to track a component's lifecycle from procurement to retirement, keeping track of purchase records, or accounting for chargebacks etc., then a record of it should be accessible and editable by an asset management application. If you plan to manage an item for its operational impact on services IT delivers to the business, it should be recorded in the CMDB as a CI and the CI record should be accessible to applications for incident and problem, change, release, capacity and service level management.

Another view:

Asset = A physical IT component managed throughout its lifecycle for its value/cost, contractual compliance and usage. Records of these assets have typically been stored in an asset repository. A component should be considered an asset if you want to be able to:

Configuration Item (CI) = a physical or logical IT component managed for its operational impact. CIs are, by ITIL's definition, records in a CMDB. A component should be considered a CI if you want to be able to:

In most cases, IT components can and should be treated as both assets and CIs. Servers, desktops, routers, and packaged applications (truly "assets" by almost any definition) should be managed by ITIL processes to improve the operation of business services. Some notable exceptions:

• CIs not likely to be managed as assets: a custom Java applet, a business process document, or a business service model.
• Assets not likely to be managed as CIs: consumable or bulk items (toner cartridges, mice) and assets on order (not yet received).

Other exceptions may be dictated by a company's business priorities and maturity in implementing ITAM and ITIL. But it's unlikely the exceptions would create such a difference between CIs and Assets as to require two separate repositories. Since the vast majority of assets should also be managed as CIs, you can use a CMDB as your asset repository.

If your asset management application can be efficiently integrated with your CMDB (in a way that allows it to apply asset lifecycle controls to "CIs" and thus manage those CIs as assets as well), there is no need to duplicate invesments and maintenance resources for repository software, data management or discovery tools. More importantly, having the same IT components used in both ITAM and ITIL applications allows you to synchronize your asset processes with your ITIL processes.

And synchronizing processes is where the CMDB's value really comes into play. More on that next time.

A topic I see many of our customers and prospects grappling with is how the familiar discipline of IT asset management fits with the relatively newer concepts around CMDB's and ITIL's "Configuration Management"

Beginning in the late 1990s, IT Asset Management created a unique mandate in IT: to reach across technical and organizational silos in order to account for and manage all IT assets in the enterprise.  Sure, some data about IT assets would always stay inside specialized tools (application development, UNIX or WinTel administration, network management, etc.)  But as IT became a larger and more mature part of the business, the need for a cross-platform approach to business issues such as IT procurement, cost accounting, and compliance became increasingly apparent.  And so did the need for a repository of enterprise assets.

Now, the growing popularity and maturity of IT Infrastructure Library (ITIL)-driven initiatives introduces a similar mandate: to account for all IT components (Configuration Items or “CIs”) and their inter-relationships in a Configuration Management Database (CMDB).  In ITIL terminology, this discipline of establishing and maintaining a CMDB is called Configuration Management.   So now there emerges a critical operational role for a unified repository of information about IT components.

To date, IT Asset Management (ITAM) is conspicuously missing from the list of key processes needed to "run IT like a business".  ITIL has not been particularly clear on ITAM's role and fit with ITIL processes like Configuration Management.  Do ITAM and Configuration Management have redundant mandates to account for IT components, resulting in an asset repository in one organization and a totally separate CMDB in another?  How does an asset repository differ from a CMDB, or an asset from a CI?  Is much of ITAM’s role becoming subsumed by ITIL?

Wading Through Terminology

The term "IT Asset Management" is subject to broad interpretation, creating a semantic trap where almost anything in IT can be called an "asset," and anything done to it is "management."  For example, a server is certainly an IT asset.  Proper configuration of a server can be said to be part of managing that server.  But if a server needs to be reconfigured with an application or OS patch to stop a memory leak, is this an "Asset Management" function?  Most (but perhaps not all) organizations would agree that patching servers falls well outside the responsibility and expected skill set of ITAM.

What if you use a discovery tool to see what you have deployed in your IT environment – is this "Asset Management"?  The answer depends on what you will do with this discovered data.  Asset Management relies on discovery data as a starting point, but requires additional processes, strategies and data to manage discovered entities as assets.  When you use the discovered data to manage software licenses, track leases or reconcile invoices, then you are performing asset management.  Since many discovery tools are marketed by vendors as "Asset Management solutions," it is no wonder that a single tool (discovery) is often confused with the broader discipline of IT Asset Management.

Many disciplines other than IT Asset Management rely on discovered data — from change and incident management to network and datacenter operations.  Indeed, many companies use basic "asset repositories" either partly or solely to support service desk operations, such as incident, problem, and change management.  For example, a database of which assets are used by which employees is helpful to resolve incidents more quickly, eliminating the game of "20 questions" between the technician and user so that troubleshooting can begin with knowledge of the exact make, model, version, and configuration of desktop, printer, or application is creating the incident.  But is this "Asset Management?"

Admittedly, all definitions of IT processes (or any business discipline for that matter) are imperfect, but for the purposes of this discussion let's stipulate a working definition:

IT Asset Management is the discipline of managing finances, contracts and usage of IT assets throughout their lifecycles for the purpose of maintaining an optimal balance between business service requirements, total costs, budget predictability, and contractual and regulatory compliance.  Traditional ITAM activities include the management of inventory, software licenses, vendors, procurement, leases, warranties, cost accounting, retirement and disposal.

Thankfully, ITIL's Configuration Management is easier to describe since ITIL is responsible for popularizing the concept, and because its mission includes forging agreement on terminology.  To summarize:

The goal of Configuration Management is to provide a logical model of the IT infrastructure that is accessed by all ITIL processes to drive consistency among them.   Activities include identifying, controlling, maintaining, and verifying the versions of configuration items (CIs).  This CI information is to be stored in a single repository – the Configuration Management Database (CMDB).

So far, so good.  But there's one more definitional issue to attend to: ITIL doesn't hold a monopoly over the term "Configuration Management".

Many analysts, vendors and IT practitioners use "Configuration Management" to mean maintaining the configurations of devices (such as servers and networks) in the real world.  The reason for pointing this out isn't to start a debate on who has the best definition.  But we need to at least be aware of the differing meanings, lest an otherwise productive conversation quickly turn into an episode of Three's Company (whose many plotlines and madcap hijinx started with a simple misunderstanding...)  Anwyay, I've found it helpful to refer either to "ITIL's Configuration Management" when talking about documenting/modeling the configuration of an IT environment, or to "Software Configuration Management", "Server Configuration Management", etc. when talking about making physical changes to the infrastructure.

With these definitions and descriptions in place, it’ll be easier to draw both contrasts and comparisons between ITAM and ITIL’s Configuration Management.  More on that later...   Meanwhile, what do you think?

Whether you sought out a blog on IT service management or were brought here by the Google tractor beam, welcome!

If you're looking for a technical forum, sorry, this isn't it.  There are plenty of good vendor-related and vendor-neutral forums out there. Instead, we'll share concepts, issues and best practices for IT service management.  Some ITSM topics, particularly the CMDB, are new for many companies.  But even those who have been tackling ITSM for years can attest that it's not a project but a journey, striving for the right balance between optimal processes and business results on one hand, and complexity and resources on the other.

So I hope you'll have a chance to share not only your questions, but also your experiences and thoughts.  What are you struggling with? What has worked, what hasn't?  What advice would you give to others starting down the path you've been down before?

So, pack a lunch, put on some comfortable shoes, and let's get started!