SUMMARY FOLLOWING STAGES ONE AND TWO
There are companies that will have reaped the benefits they are prepared to invest in as early as stage one. Those companies simply have legacy applications that need modernizing to ease their maintenance, and there is currently no desire to do more than that. Some of those companies may even have outsourced their legacy applications to firms that specialize in managing application maintenance. This may even be done to relieve the owning company from the maintenance burden while new systems, either purchased or developed, are being put in place. When companies choose to outsource their applications’ maintenance, it is often with a contractual requirement to statistically prove code quality improvement as part of the contract. For an outsourcing company, this means stage one is a minimum requirement for contract success. Whatever the reason, as I pointed out earlier, the companies that achieve stage one can stop there and reap the full benefits of that stage.
If, in the future, companies that stopped at stage one decide to move on and restructure their business logic for reuse, they can resume following the stages detailed here. And, even without accomplishing stage two, COBOL programming code cleaned to consistently follow enterprise COBOL rules can be migrated to new technologies such as .NET by compiling with specialized COBOL compilers created for that purpose.
For those who have accomplished stage two, it is now possible to move on to stage three, or, transformation. Transformation enables migration to new platforms, and often includes translation to new programming languages (see Figure 2).
STAGE THREE: TRANSFORM RESTRUCTURED PROGRAMS
If stages one and two have been followed correctly, and stage two has resulted in “well-behaved” components, those components can now be reused. They can be accessed in their original coding language through standard Application Programming Interfaces (APIs), or from different languages and/or environments through specialized interfaces, or even translated from legacy application languages such as COBOL (or Natural, PL/1, or FORTRAN) to newer object-based languages such as Java. This is where defining components correctly in stage two will lead to successful translation even when the new language follows a much different paradigm. Although I have not defined the rules for defining “well-behaved” components here, I would recommend that you become educated about successful methodologies to follow and, if you are new to this arena, contract for the services of expert consultants to assist in the first few application restructuring projects.
GENERATING NEW INTERFACES
If there is not a migration requirement and the original technology will continue, we can make component services available within almost any architecture. We can generate multiple, specialized interfaces such as:
- Interface Definition Language (IDL) for Common Object Request Broker Architecture (CORBA) access
- Web services-enabled by Simple Object Adaptor Protocol (SOAP), which consist of: XML, described by Web Services Description Language (WSDL), and discovered for reuse via Universal Description, Discovery, and Integration (UDDI). This provides a standard way to publish and discover Web services using XML, or as a Common Object Model (COM/ DCOM) object directly accessible through Microsoft’s object management technologies
- As a COM/DCOM object directly accessible through Microsoft’s object management technologies.
The list of ways to access reusable business logic could, of course, continue. The key is that correct execution of stages one and two leads to many alternatives that are faster to implement in stage three.