Legacy application modernization
Last Monday I was lucky enough to attend a one-day seminar near Heathrow in London organized by Arcati. It had a number of speakers, and gave a very interesting positioning of where many companies are today and where they’d like to be – and the all important guidelines describing how to get there.
It highlighted two very important points – that getting there is going to take time and effort; and, by the time you have arrived there, you’ll want to be somewhere else and the whole process will start all over again!
Dr Mike Gilbert, principal of Legacy Directions, suggested that there were three immediate problems organizations face in terms of modernization strategies. His first was the COBOL skills problem – he suggested that the average age of a COBOL programmer was 45, and few youngsters wanted to learn COBOL (or can even find places that teach it!). In ten years time, most COBOL experts will be looking to retire rather than take on a modernization challenge.
His second problem he likened to an octopus. The core legacy application was the body of the octopus and the tentacles were the peripheral systems that the application touched. While it is easy (a relative term, obviously) to do something with the tentacles, it is much harder to carry out work moving or integrating the octopus’s body.
The third problem was simply cost. What happens if the modernization project goes wrong? The cost can be enormous, and Mike gave an example of one company at which all the senior officers resigned following a project failure because of the expense suffered by the company.
Mike Gilbert then explained that we should be looking at the big picture when thinking of legacy systems. Firstly, there are people involved – not just IT, but the users who are familiar with using the applications. We should think about the processes – there are the old (original) processes and the new ones. Then we get to the applications themselves, which could be locked into particular databases etc. And finally there is the infrastructure that must be considered.
Before a modernization project can be undertaken, it’s important that the business leaders understand the need for the project in business terms and can see the benefits the business will get from the change. The business leaders must support the modernization project. The project must use the best methodologies (and in some cases the methodologies may be in their infancy). Lastly, companies must have appropriate tools for the project – again these might not exist for all modernization projects.
Mike suggested that in any modernization project, it was important to go through five stages. Stage 1 was to define the challenge. Stage 2 was to define success – that way you knew when you’d finished. Stage 3 was to plan the project. Stage 4 was to carry out the project. And Step 5 was to return to Step 1.
He suggested always starting with processes, because these were used by people. Then look at people, because they use the actual applications. Then look at the applications, which run on the infrastructure. And lastly look at infrastructure. He suggested that by scoring assets, it was possible to produce a decision table and show what changes were possible in terms of cost and risk. The final decisions should always be taken by the business leaders so they are supportive of the project.
This is just a flavour of one session at the seminar. All in all, it was a very useful day with lots of valuable information.
It highlighted two very important points – that getting there is going to take time and effort; and, by the time you have arrived there, you’ll want to be somewhere else and the whole process will start all over again!
Dr Mike Gilbert, principal of Legacy Directions, suggested that there were three immediate problems organizations face in terms of modernization strategies. His first was the COBOL skills problem – he suggested that the average age of a COBOL programmer was 45, and few youngsters wanted to learn COBOL (or can even find places that teach it!). In ten years time, most COBOL experts will be looking to retire rather than take on a modernization challenge.
His second problem he likened to an octopus. The core legacy application was the body of the octopus and the tentacles were the peripheral systems that the application touched. While it is easy (a relative term, obviously) to do something with the tentacles, it is much harder to carry out work moving or integrating the octopus’s body.
The third problem was simply cost. What happens if the modernization project goes wrong? The cost can be enormous, and Mike gave an example of one company at which all the senior officers resigned following a project failure because of the expense suffered by the company.
Mike Gilbert then explained that we should be looking at the big picture when thinking of legacy systems. Firstly, there are people involved – not just IT, but the users who are familiar with using the applications. We should think about the processes – there are the old (original) processes and the new ones. Then we get to the applications themselves, which could be locked into particular databases etc. And finally there is the infrastructure that must be considered.
Before a modernization project can be undertaken, it’s important that the business leaders understand the need for the project in business terms and can see the benefits the business will get from the change. The business leaders must support the modernization project. The project must use the best methodologies (and in some cases the methodologies may be in their infancy). Lastly, companies must have appropriate tools for the project – again these might not exist for all modernization projects.
Mike suggested that in any modernization project, it was important to go through five stages. Stage 1 was to define the challenge. Stage 2 was to define success – that way you knew when you’d finished. Stage 3 was to plan the project. Stage 4 was to carry out the project. And Step 5 was to return to Step 1.
He suggested always starting with processes, because these were used by people. Then look at people, because they use the actual applications. Then look at the applications, which run on the infrastructure. And lastly look at infrastructure. He suggested that by scoring assets, it was possible to produce a decision table and show what changes were possible in terms of cost and risk. The final decisions should always be taken by the business leaders so they are supportive of the project.
This is just a flavour of one session at the seminar. All in all, it was a very useful day with lots of valuable information.
posted by Trevor Eddolls at 4/02/2007 03:05:00 AM
Subscribe
0 Comments:
Post a Comment
<< Home