Perhaps the biggest challenge to pushing a SAM program forward is getting people to recognize the problem before the sky starts falling. It is easy to have a successful looking veneer over what is actually complete chaos since using/installing software is simple. It is managing software which gets complicated, but not doing so is like living on credit. Everything seems fine until the debt comes due in whatever form it takes. It we are lucky it might be something straightforward and financially contained like a software audit or true-up. For those who have been through an audit it may be hard to think of this as lucky since, especially when vendors start lining up, times can get pretty bleak. What many people do not consider however is that license compliance problems are relatively benign overall when compared to some of the real nightmares companies have experienced. What is the cost of a security hole which allows a hacker to steal the financial records of your customers? Or of two separate engineering teams working on different parts of a design using subtly incompatible versions of the same software? Having good SAM practices in place does not guarantee that you will avoid from all such events, but not having them in place certainly exacerbates the risk. At a minimum their lack means your organization will spend substantially more on software and get substantially less from it than you otherwise could.
One of the near universal frustrations facing advocates of Software Asset Management is the mercurial nature of the support we are given for our initiatives. Generally when SAM gets attention it is in reaction to something which has already happened rather than general sponsorship to create an environment which minimizes the risks of something bad happening. Either way the driver is almost always risk mitigation or avoidance and generally limited to compliance risks. There are tantalizing glimpses of the potential cost savings available from license optimization and more advanced activities we could undertake if we only had the basic foundation in place. Unfortunately, we seldom get the chance to be proactive and the urgent issues of today take precedence over creating the solid foundation we need to go beyond the basics of compliance. SAM initiatives are almost always bound by practical considerations of what we can realistically accomplish within our organizations and the current situation driving things. Even when there is no immediate crisis the tendency is for narrowly focused and evolutionary changes, rather than revolutionary ones. Certainly, this is the type of pragmatic approach I have taken with clients in the past. Where does it hurt the most and what can we do to address that? The conservative (and probably sensible) approach is to pick relatively small problems which can be cleanly scoped and where there is a good chance for success.
But what if you were given the opportunity to pitch a strategic “SAM vision” to the executive management? What if you could get the necessary sponsorship to make revolutionary, foundational changes to how your organization uses and manages software? What would you do? What would SAM look like if you were really tasked to do it right? The chance may never come, but it still seems important to take some time to think about what an idealized vision of Software Asset Management anyway. Solutions to the problems of the moment are always constrained by the current situation, but there are also choices within the available options. Keeping your ideal vision of SAM in mind allows you to measure those options against it. You can then choose those options which move you just a little closer towards it while still taking care of the immediate issue. And who knows? Perhaps those little victories will set the stage for the opportunity to make your case.
Suddenly living in a fully ISO 19770-2/3 compliant world exceeds even my ability to dream, but within what an organization can do and control… what might Ideal Software Asset Management look like? Here are my thoughts on it. I spend so much of my time being practical it just felt good to put that aside for a time. Hopefully, they prove stimulating and I welcome your comments and criticisms.
It Starts with the Software Lifecycle
Something interesting about Software Asset Management is that it owns very few pieces of the software lifecycle. I do not feel SAM should try taking over these roles, rather it should act in an overall coordination and governance capacity. If we own anything it is really the lifecycle itself and the analysis of software as it makes its way through it. To be successful SAM must work in cooperation with the other groups/competencies within the organization responsible for various pieces and parts along the way. If the contract/vendor management is not actively involved to ensure the license terms are completely understood and negotiated where appropriate, the management of licenses is crippled. Without release/distribution management we cannot control the deployment of software or ensure we can accurately discover it. Information security must be engaged to determine if the software represents a threat or exposes the organization to unknown risks and liabilities. These groups tend to have a detailed grasp of what they do, but often miss the big picture and/or fail to understand what is upstream/downstream of them. By publishing and communicating the overall software lifecycle SAM can help put everything in context.
To effectively manage something we must understand it and fundamental to this is to know its lifecycle. So when it comes to managing software it is no surprise that there are a variety of software lifecycles out there from various sources. Each has varying levels of detail and granularity in different areas, but most are quite similar. They also fall into two broad categories: one type describes the overall life of a software title within the organization and the other particular individual uses of it. The lifecycle I will attempt to describe is the first kind and I view the second to really be a subcomponent of the first. A lifecycle is commonly said to track something from “cradle to grave,” but that does not go far enough. It starts too late and ends too early. To effectively manage something we need to know about it from the time the potential for it is conceived and then long after it is gone. So instead of “cradle to grave” we need to go from “conception to decomposition.” This high-level, somewhat abstract, lifecycle has five phases to it: conception, birth, life, death, and decomposition.
The phase most often left out or minimized, conception is the foundation for the rest. Crucial to managing software within your organization is having control of what software is allowed within your organization. Standards and established processes are important across the IT infrastructure and how we manage it, but, due to the need for reconciliation between its various disparate aspects, nowhere are they needed more desperately than in our use of software. It is this, more than any of the other details, which I believe is truly at the heart of good Software Asset Management. Just having a defined set of standards and processes in place and being followed is generally better than utter chaos, although good ones are obviously much better.
It is quite common to have a “black list” of software which is explicitly not allowed for a variety of reasons, most often security related. This is not enough. There should also be “white” and “gray” lists as well. The “white list” has the software which has been explicitly validated and allowed for use. The “gray list” is for software which has been reviewed for inclusion in either the “white” or “black” lists but not qualified. Keeping a “gray list” allows you easy access to your prior analysis should the software in question need to be reassessed. When evaluating a software product for inclusion on the “white-list,” a variety of aspects should be looked at: functional, contractual, technical, security, etc… Is there already software on the list which fulfills the purpose for which the new software would be needed? Is there justification to add another one if we have already selected a standard? And if not, is there potentially a better option out there than the one being evaluated? Does the licensing agreement support how you manage software? If not, will the vendor allow it to be modified? Will your software deployment, discovery, and patching tools work cleanly with it? Does is work well with the rest of your environment or does it conflict with other software or policies? Are there any known security concerns or potential vulnerabilities?
No software should be used in the enterprise without going through this process. Even specific small-scale uses should go through an abbreviated version of it. This may seem extreme, but the downstream costs and risks of not doing so are substantial. Once “white-listed,” the software is authorized for use within the environment, but it is not ready and available for use.
Before allowing users to request a piece of software, we need to ensure that we can fulfill those requests. As part of being “white-listed,” software is validated against deployment and discovery tools. Actually making the software fully deployable and ensuring discovery does not happen until now since doing so earlier could result in wasted effort. Also, various deployment technologies offer many new capabilities which we may want to take advantage of. Unfortunately, these are often a few years ahead of what is allowed by standard license contracts. Negotiating the terms of our software contracts during the “conception” phase can allow us to legally take advantage of the advantages offered by these technologies far faster.
Once a request for the software can be fulfilled, it can be added to the catalog of requestable software and made available to users. This software catalog might be a dedicated system or part of a larger overall procurement or service catalog, but the crucial mandate is software not made available to users, through whatever means, until all the pieces are in place to manage it appropriately. Keeping things under control from the beginning is critical to managing them going forward.
One of the main business drivers for a self-service catalog is usually to shorten the fulfillment time. Modern software deployment tools can have a piece of software deployed within minutes of receiving the command to do so. Two core process issues often get in the way of realizing the hoped-for benefits: getting the request approved and validating the license entitlement. Fortunately, these can be largely addressed in the desktop space and because of the differences in cost and timing in the server world, they are generally not relevant.
Confirming licensing is really part of the next phase, but there are things which can be done up front to how speed up the time it takes to approve a request. This assumes that the request system allows appropriate approval workflows to be built for each piece of software. The first and simplest of these is to check if approval is really even needed. In many cases the request for a particular software title is never, or extremely rarely, going to be denied. These “rubber stamp” approvals do no one any good, slow things down, and take up people’s time unnecessarily. Just identifying where you can eliminate the need for approvals completely can be a big win. Ideally these workflows should also be robust enough to bypass manual approval in cases where the requester already has an existing authorization or meets other criteria which allow for automatic approval. For the majority of desktop software the need for personal managerial approval can likely be eliminated in one of these three ways.
A software catalog should also provide appropriate access since, as with many other types of things, not all software is necessarily available to all users. The price of software in the catalog should reflect the overall cost of it to the organization, not simply the license. In many cases, particularly with desktop software, the license is a relatively small part of the overall cost when other activities related to the software lifecycle are factored in. This becomes even more effective when using centralized ownership as discussed in the last section. Once made available in the software catalog the software is “born” and can be requested, but it is not yet out and active in the environment until it is requested and deployed.
Once actively available to users, the real life of a given piece of software begins and this “life” is full of many separate sub-lifecycles as it progresses within the organization. The “life” stage of the software sits above this activity like a traffic light which has turned green and has cars streaming by underneath. All the things set up during the prior two phases are now executed so that the organization can receive maximum value from the investment. Breaking down this stage into all of its myriad pieces and parts would get far too detailed, but we can look at some of the main parts that have to happen.
When requested, software may require approvals and/or payments to occur before the request is fulfilled. Any licenses should be procured centrally when needed and added to the central license repository along with the requisite proof of purchase. When possible, rule-based automatic approval can avoid wasting time on “rubber stamp” approval activities. Approvals should be retained both for normal record keeping and so that they can be used, if appropriate, to short circuit the process in the future if the user needs the software again. Once approved, software should generally be deployed automatically to the user. This fulfills the request, but actual closure should occur when the new installation is confirmed by discovery tools and matched against the deployment request. If new installations are found which do not have a matching deployment request, a discrepancy report identifies these process deviations.
Many things may happen over the life of a software installation. New versions or patches may become available and validated for use. The user who requested the software may get a new computer and need the software installed there. The computer’s user may change and the software may need to stay or to be removed as no longer authorized. The user may no longer use the software and want it removed. Or, they might not notice and we might ask them if we can remove it to reduce our license obligations. Regardless of the situation, what matters is that the deployed software be actively monitored and managed along with the contracts and licenses associated to it.
For software, the line between life and death is often blurry, but from my perspective death begins when the software is deemed obsolete and removed from the catalog of requestable software. Of course, just because no new instances are coming into the environment does not mean that all the existing instance go away. In many respects, death for software may still look quite a bit like life. We should strive to make this phase as short as we reasonably can, but should not be surprised if it takes quite a while. As part of this process, licenses for older versions need to be accessed and either upgraded or retired. Care must be taken not to continue maintenance on software which has been removed from the environment.
There can be different reasons for deciding that a piece of software should no longer be available and those reasons can set the pace for the elimination process. If it is a simple case of a newer version being available it could easily take a couple of years. On the other hand, if a security issue cannot be remediated, the process may need to happen extremely fast. Overall, once we have decided it is time for a software title to die, it is generally best done with all deliberate speed. There are always exceptions and Microsoft Access 97 comes to mind as a long-lived “zombie.” As much as we want it out of the environment, there are so many homegrown applications built on it that stamping it out is difficult. It has gotten so old and potentially risky that there are quite a few gray hairs out there because of it.
When the last instance of the software is gone from the environment we can finally truly close the book on it. Any licenses which can be usefully upgraded should have been at this point and we have confirmed that there is no active maintenance or other ongoing costs associated to the software. Records still get maintained, but the often slow process of death has come to an end. We are done and the software can be dropped from active management and things like compliance reports. The only thing still left is a memory of the software within our discovery tools should it somehow pop up somewhere in the environment again.
And Now for Something Completely Different
At the heart of Software Asset Management is the goal to maximize the value our organizations get from the software. To do this, we need to get the most we can out of the licenses we purchase at the lowest cost while not limiting the utility to our business users. This often seems like an impossible balancing act. Just going to our business users for permission to uninstall unused software frequently meets with resistance. And licenses sit unused within one part of the organization while another part purchases a new one. From our SAM perspective, we can see the opportunities for savings, but realizing them is often an exercise in frustration. The good news is there is a way to turn all of that around. The bad news is it is likely to be a pretty big organizational change.
Central Ownership of Licenses: Maximize License Utilization with a Rental Model
In most organizations the ownership of software licenses is distributed. Licenses are owned by the various departments or business units. Purchasing may be diffuse as well or it may be centralized to some degree. Many types of software are only needed intermittently or for a certain period of time. Certainly, this is not true in all cases, but even for those titles which do see constant use; installations sit idle most of the time. This is only to be expected since most software is a tool for a specific purpose. However, there is a vast amount of installed software which is truly unused or underused but still consuming a license. The question of how to reclaim these licenses is something which is at the top of the list for many Software Asset Managers. The potential for savings is easy to calculate and generally quite substantial.
It is possible for the Software Asset Management group to identify unused software and attempt to actively reclaim those licenses. However, doing is generally time-consuming and relatively ineffective, if only due to the simple numbers: there will always be far more users with unused software than there are Software Asset Managers to go hunting for licenses. And even when an unused piece of software is located, getting the user to allow it to be removed is often difficult, especially if it is not easy to request it be deployed again if they need later on or if they have to pay for it again. The main barrier to reclaiming a license is most often the notion that “I bought it, I own it” by the user or the user’s cost center. Even when there are significant savings from uninstalling the software it is often politically difficult to actually get it done.
So how can we turn this around? Ideally, we would want to set up a situation in which the users/requesters of software monitor themselves and want to have the unused software removed. Instead of hunting for unused installations and then convincing users to allow removal, SAM would be in the position of users seeking this service. This can be achieved by changing how business users pay for software.
The key is in how software licensed assets are owned. Everything is owned by the enterprise, but in most places, the full cost of the license is incurred by the initial user. This creates the “I bought it, I own it” mentality mentioned earlier. Instead of buying the License for a user, have IT buy the license and “rent” it out to the user. Now, there will be an ongoing cost to having that software installed, which means if it is not being used they are going to want it gone. And if the user does not care the manager certainly will. As long as it is not painful to request that software be deployed, our problem will have largely taken care of itself.
The demand for this is already there and can be seen in the enthusiastic response to SaaS and other subscription based models. Yes, there is work to do to set it up and the devil is in the details, but the potential gains are enormous. And, as with any type of rental, the owning entity is going to have an initial cost which will be recouped over time. Pricing what the rental price will be is problematic and depends on a variety of factors such as the inventory and utilization rates. The good news is they are highly solvable problems which have been successfully addressed for many other types of assets. The even better news is that with the increased use of virtualization, almost all of this actually applies to hardware as well as software, particularly to server hardware, as evidenced by the rise in IaaS, PaaS, and other “…aaS” offerings.
The transformative change needed to get to this point is a big one and will need some high level sponsorship to drive it forward. I believe the benefits to doing so however are tremendous.