PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The reader
is available for free
download.
ARCHIVED REPORT:
Software Lifecycle Management
Copyright 2015, Faulkner Information Services. All Rights
Reserved.
Docid: 00011493
Publication Date: 1510
Publication Type: TUTORIAL
Preview
While there are distinct stages in the lifecycle of software, more thought is
typically given to the beginning stages than to the end stages of obsolescence
and end-of-life. Unfortunately, organizations frequently rely on software that
has already reached its end-of-life stage, a highly risky process. Successful software lifecycle management (also sometimes called application lifecycle management) addresses
numerous interrelated concerns including user requirements, computer hardware
requirements, business requirements, budgeting, and availability.
This report discusses the necessary steps in managing the software lifecycle and provides
guidance to organizations in overseeing the process.
Report Contents:
Executive
Summary
[return to top of
this report]
While there are distinct stages in the lifecycle of software, more thought is
typically given to the beginning stages than to the end stages of obsolescence
and end-of-life. Organizations frequently err by relying on software that has
already reached its end-of-life stage, a highly risky process.
Software, including all of a company’s operating systems and applications on
both desktops and servers, should be acquired thoughtfully, be used
intelligently, and be retired gracefully.
In order to achieve maximum value and service from software with a minimum of
downtime and disruption, IT organizations must manage their software like any
other asset. But IT organizations must first understand how software progresses
through its lifecycle in order to manage it effectively. Enterprises must ensure
that their software is neither out of date nor unfit for widespread adoption by
placing effective controls on the adoption of new software and the upgrading of
existing software to maintain employee productivity. A good plan also recognizes
that different software packages progress through the software lifecycle at
different rates.
Description
[return to top of
this report]
This process is frequently referred to as Application Lifecycle Management (ALM);
more recently, analyst firm Gartner began calling it Application Development
Lifecycle Management (ADLM). However, since ALM refers to all applications,
while ADLM indicates development only, we disagree with that name when
discussing the lifecycle of all of a company’s software. Actually, since ALM
apparently excludes such segments as operating system software, we disagree with
using the ALM moniker as well. We will continue to call this segment Software
Lifecycle Management.
A variety of paradigms can be used to trace the software lifecycle. Some have
been around much longer than the current computer age and were originally
developed to describe engineering projects. Perhaps the oldest of these is the Waterfall Model, a term coined in 1970 by W. W. Royce. This model
separates product development into five phases: Concept, definition,
development, evaluation, and operation.
A modified version of the Waterfall Model, called Phase-Gate Methodology,
soon evolved. In this model, "loops" allow for changes made along the
project’s life that require going back to a previous phase. Phases include
concept, planning, design, development, launch, and production. A definitive
characteristic of the Phase Gate model is the requirement of management approval
via a "gate review" at the end of each phase. At each review,
management decides whether to let the project pass on to the next phase, to
repeat parts of the phase, or to kill the project.
The next evolution in lifecycle modeling is known as the Comprehensive
Iterative Model. In this paradigm, a project may have one overall phase plan
yet have multiple iteration plans, so it is not as sequential as the other
models. Perhaps the best-known iterative model is the Rational Unified Process (RUP),
created by Rational Software Corp. (now part of IBM). A significant aspect of
RUP is that it is intended to be customized so that users select the processes
appropriate to each particular project, and it is generally agreed that RUP is
most suitable for large projects.
The latest popular software development strategy is Open Source Software
Development (OSSD). In OSSD, software is written by syndicates of programmers
within a loosely confederated structure. The resulting source code is freely
available and may be customized or adapted at will. Further distribution,
particularly for profit, is discouraged or even forbidden.
It should be noted that of all of these models, none takes into consideration
the fact that software becomes obsolete for a variety of market or technical
reasons and reaches a stage where it is no longer useful. Software lifecycle
was developed to address this shortcoming.
Today’s Software Lifecycle
According to a paper sponsored by Microsoft, ALM can be viewed as having
three aspects: First is the idea,
which leads to an application’s creation; this is followed by deployment,
from the time the application goes into production and throughout its use; when
the application no longer has value to a business, it has reached its end
of life, and is then removed from usage.
However, Faulkner subscribes to a more detailed view of software lifecycle,
with five components. Although individual software packages may progress at
different rates, we believe that all forms of software follow the same
lifecycle: Procurement, rollout, maintenance, obsolescence,
and end-of-life. These
phases of the software lifecycle are described in Table 1.
Table 1. The
Software Lifecycle
|
Stage
|
Steps |
|---|---|
|
Procurement |
|
|
Rollout |
|
|
Maintenance |
|
|
Obsolescence |
|
|
End-of-Life |
|
Each phase must be addressed and actively managed
to maintain an effective platform from which to deliver IT services. Failure to
manage any of these phases of the software lifecycle will inevitably lead to
chaos, confusion, wasted time, and wasted money.
Procurement. Before
incorporating any new software, it is important to determine whether that new
software package addresses an unmet need within the organization. It is just as
critical to determine whether new software operates properly with software
currently in the IT infrastructure. Evaluation can be lengthy or brief, but it
should always be performed to assess the benefits and drawbacks of adopting each
new software product.
Software evaluation can take many forms. In a
simple case, a desktop application can be purchased after it is determined that
the application’s requirements are well supported by the current operating
system. More aggressive software evaluation typically involves phased
deployment, starting with a small group of test users who will help determine
whether an application or operating system adequately meets organizational
needs. Once the initial deployment tests prove successful, more extensive
evaluation may be desired before migrating to full-scale deployment.
Generally, the acquisition of new software and
upgrades for existing software will be planned in advance based on available
budget, business requirements, and end-user requirements. Occasionally, however,
the schedule for installation and upgrades will be accelerated due to
high-priority issues such as security fixes. As security issues can arise at any
time, they need to be addressed separately and on a case-by-case basis.
Rollout. Once
a software package has been evaluated and deemed necessary for the IT
infrastructure, it undergoes a rollout process through which it is gradually
installed as appropriate throughout an organization. The rollout process can
take many forms. It can start, for example, with lengthy side-by-side testing to
prove that the new software package adequately replaces an existing system. In
this case, rollout is complete when the old system is shut down and the new
system performs all required functions.
Another option is a phased rollout, where less
critical systems are upgraded or installed first to gain confidence with the new
software. Once the new system has proven itself, more important systems are
slowly upgraded to the new software package.
In some instances, rollout is complete when all
relevant systems throughout an organization are using a single version of a
particular software package. One rollout, for instance, may focus on upgrading
all desktop operating systems to the latest version of Windows. At other times,
IT rollouts may be limited to a specific set of systems. A rollout may, for
example, focus on upgrading external Web servers, but may expressly bypass
upgrade or standardization of internal Web servers.
Maintenance. The
need for oversight does not end at the successful deployment of a new package.
Most applications undergo constant change as they are upgraded or customized to
fulfill business needs or to repair bugs. In fact, analysts estimate that 60
percent of lifetime costs associated with an IT asset derives from support and
maintenance expenses.
Obsolescence. The
set of functional requirements that a software package must address continually
grows over time. As a result, old software slowly becomes increasingly less able
to meet the needs of the organization. Users of obsolete packages also fail to
benefit from the generations of improvements that have been built into the
newer package. Moreover, chances are that old software is both difficult and
expensive to manage because IT staff focuses on current software, not old and
obsolete packages. And even if the software is still performing adequately, it
may still be rendered obsolete by an upgrade to newer equipment running an
operating system that does not support it. The rate with which software
obsolesces varies widely by software package and usage.
End-of-Life. Eventually,
software reaches a state in which it can no longer fulfill core business needs.
It was designed to meet the requirements of an earlier time or to run on older
hardware or operating systems that are being retired. Perhpas it simply has not kept up
with the growing demands of the organization. As well, after a certain length of
time, software vendors may refuse to support their old software because
the cost to maintain it is too great. Microsoft, for example, offers standard
support for just five years after a product’s release (with limited support
extendable to ten years for certain products), although online self-help support
is offered for at least ten years.
At this point, software should be retired,
upgraded, or otherwise replaced. Ideally, of course, this transition should happen long before the software reaches this state. Relying upon software that
has reached the end-of-life phase is very risky.
Another
View
IBM opines that
software
lifecycle management includes seven distinct phases that help organizations
deliver software and services faster through improved collaboration, automation,
and governance. According to that vendor, these seven phases are:
-
Change
management, also known as software change and configuration management, is
the planning, tracking, and control of project schedules and resources,
change requests, and software source versions. -
Requirements
engineering, also known as requirements management, consists of elicitation
and definition of software or systems requirements, prioritization, and
requirements management. -
Software
delivery, also known as portfolio, strategy and management, is the
prioritization, optimization, governance, and collaboration for portfolio,
demand, delivery, and performance. -
Software
deployment, also known as build and deploy, involves automation of software
development to increase software quality and facilitate collaborative
development. -
Software
design, also known as architecture and design, is the design of flexible,
scalable software based on industry standards, aligned with business and
infrastructure needs, is also referred to as just software design. -
Software
development, also known as application development, employs collaborative,
graphical, and interactive tools and components to deliver software. -
Software
quality and testing, also known as quality management and testing, is the
key behind consistency, efficiency and predictability of software quality
that meets objectives and testing for any platform and test type.
Factors Influencing Software Obsolescence
Many factors affect the rate at which a
particular piece of software becomes obsolete. These include:
Evolving Needs. Providing
a stable software foundation is complicated by the fact that most companies’
requirements for software are constantly increasing over time. Therefore, an
operating system or application that was perfectly suitable three to five years
ago may now be outdated and insufficient for meeting current needs.
Hardware Obsolescence. Although
software does not physically wear out, it is useless without a computer, and the
physical parts of computers can eventually fail for a variety of reasons. When
that happens, the company may find it is impossible (or unreasonably expensive)
to repair or replace the hardware with equivalent systems. Therefore, the
lifespan of a piece of software can be bounded by the lifespan of the computers
or computer components that are required to use it. Software becomes obsolete in
parallel with the hardware on which it runs, if indeed specific hardware
components, and not the operating system, restrict the use of the product.
Hardware often becomes obsolete quickly as products with better capacity and
capability supersede it, and manufacturers no longer offer or support it.
Software Industry. Another
key contributor to software obsolescence is the economic model that drives the
entire software industry. It is in the best interest of software publishers such
as Microsoft, SAP, Oracle, CA, and IBM to constantly release upgrades and new
versions that add features and fix existing bugs, to maintain their revenue
stream. Once a new version is released, the previous version is positioned as
obsolete.
Interoperability. Interoperability
is a particularly powerful factor that drives new software adoption and old
software obsolescence. At the core, computers are tools that assist
person-to-person communication. Most companies have an unavoidable need to share
electronic documents (and, to a lesser degree, peripheral hardware) with other
users within and outside the organization. Most crucially, a new software
package often produces files that are unreadable by the previous version of the
software. Similarly, newer operating systems that can use a wider array of
peripheral devices are generally more useful than older ones. This is a primary
motivation for companies to purchase the same program and version that everyone
else is using – even if the previous software package is still working well in
every other respect.
Opposing Factors. In
contrast to these factors that tend to speed software obsolescence, two opposing
factors work to slow the software lifecycle and keep existing software
installations viable longer. First, the IT function of a corporation is to serve
the needs of corporate users, not the software industry. Therefore, a working,
installed, and supported system is likely to remain in use as long as it can
fulfill user demands, regardless of how obsolete that system may appear. This is
true especially for server-based systems, but also for desktop systems. Second,
the hardware assets of a corporation are a long-term capital asset. Even if
hardware vendors deem a six-month-old computer to be obsolete, it may have value
within a company for anywhere from two to ten years. In many cases, software
systems need to be replaced only when the underlying hardware fails to perform
adequately.
According to software vendor Oracle, acknowledged problems include the
difficulty in managing consistency and compatibility across operating systems
and software deployments, server drifts, and security vulnerabilities that lead
to lack of compliance. Other difficulties are those in deploying and maintaining
new software, in provisioning and maintaining new servers with a variety of
configurations, and in adapting to changes in workload of the environment.
Types of Software
Software acquisitions, upgrades, and retirements
proceed differently for different types of programs. Desktop operating systems,
desktop applications, server operating systems, and server applications
obsolesce in different ways and at different rates.
Desktop Operating Systems. Two
main factors drive the operating system lifecycle. First, desktop computer
hardware undergoes continuous innovation. A particular configuration may be
available for only a few weeks before it is retired and replaced. Desktop
operating systems that are only one or two years old may not be able to support
the new hardware, or they may support it only in a reduced-function
"compatibility mode." For example, newer high-performance graphics
cards need special interface slots, and I/O interfaces like USB 2.0 are not
included in older hardware. As this process is unlikely to change anytime soon,
companies should consider upgrading their desktop operating systems every three
to five years to adequately use with the capacities provided by current
equipment.
The second main factor is the ceaseless evolution
of desktop applications toward dropping support for older versions of operating
systems. Every software vendor targeting the Microsoft platform today, for
instance, targets newer versions of Microsoft Windows, such as Windows 7, 8, or
10; older systems like Windows XP and its predecessors are no longer
supported at all. On the plus side for companies, vendors have
slowed the rate at which they replace operating systems after numerous
complaints from users that new versions were arriving too quickly for proper
evaluation, deployment, and recovery of the substantial investment required to
implement a system change.
Desktop Applications. There
is more competition among desktop applications than among operating systems, so
vendors need to constantly add new features to their products, fix bugs, and
remedy security errors. This drive for constant improvement feeds upon itself
and accelerates the drive toward obsolescence for desktop applications. In
addition, these software tools are often used to generate electronic documents
that are exchanged with other users. Previously, each time a newer version of an
application like Microsoft Office arrived, with a slightly different set of file
formats, other users had to upgrade to be able to read and work with the
documents they received from the early adopters. Customer outcry has forced an
end to the file format modifications; most Microsoft Office file formats, for
example, have been stable (and downwardly compatible) for several years.
The adoption of open standards may eliminate some
compatibility issues. OASIS (Organization for the Advancement of Structured
Information Standards) bills itself as a not-for-profit consortium that drives
the development, convergence, and adoption of open standards for the global
information society. OASIS adopted the OpenDocument Specification, v.1.2
(published as an ISO/IEC standard in June 2015), in an attempt
to define an business document standard that crosses vendor platforms to
alleviate some of these issues.
Server Operating Systems. There
is a strong disincentive to modify the server operating system once it is
installed and running, because servers help to fulfill critical,
high-availability tasks such as file sharing, e-mail delivery, Web serving,
database storage, and enterprise application hosting. Therefore, the lifecycle
for server operating systems is extended compared to that of desktop operating
systems. A five- to eight-year-old server operating system tends to be perfectly
functional in many situations, while a three- to five-year-old desktop operating
system may be obsolescing and nearing its end-of-life phase. Server hardware
tends to have a longer service life, too, thanks to a greater availability of
replacement parts and hardware upgrades.
Server operating system upgrades or replacements
tend to occur with great care and discipline. One model is not to upgrade or
replace an operating system once it is in use, but rather to upgrade the entire
server system (hardware, operating system, and applications) when necessary.
This extremely conservative stance does not apply to bug fixes or security
updates. Although such fixes are still applied with deliberate caution, they
tend to cause less disruption than a full operating system upgrade.
Server Applications. While
server operating systems provide a stable platform for delivering IT services,
the actual services themselves are usually provided by server applications. Like
desktop applications, these software products are subject to an ever-increasing
demand for new features, bug fixes, and security updates. As with server
operating systems, however, the drive to upgrade and acquire new server
applications is somewhat reduced, because of the need to provide consistent
levels of service throughout the enterprise. As a result, the lifecycle for
server applications is somewhat extended compared to that of desktop software,
but not as extended as that of the server operating system.
Other Software. Many
software tools can help standardize and automate the tasks involved in software
lifecycle management. Some vendors, such as Symantec (through its Altiris
acquisition) and HP (via its Opsware acquisition), offer suites designed
to manage most or all of the software lifecycle, for gap-free management from
acquisition to retirement. For example, HP’s product automates provisioning,
deployment, asset tracking, change management, scaling, security management,
recovery, consolidating, auditing, and reallocating; new modules add service
test management and functional testing capabilities. These suites are modular,
so a company can start with just one or two pieces and add other modules as
needed.
Similarly, products such as CA Unicenter and IBM Tivoli include many
lifecycle management functions in their management suites as well as plug-in
applications from partner software publishers.
Other vendors offer point solutions that focus on discrete stages or tasks in
the lifecycle. A company may choose one of these point solutions if it offers
needed capabilities not found in a suite. Also, if a company already has
functioning software that handles some of the tasks of lifecycle management, it
may choose point solutions just to fill in the gaps, as long as the various
solutions will be able to be integrated.
Procurement
The first stage in the software lifecycle is procurement. An automated
procurement process that is linked to a detailed asset repository can cut costs
and support better budgeting, forecasting, and purchasing decisions at this
stage. Procurement software can also streamline the purchasing process with
electronic reviews and approvals, automated checking of budgets and items in
stock, and a searchable catalog of items that comply with corporate standards.
Tying assets to the contracts that cover them also helps a company to identify
vendor accounting errors; checking serial numbers ensures that the same asset is
not paid for twice.
Asset Tracking
An important component of successful software lifecycle management is
disciplined asset tracking, the creation and maintenance of a comprehensive
asset repository that integrates physical and financial details about each IT
asset with purchasing, support, general ledger, and other data throughout the
company. This information improves decision-making at every stage in a product’s
lifecycle.
Many asset management packages provide auto-discovery tools that streamline
the creation of the asset repository by automatically scanning networked devices
for asset information. Many also include capabilities for application metering,
which tracks software usage in order to identify dormant assets that accrue
costs without providing benefits. Installed programs that are not being used can
then be removed and transferred to where they are needed.
Procedures should be established to track all installs, moves, adds, and
changes (IMAC), to ensure that the asset repository remains accurate and up to
date. Each change can have multiple effects. When a software asset is retired,
for instance, any associated licenses or maintenance contracts must also be
terminated or reassigned.
Deployment
The actual deployment of new or upgraded software can be difficult and
time-consuming. Several vendors offer tools to automate software deployment and
make it quicker and more reliable.
Repackaging. Software
applications that use the Windows Installer format can be easier to manage, due
to Windows Installer features such as auto-repair, install-on-demand, rollback,
and clean uninstallation. In order to take advantage of such features, a company
can migrate its legacy and custom software installations to Windows Installer.
Flexera Software’s InstallShield, the industry standard for Windows Installer
installations, automates this repackaging by monitoring and capturing all the
files, shortcuts, and registry entries that are added, modified, or removed by
an installation.
Conflict Management. Prior
to actual deployment, some lifecycle management systems allow a company to test
a software package for conflicts against the other installed applications and
operating systems; to verify that all its file extensions, shortcuts, and other
installation features are configured correctly; and even to do a test
installation. With InstallShield, for example, an application can be isolated to
protect it from component versioning conflicts caused by the installation and
maintenance of other applications on the system.
Auto Deployment. Installing
software and making changes manually is not only hugely time-consuming, but also
prone to inconsistency and human error. To remedy this, some packages automate
software deployment by providing answer scripts that can be chained together to
create one-touch installation procedures to run after-hours, distributing
software through the company’s intranet. With some systems, the manager only
defines the change that should take place, and the system itself actually builds
the environment and drives the changes. Each build or change is thus made from
the same set of information, improving accuracy and consistency. Another
product, Microsoft’s Active Directory, offers features that allow administrators
to silently push applications to users and can also place an icon on their
desktop that allows them to pull the application should they need it.
Contract Management
Effective management of IT-related contracts such as software licenses,
warranties, maintenance agreements, leases, subscriptions, and insurance can
significantly reduce the lifetime TCO of each software asset. An accurate count
of installed software allows a company to avoid over-purchasing licenses and
maintenance contracts, and to negotiate volume discounts. Some systems track
software usage and identify installed applications that are not being used, so
that a company can remove them and avoid needless license and maintenance costs.
Change Management
Throughout its lifecycle, most software undergoes several changes, including
upgrades, customization, security patches, bug fixes, and finally retirement. IT
change management software helps a company to analyze what to change, when and
how to change it, and what risks, costs, and potential obstacles may accompany
the project. Such software can also help manage the process of change through
task sequencing, automated approval processing, and remote software deployment.
An audit trail can be used for security, accountability, problem trend analysis,
and rolling back changes to restore an earlier configuration.
Help Desk Automation
Help desk automation software, integrated with asset management software, can
significantly reduce management and support costs throughout a product’s
lifecycle. Support agents can use it speed problem resolutions by accessing
accurate information about each caller’s system configuration, and end users can
access its self-help knowledge base for convenient, accessible support. Many
systems allow agents to remotely manage user machines, which can greatly reduce
the time and cost of tasks such as asset discovery, troubleshooting, end-user
support, virus protection updates, network management, and software deployments
and upgrades.
Information from the help desk system concerning support and work order
history can, in turn, improve procurement, training, and TCO analysis – for
example, by identifying those assets that cause a disproportionate share of
trouble tickets and service requests.
Current
View
[return to top of
this report]
Today’s Terminology
Those beginning their ALM education will no doubt encounter unfamiliar
terminology. One word frequently encountered is Agile,
usually referring to software development. The term was coined in 2001 when a
group of software developers published the "Manifesto for Agile Software
Development" to define Agile software development. Some of the manifesto’s
authors formed the Agile Alliance, a nonprofit organization that promotes
software development according to the manifesto’s principles. The Alliance
defines itself as a nonprofit organization with global membership, committed to
advancing Agile development principles and practices. The Manifesto itself is
rather simple: "We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools; working software over
comprehensive documentation; customer collaboration over contract negotiation;
and responding to change over following a plan." Analysts agree that the
move to agile is a key driver for ALM.
Another term commonly occurring in ALM discussions is Scrum.
Although sometimes written in all caps as though it were an acronym, the term
originated with a rugby reference. In that game, a scrum is the act of
restarting the game after a minor infraction. In software development, Scrum is
a method of the management of software development projects.
Several organizations are promoting Scrum. Scrum Inc. is a provider of Scrum
training, assessments, consulting, and coaching. Scrum.org offers tools and
resources for Scrum practitioners. The Scrum Alliance was formed several years
ago, and it defines Scrum as "an agile framework for completing complex
projects." Describing itself as "a not-for-profit professional
membership organization created to share the Scrum framework and transform the
world of work," the Scrum Alliance states its mission as: "To increase
awareness and understanding of Scrum, provide resources to individuals and
organizations using Scrum, and promote the iterative improvement necessary to
succeed with Scrum." The Alliance hosts Scrum Gatherings and supports Scrum
User Groups, "providing a forum for interactive learning throughout the
world." It provides complete explanations of the Scrum framework on its Web
site. In September 2014, the Alliance announced the release, along with scrum.org and
Scrum, Inc., of another community Web site, ScrumGuides.org, which offers
"The Scrum Guide, The Definitive Guide to Scrum: The Rules of the
Game."
Outlook
[return to top of
this report]
Analysts agree that the ALM market is growing dynamically, with a current
market size of US$4 billion and an annual growth rate of about 8 percent.
Software lifecycle management can be handled in several ways, through
standalone tools or through existing management products. Integration with
products used daily is by far the safer option. They can silently handle tasks
like monitoring software changes on systems and counting licenses without
special attention from already overburdened administrators. Such capabilities
will become more and more common in management suites of all sizes.
Given the software industry’s increasing emphasis on licensing compliance
(and on litigation and financial penalties for the non-compliant), as well as
the cost of acquiring licenses, tight management of a company’s software assets
is a must. Products that can efficiently and cost-effectively assume that
functionality have a strong future in the enterprise, and even smaller companies
will profit from them, if they are affordable. Software asset management as a
service is also a growing industry, with vendors monitoring remotely via the
Internet.
According to analyst firm Forrester Research, the foreseeable future will see
increased interest in the following software lifecycle management areas:
- Licensing. Organizations
need to determine who owns their code, in order to avoid unintentional
infringement. - Delivery. As
Forrester put it, "The need to deliver business capabilities at great
speed is the reality. As software becomes increasingly important to the
overall value of the business, it moves from supporting the processes to
becoming the processes." - Security. The
Ponemon Institute, a privacy and information management research firm,
conducts annual studies on the cost of a data breach in the US. The results
indicate that data breach incidents cost US companies over $200 per
compromised customer record, with the numbers rising annually.
Recommendations
[return to top of
this report]
The goal of software lifecycle management is to reduce the amount of time,
effort, and money needed to support an IT infrastructure, while providing
maximum utility for minimum cost. An effective strategy for software lifecycle
management supports highly available services while minimizing service
disruption attributable to adding, upgrading, or retiring software packages.
Establish Solution Acquisition Procedures. The
first task of software lifecycle management is to create and enforce procedures
for procuring and testing the software. These should include:
- Determining a valid business need.
- Developing a solution set.
- Adopting software evaluation and testing strategies to determine
suitability for task and interoperability with the existing IT
infrastructure. - Conducting extended parallel testing for critical services, especially
server operating systems and server applications. - Establishing deployment strategies for both new software and software
upgrades. Typically, this will begin with a limited rollout using a small
group of test users, and continue with a phased rollout as appropriate
throughout the rest of the organization.
Standardize Software Configurations. By
limiting the number of desktop operating systems, desktop applications, server
operating systems, and server applications, and by enforcing standard
configurations of installed products, an IT staff can spend less time supporting
a large number of exponentially complex configurations, and focus instead on
providing key services on a common set of base platforms. Once all users are
using effectively interchangeable desktops, management of those assets is
significantly easier than management of one individualized configuration for
each employee.
Create and Maintain an Asset Repository. Integrate
physical and financial details about each IT asset with purchasing, support,
general ledger, and other data throughout the company to improve decision-making
at every stage in a product’s lifecycle. Update the repository when the asset is
maintained, upgraded, reallocated, or retired. This repository can be manual
(though it’s an expensive, time-consuming and error-prone method), through
software installed in-house, or via a service provider.
Use Remote Deployment and Management. After
platforms have been standardized, the next key technique is to use remote
management capabilities. In the case of Microsoft Windows, this involves a
product like the Microsoft System Center Configuration Manager (now in version
2012). This product greatly simplifies the task of supporting dozens, hundreds,
or thousands of different computers throughout a network. It can be used to
upgrade, configure, and deploy software easily, and it can maintain several
different standard configuration profiles. Remote management products with
similar capabilities are also available for non-Windows-based server computers,
particularly those that are running Linux, Solaris, or another UNIX-based
operating system.
Patch management is as critical as management of the initial deployment.
Installed patches must be tracked to aid in troubleshooting, and new patches
tested and distributed to vulnerable systems in a methodical and timely manner
to ensure that they are protected from viruses, worms and other malware. With
the number of new threats increasing daily, patching is no longer an option; it
is a necessity.
Retire, Upgrade, or Replace Obsolete Software. Monitor
vendor support policies, hardware availability, interoperability issues, total
cost of ownership (TCO), and evolving business needs to determine when software
is obsolete. Reliance upon software that has reached the end-of-life phase is
very risky. Software should be retired, upgraded, or replaced before it can no
longer fulfill core business needs or is no longer supported.
HP offers the following questions to clients of its Application
Lifecycle Management (ALM) solution to help them with purchasing decisions:
- Does the application provide the functionality needed to meet business
requirements? - Does the application function with sufficient performance to meet business
requirements? - Does the application deliver adequate security to meet business
requirements?
If the answers to all three questions is "yes,"
organizations can proceed with confidence.
Web
Links
[return to top of
this report]
Agile Alliance: http://www.agilealliance.org/
CA Technologies: http://www.ca.com/
Flexera Software: http://www.flexerasoftware.com/
HP: http://www.hp.com/
IBM: http://www.ibm.com/
Microsoft: http://www.microsoft.com/
OASIS: http://www.oasis-open.org/
Oracle: http://www.oracle.com/
Ponemon: http://www.ponemon.org/
Scrum Alliance: http://www.scrumalliance.org/
ScrumGuides.org: http://www.scrumguides.org
Scrum, Inc.: http://www.scruminc.com
Scrum.org: http://www.scrum.org
Symantec: http://www.symantec.com/
About the Author
[return to top of
this report]
Rochelle Shaw is a Web
designer and freelance author who has been tracking high technology for over 30 years
as a writer, editor, and industry analyst. She is a frequent contributor to
Faulkner Information Services.
[return to top of
this report]