Strategies for Software Deployment and License Management

Preventing unauthorized software usage, convincing top management to purchase large enterprise-class software and integrating it with existing applications were some of the challenges that our survey revealed. Here's the full report

Sunday, July 16, 2006

Software is becoming increasingly complex and difficult to maintain, thanks to frequent version changes and even more frequent upgrades and
updates. The moment you install a new software and train your users to be comfortable with it, up comes a new and better version. Even if you decide to forego the new version until you really need it, what do you do if a major patch is released for it? That's something nobody can afford to ignore. So should you just forget about commercial software and develop your own in house solution? Managing software across remote branch offices takes away a significant amount of time and energy.

Software licenses and their management is another story in itself- cost, preventing unauthorized access, renewals, etc.

All this is enough to give any CIO nightmares. In this story we find out the critical issues faced by some key IT decision makers across the country and see how they handle them.

Managing large s/w deployments
By and large, around 70% of the CIOs we surveyed felt that doing a large new software deployment was a very significant issue. There were two key reasons given for this. One was to integrate it with existing enterprise applications. The other reason had nothing to do with technicalities, but convincing the top management about the need for it.

Once the initial hurdle of purchasing a large application is out of the way, next comes its deployment. Here, we asked for the key areas of dissatisfaction. We received a mix of views, which covered everything from user-related issues related to those of the top management, to even the IT staff that does the actual deployment. Integrating new s/w with existing applications also emerged as a deployment-related issue, just as it was an issue when purchasing a large software. Getting top management involved in successful deployment seems to be a challenge. On the users front, there are issues like poor knowledge, matching their expectations, and handling their attitude with the new software.

Another challenge that needs to be overcome during a large software deployment is understanding and defining the scope of the implementation. Unless this is clearly understood and outlined, there are likely to be project delays and compromises on the quality of implementation. The end result, of course, is dissatisfaction amongst users and the top management. Automation can help in large software deployments, but there are key issues to be overcome before that can be successfully done. Automation will be fast and smooth provided you have standardized on a single OS across the enterprise.

Likewise, you need to ensure that all your machines have the latest patches and updates, and are free from viruses, other security issues, etc. The biggest problem in achieving automation is that even a small problem can wash out the whole effort. A heterogeneous environment with unpatched machines, older versions of OSs, etc is likely to have lots of such small hitches. The issue becomes even more significant when you have to do it across all your remote offices as well. Other deployment hurdles include doing the right level of customizations, handling rapid changes in technology, and retaining skilled IT staff to do the deployment.

Negotiating a s/w deal
This is more of an art than a skill, which is extremely tough when being done for a large software deal. The biggest concern raised by a majority of
respondents here was the kind of support they would get after the deployment. Would they for instance, get the latest upgrades and updates for the software on a regular basis? Some were quite skeptical about whether vendors had the requisite domain business knowledge to be able to support them after the deployment. Would the vendor be able to maintain the developed software after doing the initial handover? Another CIO was concerned about getting the right service levels and timely service from the vendor.

Cost is a major issue when enterprises negotiate a large deal with a software vendor. This doesn't include the basic cost, but the license cost, the cost per user, and the effort needed to support as well as deploy it over a period of time. In other words, the TCO for a purchased software is a bigger concern for organizations than its initial cost. Also organizations are very cautious that they don't end up buying something that's not easy to use and scale up.

In-house or commercial software?
Should you use in-house or commercial software? An overwhelming number of respondents said that they were using in-house software (in addition to commercial software). Their reasons for the same varied. Many felt that it was not worth the trouble to go for the commercial one. It either did not meet their business requirements, or the tender process for its procurement was too complicated. After-sales service seems to be an issue here again, as one of the CIOs said that he was not satisfied with it, and, hence, it was better to go for an in-house software. Cost and flexibility were other reasons for preferring in-house software to commercial. Unlike commercial, in-house software development can be controlled such that it only has features that are absolutely necessary for an organization, thus, making the software slim and customizable.

Handling s/w rollouts
The biggest area of dissatisfaction when doing major software rollouts are the users. They take time to accept the change, which is natural, as they're very comfortable using what they already have and in following the traditional way of working. The larger the organization, the bigger this challenge becomes. A new software means they would have to put in extra effort to learn to use it. Thus, it's a challenge for IT decision makers to create awareness amongst users about the new software and train them on using it. Our respondents threw light on many other areas that need to be looked into while doing a large software roll out. One is to define a process and schedule for it and then adhere to it. The framework for doing software rollouts should be such that it requires minimal manual intervention. The challenge here is to ensure that your IT team doesn't adopt shortcuts in the process. Another area to address is to define how much customization do you need to do to the rolled out software. Getting users' feedback for this is important, but only to a certain extent. It shouldn't happen that you end up satisfying a small set of users with the customizations, while the larger chunk remains unsatisfied. If you have offices in remote locations, then you need to have a well-defined strategy on how you're going to support them after the software rollout. One last thing that came up was performance testing. Clearly, you need to study the impact of a new software on your IT infrastructure before actually rolling it out. How much bandwidth does it consume on the network, and will it run on existing hardware? These are a few points to ponder over. Around 60% of the respondents said that they don't use any solution for doing automated software rollouts.

Remote deployment
Our respondents use various interesting ways for deploying software across their respective organizations' remote offices. By and large, these can be divided into on-site and remote deployment. A majority of the organizations were doing it remotely over their communication links. The options ranged from doing it over FTP, WAN links, VPN, and even using products like Citrix for the job. There were also a few who used a mix of remote as well as on-site deployments. Wherever possible, they would deploy it using their WAN links, and for other places, they would send CDs, as well as experts from the head office. Interestingly, more than 50% of the respondents said that they managed to do their deployments in a week or less. Only a third of the respondents said they took a month for the job, and even a fewer number took several months for the job. This along with the connectivity options indicated by the respondents indicates the trend of doing everything remotely.

Managing software upgrades
When upgrading a business application, there are three key concern areas. These include ensuring that the current customizations remain intact, ensuring that users experience minimum disruption, and resolving version conflicts. Most of the respondents said that they would upgrade to a new software version, only if it had features that were absolutely essential. Very few said that they would upgrade immediately. An overwhelming majority of the respondents test an upgrade on a standby system first, before actually rolling it out.

Software license management
This is one of the biggest challenges that organizations face today. In this, preventing the use of unauthorized software emerged as the biggest concern, with 50% of the respondents claiming it as their key challenge. This became even more interesting when we found that 50% of these respondents were already using some asset-tracking software for their organizations. The other 50% either didn't have any pre-defined policy for controlling the use of unlicensed software or strictly enforced well-defined policies for the job. Overall, around 60% of the respondents were not using any asset tracking software. A majority of the respondents were also not satisfied with their existing process for managing their software licenses. Another challenge organizations confront is determining how many software licenses are actually needed. It's a well-known fact that most
organizations purchase fewer licenses than the total number of users. This is done under the presumption that not all users would need to use the software all the time. So the licenses would be shared. Arriving at the right balance of users and licenses is, therefore, a key challenge that IT decision makers must resolve.

Anil Chopra

Page(s)   1