Wednesday, June 09, 2004
It is fewer than often that we get a clean slate to start with automating business processes. This brings us face to face with Legacy Systems Management. In situations this Legacy is a blessing in disguise, at time it is pure source of annoyance, but i have felt all along that an effective Management will maximize gains in these Projects neverthless it will never be a single one time event in any organizations’ life. Through this site I intend to issue a series of documents, my experiences and exposures, first and foremost, in relation to ERP Project Management.
1. The Task
“Modernization” is being in a perpetual state of responding to growing needs of time that is to say having a predominantly proactive outlook. It must avoid the telescopic view into distant future implying tunnel vision or a microscopic view with its reductionistic approach; both ending in disproportionate view of needs and resources. It should simply be a real life picture of technological needs. It is much more simple process of open and fair response in all times to all needs, growth potentials and technological advancement. Therefore change is responding to and being in perpetual visioning process. Change comes from within and not without. Yet at times legacy become dispensable, both in terms of human resource or software and hardware. How it is appropriate to dispense legacy is a tricky question below is an analytical approach to adopt “new” and dispense the “old”.
2. What is a Legacy?
Legacy systems are the information resources currently available or used in past in the organization. They include existing databases, operating systems, application programs and all other forms of hardware and software that a company may own. The prominent legacy applications on the some of the examples of legacy systems are:
1. File Systems Databases
2. Client Server Applications (especially if we intend to be proactive Client Server Technology will be considered legacy in a short while).
3. COBOL. Etc.
3. Forward Engineering Process
Forward engineering is a simple process through which systems are implemented in a fairly straightforward logical sequence, typically including analysis, design, construction, testing and maintenance phases. Forward engineering is a simple and straight forward for out of box applications, it is also the normal new systems. Yet to have a clean slate is more often thought than experienced in real life situations. It is often compromised by the existence of existing systems.
4. Reverse Engineering Process.
As a smart alternative to forward engineering, reverse engineering is an intelligent option when there is insufficient information to form a sound basis for a new system. This is results from:
o Knowledge in the legacy system may no longer be available in any other form
o No formal definition of a core business process
o Policies and procedures are non existent or irrelevant.
o Or procedures exist for no reason.
o Legacy Systems Lack basic documentation
o There is insufficient understanding of the business itself.
So Reverse engineering is a smart and intelligent option for acquiring critical knowledge of business processes from existing systems so as to specify and construct their replacements. This is not only sustainable process for meaningful change but also offers low risks. Especially if the organizational skill levels are inadequate to ascertain the modernization process; reverse engineering could be a safe and accurate option for change.
4. Incremental Modernization Processes.
“Big Bang” is not feasible even if desirable to change from a legacy to a new system in a single go. The modernization of legacy systems is usually complex, large, years long projects that pose significant financial, organizational and operational risks. Therefore, a ‘staged’ evolution from the legacy application to the new system over periodic intervals of time, ascertaining each stage, capitalizing on its gains and moving on to the next natural steps; is stable and productive approach. This would lessen the impact of the risks involved. The incremental approach reduces the percentage of introduction of ‘New Code’ into the percentage of ‘Old Code’ or Legacy Systems. This process allows to gradually increasing the ‘New’ to replace the ‘Old’.
Modernization of the legacy system is best achieved through critical guiding principles:
o End User Involvement
o Staged Developmental Approach.
o Time Management
o Predefined and Preplanned “Replacement of Systems”
o Periodic Testing.
o Empowered Smart Teams Management.
These guiding principles greatly improve the success and reduce the risks of taking the legacy system through a sustained incremental modernization project.
1. Managing Legacy and Modernization.
Software market has very aggressively responded to modernization requirements of IT industry and ushered in a series of tools which facilitate and increase the efficiency and effectiveness of systems, analysts, designers, developers and testers, which in turn benefits the enterprise.
Support for legacy environments for example old systems like COBOL is limited in terms of availability of tools; the business units that rely on older applications have genuine concerns on modernization. What organizations will need to do is mix and match tools and discover the right solution for the Migration part of ERP Project. These tools work wonders, with ability to generate code logic and provide a means to employ legacy ‘wrappers’, such as data wrappers, UI (User Interface) wrappers, and application wrappers. These wrappers encapsulate, or wrap, the legacy application and data resources.
2. Repositioning for Composite Applications.
IT staff treads on water, ever moving right under their feet, just to be the current waves they have to tread a very fine line of keeping afresh older knowledge base and acquiring new technologies. Rapid advancement and continual shifts in technology is a prize for organizations and nothing less than a nightmare for IT staff. New approaches, techniques and tools appear continually. New delivery mechanisms appear and affect current and future strategies. An end user asking for new functionality to change from old one is not just a simple request anymore. It triggers a process of integration of the organized chaos that currently exists. It seems obvious that over time the role of the application developer has changed along with the strategy of the organization. We have to accept that we should now be called ‘application integrators rather than developers’. The job today is much more about integrating the assets we have than developing new ones. Integrating to deliver a business process that works smoothly while involving legacy, ERP and new application functionality delivered via any one or more of the user-interfaces that currently exist. We will rarely, have the opportunity to start from a clean slate. There is no such thing as clean slate in IT anymore. We have to refurbish our office ‘our self’ while working out of it, so are we not refurbishers?
As we take this challenge, luckily there is a continued growth of tools in the Enterprise Application Integration (EAI) market. At the heart of our integration strategy is a ground-reality-based approach for delivering and managing business chains and it has to be reflected in the use of the assets we currently own in information technology, with the need to provide highly coordinated functionality from many diverse applications in many more diverse technologies. The best way out is to employee business modeling tools. This would allow visualizing, catalogue and managing the vital scenarios, which happens to be ideally suited for the purpose.
“New project complexities go beyond the understanding of individuals, no matter how expert they may be. Integration teams will have to employ multiple methods that will include skills from packaged implementation, new development, traditional development, component development, legacy integration and reuse. ‘Project management in this buffet-style environment will present new challenges for co-ordination and measurement’. Cross-functional teams with non-linear tasks will be complex to manage. Many diverse skills, from legacy to wireless, may need to be employed in any one implementation, and are unlikely to be possessed by a single developer. “
We have to accept the challenge and understand that it will not be a simple straight line transition from PointA to PointB because when we get to PointB we will want to go to PointC. The magic lie is controlling the fusion reaction rather than leaving it unbridled and untamed wish list of automations. The challenge is to control this fusion of chain reaction and create an environment to control a continual evolution of application portfolio making as much use of the assets we have while continually planning to enhance and replace them as new challenges occur. The shift from a straight line transition to a continued evolution will help us understand how to plan and control this new componentized, multi-disciplinary workflow model before it controls and overwhelms us. Yet the good news is that this is probably the only work where input is equal to output; ideal machine and at times even better. (Hope I am not being too optimist about our potentials)
To be continued with part B of this paper; with a step by step approach to Managment of Legacy Systems