database models and legacy systems
The sheer thought of a company just updating a system makes many cringe; I mean it might actually run more efficient, even secure the data and it might even allow the users to utilize the system outside the office (mobility) Yes! This is being facetious. All joking aside, many of these legacy systems are still in practice because they are still functional.
One phrase to keep in mind would be “if it ain't broke, don't fix it!" (Legacy, N.d.). If the “system is complex, and documentation is poor or simply trying to define the scope can be difficult and redesigning could be very expensive, due to complexity or monolithic architecture (Legacy, N.d.)”. These are just a few reasons one might still be using a legacy system. However, there are many risks with this logic.
Although there are many risks in keeping legacy systems in place, many organizations may not realize “it is not as difficult as it used to be to integrate a new system” (Lamb, N.d.). To reduce much of the risk keeping the legacy system one might consider:
- “Improving documentation, capture system information from departing staff and incrementally rewrite or improve system code when possible.
- Provide code developers with tools and training to identify potentially high-risk systems and revise or develop new, secure code.
- Consider migrating to software-as-a-service (SaaS) or commercial-off-the-shelf (COTS) deployment models
- Increase standardization (Hickey, 2015)”
One legacy system still in use today is COBOL. I found many organizations, especially banking or financial services still use this system created in the 50’s. The reason is because “little has changed in the core of banking. It is not a system that needs to replace itself every 3-5 years to remain alive. The biggest influences are external with equipment companies going out of business and perhaps some new reporting requirements (Lauer, N.d.)”.
Another reason might be based on “very little downtime. It is very stable and reliable (COBOL). All the front end systems used may experience some sort of down time or performance degradation. That could put some activities at risk, but the risk is not of the same magnitude as the back end accounting infrastructure which runs on COBOL. Customers who need to withdraw money need the cast iron trust that anytime they want to get their money, they can. A bank that has a failure, and especially a sustained failure for say a period of an hour or so, can quickly lose its standing in the market. The reputational damage will potentially be unrecoverable (Lauer, N.d.)”.
Most of the changes within a banking sector would be mostly for “ATM or debit/credit card changes (security pin)” and with the millions of rows of code within COBOL more than likely this “legacy” will remain intact (Lauer, N.d.). So, should one feel safe using an old “legacy” system especially in regards to one’s money? “What’s worse: Living with legacy systems or replacing them? Any mistake could have a severe impact. Most agencies have targeted the 60 year old COBOL system(s) for replacement, but it’s not a simple rip-and-replace job (Robinson, 2015)”. Old mainframe companies that have recently refocused on the cloud continue to update their COBOL tools to keep pace with current IT trends”. This should make everyone feel a little more secure (Robinson, 2015).