by July 16, 2006 0 comments

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.

Research Methodology
To work out a well-rounded
view on how to deploy and manage software in an organization, it’s
important to understand the issues first. For that, we spoke to key IT
decision makers across 12 different organizations to get their views on
s/w deployment and license management, and understand how they are doing
it. For this, we divided our questionnaire into four parts. The first one
aimed at understanding the issues in deploying a new large software. The
second part aimed at understanding issues in doing major software
rollouts. Next, we asked the key issues in doing software upgrades and
migration. Lastly, we asked how they managed and monitored software

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.

View Point
Vivek Dharia, CIO, KNP Sec
How do you determine the
actual number of software licenses needed in your organization?

It depends on how many units have been purchased, deployed and are
available. It also depends on how much we save on software licensing
considering the ROI & retirement of software.

How do you resolve the problem of
integrating a large software with your existing applications?

Configuring and integrating existing software and hardware with a database
to work with new software requires diagnostic tracing capabilities. The
major problem while doing integration is that usually there exists an
inherent heterogeneity of system platforms and software applications
within the same enterprise and among collaborative partners.

What kind of support do you expect
from your top management once the initial hurdle of convincing them to
purchase a new software is over and you’re in the deployment phase?

Top-management’s leadership, involvement and support in implementation
is critical to success. The support calls for communication and
cooperation to determine and report the progress towards meeting the
requirements with technical reviews.

What would you like to do to improve
your software license mgmt process? What are the key challenges you’d like
to overcome and how?

We have to find the developers’ needs for flexible licensing, secure
protection and ease of use in development, deployment and administration.
The challenge here is that it should be a cost effective process that
makes use of existing tools to the maximum.

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
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

Anil Chopra

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.