Today I’m writing about a crucial, but slightly non-glamorous topic in today’s 24x7x365 IT “cloud-enabled” world.
Ready?
Two words: “legacy applications”. The ones that make consultants groan, technologists run for the exits, and industry analyst firms spread gloom about either the exodus, or outright lack of “legacy talent” in today’s IT market.
But love them or hate them, legacy applications are with us for a reason and deserve a lot of attention.
What is a legacy application?
In short, a legacy application is so vital, entrenched, reliable, expensive, special purpose, or historical that its removal could have disastrous consequences for the business.
I generally define a legacy application as:
- Being six or more years old
- Now outside of warranty or support contract
- Difficult to support based on available IT market skills
- Encompassing a minimum $200,000 or higher multi-year investment
- Having two or more critical business applications or processes rely on it
- Having a deeply entrenched and experienced user base
- Having an estimated removal and replacement cost equal to, exceeding newer alternatives
Legacy system and application examples include:
- Mainframe / CICS / COBOL applications
- OS/2 Based applications and databases (yes, they actually do still exist)
- Novell Bindery and NDS
- Windows NT 3.x and 4.x
- RACF / ACF2 / RADIUS
- Proprietary accounting applications
- Any application with a closed-end data source (unable to be natively read, or easily exported from the legacy application to a non-legacy format, such as text, XML, CSV, flat file)
- Batch scheduling programs
- Old versions of UNIX, running in-house developed code, scripts, or critical applications
- Older, proprietary building access systems, PBX/phone switching systems, etc.
NOTE: Platforms, systems, and operating systems can also be labeled as “legacy”. Legacy need not have any relationship to mainframe-based systems.
How do applications and systems become legacy?
By being reliable and deeply entrenched in the framework of a business or organization. I often liken legacy applications to historic landmarks. Possibly worthy of preservation, or possibly worthy of replacement, but before doing anything with them, their history, necessity, and relevance must be strongly considered. Will a new replacement or “cloud” system really provide more value, cost savings and supportability than what it replaces? Or, would replacement just start an endless cycle of “rip and replace” with each new technology that comes along?
Advantages of legacy applications
- They work. They are reliable. End users usually don’t have to think about them much, if at all.
- Legacy applications and systems are an entrenched part of the business, user, and application community. They are well understood, and heavily used.
- Training materials exist, and development is mostly or completely amortized.
- Legacy applications are highly effective in their designated purpose.
- Legacy applications, especially those based on mainframes, can be extremely fast and efficient. Mainframe transactions may be processed locally without requiring multiple network SAN/WAN/Wi-Fi/etc. traversals to complete a transaction.
Disadvantages of legacy applications
- They are often big, complex, and difficult to maintain.
- May require custom outsourcing for continued support.
- May be slower than contemporary alternatives.
- Generally less flexible, extensible, and distributable than contemporary alternatives.
- Not understood by newer generations of IT professionals.
- In-house professionals who created the original legacy system or application may be long gone.
How do legacy applications and systems impact IAM systems?
Legacy applications pose special challenges to an IAM or enterprise integration programs. A good rule of thumb in is to consider the data source. If the application uses a well understood database or data storage technology, with well-defined protocols, chances are good there may be a way to integrate the legacy application.
In the identity and access management (IAM) context, here are some key considerations:
Identity Lifecycle Management (provisioning / de-provisioning / workflow / self-service / Identity-related services)
- Proprietary protocols
- Back-end repository (custom-made database, spaghetti tables, older versions, etc.) may prevent direct communication/li>
- Adapters may not support user self service for password and profile changes
- Interfaces may not be exposed to allow message passing for workflow-enabled applications
Access and Authorization
- Application may use proprietary or “black box” mechanisms for authenticating and/or authorizing users. May require custom code to support externalized authentication and authorization.
- If the application supports LDAP, RADIUS, RACF, or ACF2, your Access Management infrastructure *may* be able to integrate it.
Auditing, Reporting, Compliance
- Application may not support standard log formats.
- Parts of the application may not be written to log access, authorization, and breach attempts.
- Application may only support weak, short passwords (compliance problem).
Application Integration
- May not be possible
- May require custom development on the legacy application/system side
- May require custom development on the IAM product(s) side
- May require significant added expense
How can an IAM program address legacy applications?
- There may not be a one-size-fits-all solution for your particular application or system. Be absolutely sure that critical legacy systems are factored in to any IAM program decision including product and budget selection. The business may choose not to integrate legacy applications due to cost or support factors, but these reasons should be understood up front.
- Additional products such as ACF2 / RACF , LDAP bridges, or terminal emulators may be required. Many vendors require custom coding and extensive additional development to support many types of legacy application.
- Traditional mainframe-based applications may require “screen scraper” terminal adapters, or other emulation-based approaches. These approaches may be fine for basic provisioning, but can make bulk provisioning very slow. When selecting IAM or integration vendors, consider whether or not their software will add or reduce provisioning time.
- IAM system components, such as password policy controls or password synchronization, may have increased risk. Many legacy applications only support weak passwords and short, easy-to-guess user names. Ensure that your integration products have a means to securely transport and store legacy data.
- Don’t underestimate potential user resistance, retraining, integration, and testing requirements for legacy applications.
- When commercial or custom third party legacy applications are involved, bring the vendor in to the discussion early. They original vendor may have solutions available, or suggest workarounds for data extracts, access control, or provisioning. In some cases, XML-based solutions and services can wrap around older technologies, which can extend the lifespan of your legacy systems.
- Due to the vast differences between versions of databases, protocols, access methods, and other elements of software applications, integration systems are typically version centric. For instance, an IAM provisioning system may support version 8.1.x of an application server, but not 8.2.x. Same with host operating systems and patch levels which host the IAM systems themselves.
- There may be no one-size-fits-all provisioning solution for your particular applications and systems. Be absolutely sure that critical legacy systems are factored in to any IAM program decision including product selection. The business may choose not to integrate legacy applications due to cost or support factors, but these reasons should be understood up front.
How can businesses deal strategically with legacy applications and systems?
Be absolutely sure that critical legacy systems are factored in to any IAM program decision including product selection. The business may choose not to integrate legacy applications due to cost or support factors, but these reasons should be understood up front. Often, organizations use an IAM or enterprise integration program as their golden opportunity to understand and document processes, clean data, and build a strong application portfolio strategy. How an organization addresses its legacy systems is a business decision, first and foremost.
Here are just a few tips and criteria for deciding what makes sense in your situation:
- Is the application commercial/retail or internally developed? If commercially developed, replacement justification may be favorable if the vendor still exists. (Upgrade incentives and the like.)
- Multiply the current annual maintenance cost by 5.
- Calculate the total projected cost of the replacement(s), add 5 years of comprehensive support (internal + external) and total.
- Are you able to get the data out in any useful way for other applications to use? Yes = strong point in favor of the application / No = may want to strongly consider either phasing it out, or calculate costs of retrofitting it with a data export mechanism
- Do well-defined integration mechanisms exist? (XML, protocol translation, etc.) – Yes = points for / No = points against
Summary
In this article, I’ve suggested some key considerations regarding legacy systems. There is no absolute right or wrong answer when it comes to replacing a legacy system. The most important thing is to weigh your options carefully, consider newer alternatives, user acceptance, retraining, supportability, and other factors and make your decision.
Also keep in mind: “just because it isn’t broken, doesn’t mean you shouldn’t consider fixing it.” If the opportunity and budget come along to swap out legacy technology — without putting your business at risk — consider taking the plunge into newer systems. Newer systems, with increasingly open programming and service models, are inherently easier, and cheaper to host and support in the long run.
Have additional questions about legacy applications and systems? Looking for a second opinion? I can help. Call +1 800 507 3480 today or use the contact form to request a complimentary initial consultation.
