Strategies for Software Deployment and License Management

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