EA is probably one of the most critical areas of the technology domain and it is also likely to be the least understood. More often than not, the purpose of EA is to design replacements for old legacy systems.
At the time, in operations, we were receiving solutions that were well designed on paper, proven in development, proven in test environments, but then implemented differently from the tested design. This resulted in production problems, which required emergency changes in order to make the new solution operational.
A number of reasons caused the deviation from the original design:
• The existing system landscape was not well documented and consequently not well understood.
• Development and test systems didn’t match the production environment. This was due to a lack of good documentation.
• Migration to the new solution, mainly from legacy environments, was not well planned and subsequently being badly executed
• Not all stakeholders were properly consulted or involved in the design and build of the new system. As a consequence, the design was not fully fit for purpose.
A lot of the problems could have been avoided if the existing systems were well documented and well understood. This is an issue almost every organisation faces.
The technology landscape in most businesses is littered with ageing legacy systems doing a respectable job. In one organisation where I worked there were five billing systems all doing very similar tasks and producing similar output. This was the result of five separate businesses being acquired over a short period of time. The company commissioned a project to replace all five billing systems with a new single billing platform.
Until we start to embrace the need for continuous incremental change, we’ll be forever stuck in the vicious cycle of big bang projects designed to rid us of legacy systems that cannot be easily replaced without a change in the technology landscape.
Some of the problems described above – stakeholders being left out, lack of good migration planning, lack of documentation, and so on – made sure the project did not go well. Instead of replacing five systems with one, a new sixth system emerged, sitting alongside the other five. It took a further two years to migrate all five to the new sixth system, at a significant cost to the business.
Read more: Leadership is demonstrated, not measured
As time passes by, documentation, knowledge, the critical intellectual property gets lost or leaves the organisation. Additionally, legacy systems live under the spectre of other potential issues. These can range from:
• Vendors not supporting older codebases
• Vendors no longer in business
• Systems where source code has been lost or the original developers no longer in the organisation
Read more: Confessions of a 'recovery professional'
• Capacity issues that cannot be resolved by hardware upgrades
• Other age or time related problems.
EA attempts to solve a very complex problem that isn’t well understood or properly defined. From a legacy environment perspective the issue is clear:
How do we get from something that was once fit for purpose to something that needs to scale, evolve and be easily upgraded with little or no disruption to the existing systems and processes?
With today’s focus on scalability, standards, and security, legacy systems don’t meet current expectations. The legacy environment could be historically classified as a well-planned town, but now, with the passage of time and more importantly progress, it starts to resemble a slum or shanty town.
Next: EA and the building analogy
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.