Replacing 'rip and replace'

Comment There is a major problem with building an agile business model – agility demands the ability to change and adapt the IT systems not just rapidly, but also safely. That means being able to upgrade hardware and software resources with ease, and more importantly, without damaging IT’s primary job - running the existing business processes efficiently and reliably.

Sadly, IT folklore is littered with stories of companies brought to their knees by major upgrades that have gone horribly wrong. Then there are the stories, quite often seeming to involve major Government departments, of systems that never quite make it through to production status because it has not proved possible to keep pace with the rate at which the specification and operational demands have changed.

Mind the gap

Traditionally, the word "upgrade" has meant a time of "rip and replace" in the IT Department. As individual servers have become too slow or applications and operating systems too limited in capability users have faced the traumas associated with the replacement process. Though there is usually a period of running applications and servers in parallel to shake down obvious problems, these handovers are inevitably tricky and full of risk to the business. It is often the case that the new systems only get to handle the full workload after the handover, and it is not unknown for some companies to fall down the gap that they discover, too late, still exists between old and new environments.

Equally traditionally, the major dislocations that upgrading brings means that companies have tried hard to limit the number of times they attempt it. But if creating an agile business is the target then "upgrading" has to become an integral part of the IT department’s culture, for it will become an ongoing process. It must, therefore, become a process that is easy to manage and implement, and one that can be conducted reliably while maintaining full integrity for both the systems infrastructure and the business processes.

Developments in server platforms, and in particular hardware platforms, have now made the upgrade process a great deal easier and far less traumatic. Rack-based Blade Servers, for example, make it possible to upgrade or scale-up a server environment without any downtime to the service that is provided to users. The Blade approach has at its heart, a standardised architecture and form factor. The two leading architectures these days come from IBM and HP, both of which have opened up the design to third parties. This means that companies making specialist servers or devices can piggyback on the architecture and all its standardised interconnections and interfaces. In this way, third party products simply slot in to the rack and are automatically interfaced into the infrastructure in a managed way that does not interrupt any other operations running at the time.

Don't rip, flip

With the recent announcement by HP of a Blade Server running the company’s HP-UX flavour of Unix on Intel’s Itanium processor, users now have before them two hardware infrastructure families that can service most of the processing requirements large enterprises will require. Both now have Blade Servers ranging from single x86-based processors through to the most powerful processor lines they offer – HP with Itanium and IBM with its Power 5 Risc chips – plus a growing range of specialist servers from third parties such as communications servers from Cisco and Nortel.

This approach highlights a new trend in the process of upgrading or upscaling the hardware environment. "Rip and replace" is itself being replaced by a process of osmosis. Instead of replacing a complete system, the task can be undertaken in simple stages, a Blade at a time if necessary. Each addition or change can be tested and validated without bringing the rest of the system to a halt. The far finer granularity of growth in the infrastructure also maps more closely to the real needs of an agile business to change, adapt or add only those business processes that are required to meet business needs.

The two most important aspects of this are that these changes can be made not only rapidly and safely but also incrementally. Servers – and these days some significantly powerful ones – can be added to a rack with their arrival and integration into the infrastructure resource pool fully and safely managed.

For the agile business, this means that a single business process can be added or upgraded as an entity and in a timely fashion, rather than having to wait along with a list of other modifications, updates and upgrades until it is large enough to warrant the risks of pulling the whole system down.®