Geeks With Blogs

News Dave's Mug View David Oliver's profile on LinkedIn Add to Technorati Favorites Blog Directory for Guildford, Surrey
Dave Oliver's Blog Enterprise Technology Thought Leadership in a FTSE 100

In this post I’m going to discuss a possible solution to a common problem and that is how do to initiate a renewal process to replace an old system without initating one of the existing major change drivers.

System renewal and end of life are the life blood of I.T. Our whole business thrives on change. But change is costly, time consuming, complex, problematic and uncomfortable. It’s one of mankind’s ultimate ironies, we are good at adapting to change but we don’t like it.

So the change drivers for a system are most commonly,

1) Change in business requirement
2) A technical reason

The main problem with these change drivers is time. Here are some for instances;

Business requirement change needs to cater for it in a timely fashion to take full advantage of a market change.

A fundamental piece of the puzzle, either hardware or software has gone wrong and a solution is sort expediently as the business is no doubt suffering without it.

As you can see the main change drivers are in the short term and give little warning not allowing much of an opportunity to plan and budget.

It is a pretty much well known fact that we dislike short term change, frankly it is a pain in the arse.

Pushing as much out to the medium and long terms allows you more time to plan but the common change drivers will always be there so the challenge is to minimise the impact of them by using time as a change driver.

My idea is to place a ‘used by’ date on to the different parts of a system, this in effect will then become a change driver. Categorise the impact of change on that part (which can simply be ‘major’ or ‘minor’ for instance) and place a date for review and the initiation of it’s replacement before the ‘used by’ date into the Service Level Agreement (SLA) as part of the design stage of the system or after major review so the businesses expectations are managed.

We understand the ‘used by’ date on our food products, we understand that there is greater risk involved in eating meat or drinking milk after this date so adding this to our systems will in effect do the same thing.

Having a used by date allows you to have items on your budget instead of a blank piece of paper at the start of a budget round. It allows you to have a longer term view so you can manage resource over a great period of time.

So how do we establish a ‘used by’ date? The most obvious way is for the ‘used by’ date to mirror the products support end date. Other generators of ‘user by’ dates are dependencies on other systems or processes, or when it has served its purposes such as a projects-end.
Having many ‘used by’ dates in a system gives visibility to the fact that a system is made of many constituent parts working together so the dependency between them is understood. Parts can be replaced but categorising the part manages the expectation of the work involved to replace it.

The temptation is to just have one ‘used by’ date which can be the earliest major ‘used by’ date in the system as it simplifies the understanding. The problem here is that you could prematurely be shortening the life of the system. It could be after all easier, cheaper and les complex to affect a major change than replace the whole thing. The ‘used by’ date system can be used as means to maximise the life of a system.

Like all things systems have a life, accepting this fact allows you to cater and manage its renewal. The ‘used by’ date is an easy to understand tool to help you initiate this process.

Posted on Saturday, July 29, 2006 10:20 AM Main | Back to top


Comments on this post: One of the most important parts of life is understanding when it's going to end.

# re: One of the most important parts of life is understanding when it's going to end.
Requesting Gravatar...
Dear Dave,
The useby date seems like a great concept, but today when I look in my IT fridge I see an awful lot of green gunk in the bottom. There will always be legacy systems in many organisations for a number of reasons, for example,
- the system still does it's job quite well and there is no need to change.
- the system is doing a job and will be changed as part of an ongoing maintenance phase - maybe because this makes business sense or maybe it's just to costly or complex to rewrite.
Older technologies may have their shortcomings and may not be flavour of the month, but however unpopular they are the systems that were constructed with them are likely to live on unless there is a really strong case to make a change - like the security is as open as a barn door - but only if we can convince the guys with the pointy hair [go see dilbert.com if you don't get this one].
The shelf life of a system is a neat concept, but will it actually change things in most organisations? I wish you luck in promoting the concept.
Left by Felix on Aug 04, 2006 8:04 AM

# re: One of the most important parts of life is understanding when it's going to end.
Requesting Gravatar...
Left by Mental Health on Nov 24, 2006 8:24 PM

Comments have been closed on this topic.
Copyright © Dave Oliver | Powered by: GeeksWithBlogs.net