When you decide to manage your organization’s software licensing and entitlements with the aid of technology, you quickly realize just how many non-technology factors need to be considered. You really don’t necessarily require technology to manage licensing or entitlements. In fact, several organizations manage these via audits and manual updates to internal systems.  Manually tracking entitlements and licensing is an approach with its own set of shortcomings, the most notable being the inability to exact any measure of control or perform any kind of true audit. Organizations generally tend to favor software overuse, except when it comes to specialized software where enforcement and restrictions are commonplace and expected.

If the organization does decide to use technology to manage software entitlements, home-grown solutions are often considered a low risk, low cost and fastest to market approach. However, time and again this model has proven to be more costly in the long run for organizations. Home-grown licensing solutions place undue burden on precious development resources, and are a hindrance to long term growth.  This is because home-grown solutions rarely are built with future business models in mind.

Regardless of whether an organization has built their own licensing enforcement system or uses a third party, organizations quickly realize that in order to truly deploy any kind of meaningful system, a lot of work is required to marry technology with business processes. The reason for this is that licensing rarely just serves one purpose, nor is it the domain of just one part of the organization. A business model required by product management needs to be developed by engineering, fulfilled by operations, managed by IT and supported by technical services. Each of these groups works in a relatively independent environment; they do not share the same tools and technology as part of day to day business, and often have minimal interaction which each other.

So, how exactly do independent departments come together to bring licensing harmony to the organization? If you’re like a lot of organizations, the process begins with a decision to make.  You could build, but maybe you should buy, and in either case the solution is so complex that you worry you probably won’t have something that works very smoothly. Unfortunately, this is precisely the reality that most organizations face and the resulting “broken” system results in negative backlash towards any type of licensing project. “We didn’t have these problems until we introduced licensing” says the CEO frustrated by customer complaints. “Our systems weren’t meant to handle this” says the CIO defending the lack of clean and useful data that IT was meant to provide.

Why does licensing end up bearing the backlash for development projects?  Many organizations do conduct thorough analyses of their requirements, put together RFPs, and create cross-functional evaluation teams.   The reason is simple: Because even with all the right measures in place, each functional group will focus primarily on the requirements that are relevant for that individual group to get the job done, versus looking at the bigger comprehensive picture.

Here is how disparate the internal process can be.  Engineering focuses primarily to make sure that functionality being built into the product supports the use cases identified by product management. Once the software’s functionality meets the requirements laid before them, Engineering’s part of the job is essentially done. Similarly, IT and Operations will look at the impacted integration and delivery touch points to ensure that their requirements are met.

Herein lays the problem.  There is no role in most organizations that is dedicated to looking at the overall project and ensuring that all the required pieces are implemented for a fully operational licensing system.   And, even when this role is assigned, it doesn’t necessarily ensure success. A sound software licensing implementation still requires a few key elements:

  • Identification: Identifying functionality across business areas is required to integrate everything together smoothly,
  • Oversight: Having oversight for the entire project ensures all the various pieces will work together.
  • Accountability: Who owns it? There needs to be accountability for the person or team to make sure the project is successful.

Do you think organizations can have a successful implementation across the business without any one of these elements?  Or, do you have another element that should be on the “must-have” short list for licensing implementations?  Share them with our community.