Many enterprises fob off Microsoft licensing expertise to one unfortunate soul who is periodically put on the hot seat, then goes back into the closet until he's needed again. That's not a smart way to handle software licensing because the process is complex and crosses many organizational boundaries.
Someone requisitions software, presumably based on usability considerations. Someone else develops the budget from which funds are drawn. But someone else may have negotiated the volume-licensing agreement through which the software is purchased. Another staffer issues the purchase order and pays the invoice.
Then, someone in IT installs and configures the licensed product and may be responsible for managing the servers or desktops it runs on. An employee actually uses the product. Someone else is responsible for tracking this corporate asset, knowing where it is used and installed, and what record to delete or update when the software is retired or upgraded.
By now, at least seven people need to know something about licensing. If any of them makes a mistake, opportunities for error arise and can be compounded. In some cases, simple errors can lead to million-dollar liabilities.
Any organization in which these responsibilities will be distributed needs to ensure that not only is there someone who knows about licensing, but also that numerous people know how to stay out of trouble and who to call on if it arises. This is particularly true of Microsoft products because the software giant is the most aggressive auditor of corporate licenses.
In part one of this two-part tip, we’ll look at the stages of the process -- from requisition to budgeting -- and why it's important to know about licensing.
Technical staffers are rarely hired with licensing expertise, and ideally, they will spend as little time as possible on it. Nevertheless, anyone involved at a high level of the development process, such as a software architect, should be aware of the effect that licensing can have on budgets, software design and operations.In database design, for example, spending slightly more on hardware can sometimes substantially reduce software licensing costs. Some designs may contain licensing traps -- such as rules that limit load balancing or virtual machine provisioning -- that will ensnare operations personnel and potentially expose the organization to penalties.
Software dependencies are another minefield. Microsoft SQL Server licenses are required for many of the company's other server products. Developers working on a multiserver SharePoint system for use by external customers need a deep knowledge of how SharePoint is licensed to avoid substantial extra costs or inflexible solutions.
Architects should keep such interdependencies in mind as they create models for software performance. Application management should maximize financial efficiency and minimize the risk of ordinary operations requiring extraordinary compliance effort.
Microsoft has at least a dozen programs that offer volume discounts. However, Microsoft and its resellers typically present customers with only a single proposal that tends to be better for the sales team than for the customer.
In my experience, enterprise customers are often presented with proposals that bear little resemblance to their IT plans or goals. Eventually, customers may conclude they have no other option and sign a costly and inflexible program that commits them to long-term allegiance to the vendor, with few performance or delivery guarantees.
Responsibility for determining and negotiating volume-purchasing options may reside in various business units -- legal affairs, finance or procurement, for example -- but the organization should make an effort to understand the full range of options. It can then map its IT goals to the purchasing program most suitable to attaining them.
This implies another critical element in licensing -- communication. If operating units can clearly describe their requirements, the IT organization can match them to specific hardware and software, and the purchasing organization can match the architecture to the optimal purchasing process.
In Microsoft's case, timing, as well as price and other factors, come into play: Purchases that are not required immediately can sometimes be timed to generate superior discounts, if someone understands how Microsoft's volume-purchasing programs work.
To ensure that funding is available for IT purchases and to reduce the risk of loss, those responsible for budgets should match licensing requirements and purchasing plans to the organization's overall budget and financial processes.
In some volume-purchasing programs, Microsoft offers zero-interest "spread payments," which typically require a purchase of Software Assurance (SA), Microsoft's upgrade and maintenance add-on. At 25% or more, it is a costly payment-planning vehicle. Microsoft Financing, the company's lending unit, offers commercially competitive interest rates and is better for organizations looking to spread payments over several years. SA is not required in this case.
Microsoft's subscription-purchasing plans can be another useful option, particularly since they may offer tax benefits in some jurisdictions.
Some organizations may face major, one-time expenses when they purchase software or additional desktops partway through an agreement. Budgets need to reflect not only predictable, ongoing payments, but periodic extras as well. An organization with a grasp of its financing options and the events that might trigger unplanned expenses may be better able to defend -- or defend against -- extraordinary expenditures.
Now that you've assessed your needs and gotten funding, what steps come next? In part two of this two-part tip, I'll discuss actually procuring, using and monitoring Microsoft-licensed software.
ABOUT THE AUTHOR
Paul DeGroot is a writer, trainer and principal consultant at Pica Communications, which specializes in Microsoft licensing strategies and policies.
This was first published in July 2011