Identity Management Success

I’m going to write a little about a topic that is not so glamorous in today’s “Web 2.0/SOA-enabled/Blogified” world. Two words: Legacy Applications. That’s right — the things that make consultants grown, technologists run for the exits, and industry analyst firms spread gloom regarding the pending exodus of legacy talent. Love them or hate them, Legacy Applications are here for a reason and pose vital consideration points for your IAM Program.

What is a Legacy Application?

In short, a Legacy Application is one that is so vital, entrenched, reliable (generally…), expensive, special purpose, or historical that its removal from production or failure could cause catastrophic consequences. While your criteria may vary, from an IAM Program perspective, we generally define a Legacy Application as:

• Six or more years old
• Nearing, at, or past end-of support life (for COTS)
• Challenging to support, from a current skill set perspective
• Encapsulates a minimum $200,000 collective multi-year investment from a business perspective
• May be a COTS (Commercial Off The Shelf) or internally developed application
• Five or more critical business applications or processes rely on it
• Deeply entrenched user base and high comfort level
• Estimated removal and replacement cost is equal to, or exceeds newer alternatives

Examples include:

• Mainframe / CICS / COBOL Applications
• OS/2 Based Applications and databases (Yes — they 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 (e.g. “black box”) data source (unable to be natively read, or easily exported from the Legacy Application to a non-legacy format, such as text, XML, CSV, etc. 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.

(As noted above, platforms and operating systems can also be considered Legacy Systems or Applications.) One of the evident points from the list above is that Legacy Systems and Applications need not be mainframe based.

How do applications become Legacy?

By being reliable and deeply entrenched in the business/culture/mindspace of the organization. At Links Business Group, we generally liken Legacy Applications to historic landmarks. Possibly worthy of preservation, possibly worthy of replacement, but before doing anything with them, their history must be carefully considered, along with their relevance — or lack thereof — to your current Identity Access initiatives and strategic goals. Will the projected replacement for that historical landmark really bring more value? Or, perhaps start an endless cycle of “rip and replace” with each major technology wave?

Advantages of Legacy Applications

• They work. They are reliable. A true legacy application is just there, it works, end users and people bring the dollars into your organization do not generally have to think much about it — if at all.
• Entrenched part of the business, user, and application community. Well understood, and heavily used.
• Training materials exist, and development has be 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, and 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 offshoring for continued support
• May be slower than contemporary alternatives
• Generally less flexible, extensible, and distributable than contemporary alternatives
• Not well understood by newer generations of IT Professionals.

What do Legacy Applications mean to IAM Programs?

Legacy Applications can pose special challenges to the IAM Program. A good rule of thumb in regard to IAM and Legacy Applications, is to “consider the source.” In other words, any applications in an IAM Program should be viewed entirely from back to front. If the application uses a well understood database or data storage technology with well-defined protocols, chances are good that there is a way to integrate the application with one or more components of an IAM architecture. Here is a general breakdown of challenges/opportunities presented by Legacy Applications in each of the four major realms of Identity and Access Management

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 a provisioning adapter from communicating directly with the application.
• Adapters may not support user self service for password and profile changes
• Interfaces may not be exposed to allow object-level communication, such as SOAP messages for workflow-enabled applications
• Access and Authorization
• Application may use proprietary or "blackbox&quot mechanisms for authenticating and/or authorizing users. May require custom code to support externalized authentication and authorization
• If application supports LDAP, RADIUS, RACF, or ACF2, your Access Management infrastructure *may* be able to accommodate

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

How can an IAM Program address Legacy?

• There may not be a one-size-fits-all provisioning solution available 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.
• If additional products are required (ACF2 / RACF bridges, for example,) to support provisioning or access control, calculate those into the cost structure early. Many vendors require custom coding and extensive additional development to support certain classes of legacy application.
• Traditional mainframe-based applications may require “screen scraper” adapters, or other slow emulation-based approaches. These approaches may suffice for basic provisioning, but can often introduce additional time to each provisioning action. As part of your vendor pre-selection process, consider whether or not provisioning or access control systems will add net time to each transaction type.
• Pieces of IAM systems, such as password policy controls or password synchronization, could have added exposure risk due to weakened passwords supported by legacy systems. Ensure that your products have a means to securely transport data with legacy systems, while providing additional “standing encryption” capabilities for any data stored.
• Don’t underestimate potential user resistance, retraining, integration, and testing requirements for Legacy Applications. In some cases, such as with Legacy Systems that provide access and authorization services, all applications consuming the application services
• When COTS or custom third party Legacy Applications are involved, bring the vendor in to the discussion early. They may have solutions available, or suggest workarounds for data extracts, access control, or provisioning. In some cases, XML-based solutions can be used as a “wrapper” around older technologies, which allow their functionality to be extended.
• Due to the often vast differences between versions of databases, protocols, access methods, and other elements of software applications, IAM Systems are inherently version centric. For instance, a provisioning system may support version 8.1.x of an application server, but not 8.2.x. Same with host operating systems which house the IAM systems themselves.
• There may not be a one-size-fits-all provisioning solution available 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 should the business address Legacy Applications from a strategic perspective?

There may not be a one-size-fits-all provisioning solution available 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. Often, organizations take the initiation of an IAM Program as a golden opportunity to understand and document processes, “clean their application houses,” and set application portfolio strategy. How an organization decides to address its Legacy Infrastructure is more a business question than anything else. Here are just a few tips and criteria for deciding what makes sense in your situation:

• Is the application COTS or internally-developed? If COTS, the justification for replacement (the old buy vs. build scenario comes into play here)
• Multiply the 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

Conclusion

Today we have looked at just a few of the issues surrounding Legacy Applications, and made some suggestions on how to plan for them. Before we end the discussion, a final point is worth repeating. Decide before your vendor pre-selection process if Legacy Applications will be included in your IAM Program, and if so, which ones.

Have additional questions about Legacy Applications and Systems as they relate to IAM? Looking for a second opinion? Links Business Group LLC can help. Call us today at +1 877 769 8938 or send email to request a complimentary initial consultation. Thanks for reading our blog, and we look forward to working with you in the future.

Until next time, all the best, of Identity Management Success.

Corbin H. Links, President
Links Business Group LLC

©2003-2007 Links Business Group LLC. All Rights Reserved.