(Original creator: bolarotibi)
Guest contributor, Paul Herzlich from analyst firm Creative Intellect Consulting (Part 1) Although discussions of modernization often center on a world of technically dazzling possibilities, the reality for many organizations is much less exciting. Long before they consider their ambitions to be state-of-the-art, they have to confront the fact that their applications are probably lacking or are even incompatible with only moderately recent technologies that would allow them to participate in the interconnected world of composite applications, like object orientation, SOA, web services and XML. Forget about whether they can make use of the latest shiny technological tricks. They realize that living outside the technological mainstream is costing them in a whole host of ways:
- They’re at risk while they depend on obsolete hardware and unsupported system software, databases, and middleware.
- They maintain separate development tools for software development with a raft of side effects: separate licenses and less capable, less integrated and less productive tools than those available for mainstream languages.
- They and their IT service partners find it difficult to recruit staff; legacy languages and platforms require niche skills that lack pulling power for new recruits.
For many managers, the straightforward solution to modernization is to rewrite applications in a trendy language on modern platform or to replace them with a packaged application. Rewriting or replacement are both valid but can be expensive and highly risky options. There are incremental alternatives. A typical stepping-stone to modernization involves wrapping existing core business systems in modern interfaces and treating the legacy systems as if they were a black box. You write an interface that transforms data and commands between new and old technologies. The black box modernization strategy is popular but has architectural limitations and negative side effects on IT processes.
- The distribution of logic across front and back ends is not optimal; often business logic has to be duplicated. Once it is duplicated, you have duplicate maintenance and a new risk of errors when new and old logic mistakenly diverge.
- The timing of back-end processes – many of which are batch – doesn’t match the interactive nature of the modernized front-end. The black box implementation may appear awkward or incomplete.
- Without extensive back-end changes, you are still largely limited to data catered for in your back-end data model.
- It places extra burdens (which mean costs) on IT processes. You multiply the development and test environments, skillsets and tools required.
- Although in theory you keep your core applications, often they still require modification. For example, if you add mobile access, you may need to extend your legacy system to cater for new locational data. All this adds complexity, effort and risk to coding, integration and testing.
This page has no comments.