Do software upgrades have to replace the previous version? This is a fairly destructive approach, particularly when new code contains new bugs! A more lightweight upgrade mechanism is possible based on end user roles. Stephen Morris explains how to upgrade only the parts of an application you need in an effort to reduce the risk and the seemingly inevitable disruption caused by a full replacement.

Like this article? We recommend

Like this article? We recommend

The advent of inversion of control (IoC) in frameworks such as Spring is a
powerful indicator of the future of direction of computing.

Basically, IoC allows you to write software so that you can modify it without
making code changes. Instead, you can modify external XML files to change the
way the code works. In Spring parlance, you can modify the wiring of code via
XML.

Spring provides internal mechanisms to achieve this using aspect-oriented
programming and other techniques at the cutting edge of software evolution. In
this article, I look at a different area—that of code upgrades.

I often think software upgrades are invasive and blunt instruments. Bad
upgrades can have a bad effect on productivity. I occasionally see this when one
of my scheduled antivirus software updates chokes on scanning one of my local
files. The next update generally doesn’t choke; i.e., the bug is quietly
fixed in the interim!

I recently upgraded my browser application. When I couldn’t get it to
work, I then had to revert to the old version, suffering a grumpiness-inducing
machine crash along the way.

Is it really necessary to upgrade an entire application? Why not just upgrade
the parts you need in an effort to reduce the risk and the seemingly inevitable
disruption?

Is it even possible to perform a partial on-demand application upgrade? Can
we put the "soft" back in software?

In this article, I present a mechanism for what I call targeted client
upgrades. The upgrade code targets the needs of a specific client user
instead of merely facilitating the IT department or the vendor upgrade
schedule.

On-demand upgrades fit into a broader category of software deployment that is
increasingly referred to as rules-based IT. Rules-based IT seeks to
allow the definition of business-driven rules for consuming IT services.

In other words, the IT rules facilitate the needs of the business and help
its users to do their jobs more effectively.

Traditionally, IT services are rolled out and maintained on an
enterprise-wide basis. This is the model used for Windows updates and antivirus
data file renewal. It’s a clunky mechanism.

To illustrate a typical example, let’s imagine that I’m an HR
director and I need software features X, Y, and Z in a given application. The IT
folks roll out the software with my required features.

The features concern manipulation of private information, and hence are
password-protected so that only I can use them. In other words, everyone gets
the code, but only I can use it.

Wouldn’t it be nicer if I could get the new software features with only
a minimal upgrade? Or, better still, only my code gets the upgrade. Everyone
else is unaffected and unaware of the upgrade.

What I’m looking for here is a more flexible, lower-cost upgrade
mechanism. How might you go about creating such an upgrade?

A Staff Management System

For my application domain, I’m going to stick with the idea of an HR
application that stores and maintains staff records. Many organizations allow
all staff to at least view a portion of such data, while permitting only a
select few to make modifications.

I occasionally wonder at the way some senior IT staff can view confidential
data, purely because they administer the HR systems. I remember one company I
worked in where a relatively junior IT staffer remarked to me with pride that he
knew what everyone’s salary was!

Figure 1 illustrates an application in which user privileges are role-based.
What this typically means is that users are grouped by privilege levels.