Legacy systems contain thousands of service components that perform an array of business functions. For instance, let's say a set of components in an on-premise legacy system your organization is running delivers a statistics report to an executive. In order to get this weekly report by her deadline, the executive should consider migrating the necessary components to a new Software as a Service (SaaS) app.
If an economic feasibility study indicates this migration would be a smart decision, she should collaborate with other executives and a team of developers, system engineers, and business analysts to break the legacy system into components before working on the app.
1: Identify legacy system assets
The development team, the executive, and the legacy system owner need to identify the legacy system's assets. The assets include:
- Documentation, including legacy system descriptions and flowcharts, and a disaster recovery plan;
- The facility where the company's internal data center is located;
- Stakeholders associated with the legacy system; these include current users (including executives), developers, system administrators, and business analysts;
- IT infrastructure on which the legacy system runs; and
- Developers' tech skills, such as developing a SaaS app on a Platform as a Service (PaaS), allows developers to share their skills virtually.
2: Discover the necessary components and their dependencies
A developer should scan the source code for service components for later extraction. The source code includes the main program and its interfaces with subroutines, which may be written in a programming language that's different from the main program's language.
The next step is for the developer to identify dependencies among the components in the main program and its subroutines. A service component's dependency can have many-to-many relationships with the dependencies of other service components.
During the process of identifying the components, the developer should also create a flowchart to help him visualize how service components are dependent on one another.
3: Extract the components
The developer should determine which components should be extracted from the legacy system. The ease of extracting service components depends on five factors:
- how well the source code was written from the start;
- how often the source code has been patched and re-patched to fix bugs;
- whether the legacy system's documentation has been periodically updated;
- the developer's tech skills (e.g., the legacy system's original developers may no longer be available); and
- the complexity of the service components' dependencies.
4: Accept or reject the extracted components
Once the developer untangles the dependencies, he can accept or reject them. Accepting dependencies do not always equate to accepting a service component as is. The developer may need to restructure the service component to meet new business requirements. Combining dependencies might result in fewer service components by eliminating duplicate or similar service functions. The developer puts all accepted service components in a repository to use when creating the SaaS app.
Creating and installing the SaaS app
When creating the SaaS app on the PaaS, developers should determine:
- what the user, developers, sys admins, and business analysts expect from the SaaS app, and then choose the type of cloud deployment the SaaS app should run on: private, public, or hybrid.
- what accepted service components to use in creating the app based on the expectations from users, developers, systems developers, and business analysts.
- the most cost-effective way of orchestrating the service components into a loosely-coupled (i.e., the app can wait for a response from a user while the rest of the app continues to operate) SaaS app, and test if the app results meets the expectations.
After installing the app, developers should monitor the SaaS app's performance and any changes in business requirements that may require updating and restructuring the app's service components.
- Software as a service: SaaS Cheat Sheet (ZDNet/TechRepublic special feature)
- Ebook: Executive's Guide to Best Practices in SaaS and the Cloud
- 10 reasons why legacy apps are doomed
- Speaking out in support of legacy systems and solutions (ZDNet)
- Ebook: SaaS and the cloud — A primer for IT pros (Tech Pro Research)
Disclaimer: TechRepublic, ZDNet, and Tech Pro Research are CBS Interactive properties.
Judith M. Myerson is a Systems Engineering Consultant and Security Professional. She is the editor of Enterprise System Integration and the author of RFID in the Supply Chain. She has researched and published articles on a wide range of cloud computing topics, RFID, security, networking, and mobile. She was awarded a Master of Science degree in Engineering (Computer and Information Sciences). President of a toastmasters group, Judith was awarded her Advanced Communications Gold certificate. She is a member of The Operational Security Professional Association.