The question regarding software licensing has arisen. To put this in better context I am referring to the purchasing of licenses either to supplement requirements or for renewal purposes.

The argument is that it is for configuration management (in any sense of the word) to purchase and maintain the software licenses in all scenarios. I strictly disagree, especially as my role is quality assurance, not management.

I believe it is for Release Management (supplier or project) to ensure that licenses have been purchased for any new/changed product but I do not know who the responsibility for ensuring those licenses are maintained and renewed falls to. I believe it is some sort of procurement division, financial management perhaps?

- manage it's financial inflows and outflows
- centralize and track all contracts, which is critical for renewals, mergers, acquisitions, & divestitures
- centralize and track all product inventories
- centralize and track all "expected asset inventories" as, they usually know what assets will be coming in
- centralize and track all license information
- centralize and track all vendors

A strategic and centralized Vendor Management organization (or an organization that is accountable for such activity) is critical, these days. With everything that's going on with respect auditing, compliance, and legal ramifications, licenses are "contracts" that have some different characteristics. Vendors actually put in legal/contractual stipulations that allow them to send in independent auditors, at any time, to check up on how you manage their products. And, if you don't have a centralized group that strategically manages all of these things, you may have bigger issues than you think.

Now, if you're asking "who procures software licenses?" This is a different story. The issue now becomes: "Who will be the Product Owner for the software?" It is a very strong best practice to have an accountable owner for each and every product in your enterprise, hardware, software, vehicles, etc. This way, everyone knows who to turn to and who is accountable. My recommendation is that the Product Owner, which is "always" internal to your enterprise, should initiate the request for purchase of the product to the Vendor Management/Procurement organization. The Product Owner may be acting on behalf of end users that are the source of the request or even the sponsors for the product.

"When to purchase the product" depends on your product lifecycle flows. Hopefully, your buying your products or checking your license inventories at the beginning of your development and engineering projects, as part of your Requirements Management process (another critical operational process not covered by ITIL).

If the renewal is strictly a maintenance renewal issue, then this should be the function of the Vendor Management organization, who should be checking for all forms of contractual expirations, long before they occur. This is critical because license renewals should be budgeted for, well in advance or procurement, and, if done properly, can be properly handled by accountants in a way that will meet their needs.

The Release Manager should manage the software license as part of the DSL. In addition, the RMgr should work with Operations Management to come up with a person who deal with Vendor Relationships. However, if the focus is the renewal of licenses etc. ; then the RM should work with the Change Manager & the configuration librarian in developing processes and procedures to renew / cease etc licenses.

In addition, the RMgr should work with the corporate procurement staff to determine the best to renew the licenses.

Some S/W, H/W F/W license agreements automatically do the billing.

And the details of the licenses and maintenance data needs to be in the CMDB_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

The Release Manager should manage the software license as part of the DSL. In addition, the RMgr should work with Operations Management to come up with a person who deal with Vendor Relationships. However, if the focus is the renewal of licenses etc. ; then the RM should work with the Change Manager & the configuration librarian in developing processes and procedures to renew / cease etc licenses.

In addition, the RMgr should work with the corporate procurement staff to determine the best to renew the licenses.

Some S/W, H/W F/W license agreements automatically do the billing.

And the details of the licenses and maintenance data needs to be in the CMDB

While it's not unheard of for Release Managers to be responsible for licensing, there are a number of potential "gotchas" in your statement that may make it difficult to implement properly. Some things to consider...

First, a Release Manager may not be assigned until after processes like Requirements Management, Design, and Prototyping (possibly even formal development) are long done. At this point, decisions on SW should have been stabilized and the SW procured, long ago.

Also, what is in the DSL will be addressed as part of "development's" needs for designing, implementing, building, deploying, installing, instantiating, and executing the software. The Release Manager won't know what he or she will be controlling as part of the Release until all of that is stabilized, which means developers have already been using the software for quite a while. This implies that the developers need SW and it's licensing to be stabilized long before it's deployment to a production environment.

Another problem is that in organizations where there are multiple environment that have centralized control, the Rel. Mgr. for each environment might be different. In a case like this, which Rel. Mgr. would be responsible for the SW licenses? First? Last? One in the middle?

Also, in mature organizations, where Builds, Distributions, etc. are all automated, the Release Manager has a very limited role, which is to ensure a script gets kicked off in targeted environments, properly, and according to schedule. He or she may have no say or view into what software is leveraged, as it's all part of the scripted builds and deployments that were set up by development.

What licenses are needed are usually part of the Project Planning function, which is very far up (or in the front of) your product/system lifecycle process. It's typically up at the beginning, with Requirements Management, which flushes out what you need, and then is itemized in your Project Plans to ensure it gets done. Then development and/or engineering teams procure what they need to get the projects moving. This is, more common than not, long before the Rel. Mgr. gets involved in most projects.

You are a bit wrong in what I am saying. I am looking at this from an OPERATIONAL point of view not a development POV.

If an organization has for example 100 PCs with Microsoft Office Professional, a MS Exchange server, MS SQL and some other tools such as Remedy etc

There would need to be 100 licences for the desktop software w/100 unique Keys and certificates provided by the vendor who sold the systems -
There would be the server licence for the Server O/S
There would be the seat license & O/S licence for Exchange, SQL and Remedy.

The seat license are usually bought in some sort of package on an annual basis -

The question is who manages these licenses

The answer - The Release Mangement environment manages the DSL - therefore the RM process should manage the licences.

However, once created then the only real involvement is the finance department paying the fees annually

But what if the user base doubles/triples/halves... how is the numbers tracked - total users, concurrant users._________________John Hardesty
ITSM Manager's Certificate (Red Badge)

I agree that the RM is responsible for the operational management of the DSL and that increase/decrease in software will have an affect upon the licensing.

I also agree that procurement/finance/project will actually pay and arrange for the correct number of licenses to be provided and that the RM will ensure this is correct before submission into the DSL.

I therefore need to ensure that there is a finance management procedure for the renewal of licenses on a yearly/quarterly basis (whatever the renewal period is). At the moment the fingers all point to me.

You are a bit wrong in what I am saying. I am looking at this from an OPERATIONAL point of view not a development POV.

Take a look at what I say below. You recommend the Release Manager doing the work. I believe that the Release Manager is long gone and can't do the work. End users will ask for software to be installed on their desktops, which will require the allocation of licenses, strictly as operational Service Management functions. It will have nothing to do with Releases.

Quote:

If an organization has for example 100 PCs with Microsoft Office Professional, a MS Exchange server, MS SQL and some other tools such as Remedy etc

There would need to be 100 licences for the desktop software w/100 unique Keys and certificates provided by the vendor who sold the systems -
There would be the server licence for the Server O/S
There would be the seat license & O/S licence for Exchange, SQL and Remedy.

The seat license are usually bought in some sort of package on an annual basis -

Actually, they're only "bought" the first year. Every year after that, it's simply a maintenance and support payment for all existing licenses. The only licenses that are purchased/bought would be any "new" licenses that are incremental. The typical terms are that the consumer/enterprise buys "X" seats and pays list price for the seats and an additional 15% - 25% in maintenance and support fees in the first year and an ongoing 15% - 25% for each year, thereafter.

Quote:

The question is who manages these licenses

The answer - The Release Mangement environment manages the DSL - therefore the RM process should manage the licences.

Actually, this is very incorrect, since the Release Manager is long gone after the Release is done. The Release Manager can only facilitate the allocation and management of licenses during a Release. Once a Release is complete, you may not have Releases for months and the Release Management function may cease to exist during that period.

Operationally, which is what you brought up, the Release Manager is not involved in provisioning licenses to most End-Users, as this is typically not part of a "Release". For example, you buy 100 seats of Remedy, which means you are contractually entitled to 100 seats. Rolling out Remedy the first time, you might deploy 50 seats for the first Release of Remedy. In this case, yes, the Release Manager would help ensure that all licenses exist and are deployed as part of the rollout. However, long after the Release/Deployment is done, new users may need access to the tool. The Release Manager is long gone. In this case, the end users will typically put in a Service Request, via the Service Catalog or a call to the Help Desk which will act as a delagate to the Service Catalog, to have the software installed on their desktop. The Service Group responsible for ensuring that the right person is entitled to the tool will perform whatever work needs to be done to add that end user to the appropriate license groups, etc. Then the user can install the software and run it properly. There is no Release Manager in this process.

What I believe you're asking about, here, is who performs the management of what licenses are in use, where they're installed, how they're installed, what products they correlate to, etc. This is simply an Asset Management function and is typically the responsibility of the Service Group that allocates the licenses to the appropriate end users.

Quote:

However, once created then the only real involvement is the finance department paying the fees annually

Actually, it's not the finance department that should be involved (they only cut checks and deal with accounting) but, as per my recommendation in the previous post, the Vendor Management group that should be performing such functions. They're very different groups with very different responsibilities.

If you're proactively managing your enterprise properly, as recommended by ITIL, you will not "blindly" make a payment to the vendor in the new year. The Vendor Management group will ensure that the licenses are properly being utilized and that it makes sense to cut a check of that magnitude or if they need to renegotiate new terms to improve the enterprise's situation.

You've obviously never been seriously audited or sued by a vendor. Once you are, you will change your views on this topic very quickly, as to who should be managing licenses. Vendor Management typically acts as the gatekeeper and controller for "all" contracts of any form, including licenses. It is their responsibility to ensure that contracts have not been breached. It is therefore their responsibility to know every detail of every license in the enterprise. If you're not doing this, I highly recommend you think about it. Enterprises that have instituted competent Vendor Management groups have been able to take advantage of some very significant savings and avoid some extremely complicated legal situations. Vendors will naturally run over your enterprise to work in their own financial best interest. A smart enterprise counterbalances this with a VM group that is constantly beating the vendors up to lower their costs or provide better value.

Quote:

But what if the user base doubles/triples/halves... how is the numbers tracked - total users, concurrant users.

I agree with you that this is an "operational" task but it is also an Asset Management task. The instance of a SW license is, itself, an Asset that needs to be inventoried and tracked.

The superset of License Management is normally tracked by Vendor Management from an "ownership" perspective. It is their job to understand how many licenses the enterprise is entitled to, who is entitled to them, how they are to be used, and then to correlate this information back down with the teams performing Asset Management functions, that can tell you what is actually installed and being used in the environment.

If you have to include this yourself and keep audit an application like Centennial's Discovery will audit your estate and keep track of all licences and software version etc

Hi Jason,

There are place where this breaks down. For example, where a large enterprise has a global Enterprise License Agreement, where an enterprise is free to simply install and use a product, at will. I personally believe that all such installations should still be managed but, unfortunately, there are many enterprises that will not.

I don't agree that the licenses should be kept under control of Release Management. Licenses are a typical CI type, and this is the way you can keep track of them (how many you have used up, when does it expire, etc.), therefore I definitely see them under Configuration Management. Who actually buys them and goes through the procurement process can vary, depending on the organization's implementation.
The DSL is for keeping a master copy of your digital CIs (software, testing products, documents) as the ISO20k requirement says, and my opinion is that it has as much to do with Configuration Managament as Release Management.
I don't see licenses themselves as DSL items, but probably that's my issue.

hi, there are some strong points made from everyone about who is responsible.

If we go back and look at what Release Management is about, it does not state contract management as one of its duties. This is stricly an Asset Management function and should stay that way.

Renewing of licenses invloves many financial aspects, negotiation skills, etc, that are not part of the Release Managers role. There are the ones who you have to go to to talk to before you purchase any licenses before rolling out a new system. Is the Release Manager involved in these activities? How manages the contracts themselves? When are the lawyers involved? A few questions to think about.

My suggestion is to remove this fucntion from release management and give control back to the Asset Management domain.

I think there are some misconceptions about the ITIL processes. What process like Release, Change and Configuration, etc. Management processes are responsible for is managing their respective processes and ensuring procedures are followed and conformed with. They are not the "doers" of the process. With that said Release Management would not manage software licenses. Configuration Management would record and track them, Release might maintain them in a DSL but the responsiblity for the procurement and ordering and the overall ownership would go to another group. Where I am employed we have a group called "Contracts" that for whatever reason has that responsibility. Our Configuration Management process aids them in the usage of Enterprise class server software but that is it. I like the idea mentioned in an earlier post of a Vendor Management group for this purpose. There is an ITIL process for this called appropriately enough "Software License Management process".

Dpagucci
ITIL Practitioner Release and Control + Support and Restore (IPSR & IPRC)

Whether at the early stage of provisioning the licences as part of a project/release/delivery, or making sure that the number of licences grows with the user population, belongs, to me, to Capacity Management.
Ca.M will "count" for the licences available vs needed as it would for disk space, ram , number of desktop, bandwith, etc....
Ca.M will also check for licence expiration and renewal._________________JP Gilles

I think everyone is right because there is no one answer. ITIL is just a framework of best practices to follow without a lot of specific procedures that must be followed. What the answer to license management and a lot of other questions comes down to one thing and that is what is best for your organization and what adds the most value to your org. When implementing ITIL you design and align the process to fit the organization in the best manner possible. So I don't think there is any wrong answer to this question. I would like to say that the people who respond here on a regular basis are very experienced and very impressive. Really does make interesting reading.