![]() |
![]() |
There is a trend towards a convergence of support tools in this arena, although there are currently many tools that overlap in their scope.
Where companies choose deliberately to limit the amount of software installed on client workstations, they are able to reduce their support costs for both software distribution but also Problem Management because there is less to go wrong at a local level. There are several implementations of the so-called 'thin client' available, but they all follow the same principle of loading software dynamically over a network rather than storing it on each client workstation. This approach reduces the number of locations for the software to a few servers within an organisation, thus greatly reducing the overhead of distributing Changes to applications.
Some implementations of the 'thin client' require no modifiable software to be installed locally at all, and rely upon a control program in the firmware of the workstation to connect to the network and download the applications. This approach has the least administration overhead. Other methods depend on a locally installed operating system and the use of emulation software to run a remote session on the server. This approach, therefore, requires the management of the locally installed systems software.
A growing number of systems consist of software that runs on more than one hardware platform. A common model is to make use of middle-tier application servers that issue requests for data on back-end database systems.
Figure 9.10 - Example of a multi-tier configuration
In Figure 9.10, several workstations are connected to a middle-tier application server, which accesses data on two different back-end database systems. In this example, it is quite possible that application software needs to be deployed on all three tiers: workstation, application server and database server.
Release Management should ensure that Changes to the application as a whole are coordinated across all of these platforms, along with any requisite hardware changes.
A variation on the multi-tier model is often used to provide Internet access to an organisation's systems alongside existing internal Users with normal workstations running Graphical User Interface (GUI) versions of the same or similar applications. A common model is to deploy a web server connected to the Internet for Users with web browsers. This would normally be connected via a firewall to prevent unauthorised access to the rest of the organisation's internal network.
Figure 9.11 - Example configuration for web access
Figure 9.11 adds some further areas that need to be controlled, in addition to those in the multi-tier model:
It can be seen, therefore, that Release Management has an increased role to play to ensure that all components of an IT service are changed in a coordinated manner with an Internet application. One challenge is that different parts of the IT department (or even some Users themselves) may need to be involved in this type of application, such as the networks team for the connections and firewall; the Web Master for the web server; the server team for the application server; and mid-range or mainframe teams for the back-end database systems. It is the role of Release Management to help bring all of these activities together smoothly.
It is becoming increasingly common for commercial software vendors to provide fixes and upgrades to their software available for downloading on the Internet. There are also huge numbers of complete applications that can simply be downloaded and installed.
It should be noted that, although the prospect of self-maintaining applications sounds attractive, there are dangers:
In summary this practice should only normally be used by support staff on controlled test equipment, as part of the construction of a subsequent official Release. It should be strongly discouraged for use on live workstations.
![]() |
![]() |