Targeted Client Upgrades: Creating a Flexible, Low-cost Application Upgrade Mechanism
- Feb 15, 2008
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.
Clearly, this type of upgrade mechanism carries a significant risk, which got me thinking...
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.
The privilege level dictates the allowed access; e.g., certain menu options may be unavailable for users below a specific privilege level.
The role in Figure 1 could be implemented using a password scheme, by group membership, or tying in with some platform-specific mechanism.
)
Figure 1 HR application data accessed by role
The users on the left of Figure 1 can view all data and make changes, whereas those on the right can view only their own specific data.
Figure 2 illustrates an example view for the privileged users.
)
Figure 2 Privileged HR application data view
Figure 2 illustrates access to salary data. It might be argued that Social Security numbers are also private, but for the purposes of this article, let’s assume they’re not.
Moving on, Figure 3 illustrates an example view for the non-privileged users. It’s likely that the view in Figure 3 would be even more restrictive, just allowing a given user to view his/her own data.
)
Figure 3 Non-privileged HR application data view
