Identity Management Success

Let’s face it: Identity Access Management Programs are a challenge. They are big. They can be (and generally are) very expensive. They can take a while. (In some organizations, many, many years.) They are intrusive, and require organizations to think long and hard about where they have been, where they are today, and where they need/want to be tomorrow. Then there is the constant starting & stopping, ever-changing requirements, terminal scope creep, key resource personnel, vendor bug, support, or deployment issues — just to name a few. All these factors dramatically reduce the success likelihood and increase the failure likelihood. Today however, I want to talk a bit about momentum: what it is, why it is a good (well…critical really) thing, and what can happen to your Identity Access Management Program if it is lost. On the glass half full side of the equation, we will also present some suggestions on how to regain lost momentum.

Those of you who have been reading our blog and listening to our podcasts since the beginning (you know who you are …. we know who you are… and a hearty Thank You!) know that the litany of disaster above is just a device to illustrate the things to be aware of before and during an IAM Program, and how to prepare for maximum success. We are optimists here at Links Business Group, and know first hand that although many IAM Programs fail, plenty succeed and more are succeeding every day. As always, we hope our experience and suggestions can help your program become a shinning Identity Access Management success story.

What is IAM Momentum

IAM momentum is really just a rehash of a sound Project Management principle, and applies toward any project. The idea is that once a plan is formed, documented, team assembled, etc. that it most move forward inexorably toward its stated goal until all milestones are achieved — preferably on time, and on budget. (Or at least within the allowed variance, generally a good 10% for the standard organization.) Momentum propels stakeholders, subject matter experts (SME’s), clients, implementers, etc. toward the goal. Momentum takes advantage of the dictates/mandates/organic bottom-up groundswells, etc. — or whatever force(s) brought your program to fruition. Momentum is fluid, continuous, and although obstacles will always surface, momentum finds a way around them. A skilled IAM Program Team views obstacles as just another set of opportunities with which to strengthen organizational commitment to the tasks at hand.

Benefits of Momentum

• Builds morale, induces commitment
• Maintains positive forward motion, in multiple parallel tasks or “work streams”
• Builds and maintains focus
• Lower overall program costs
• Builds multiple layers of success. Milestones fall one by one until the Program Plan is signed off by the sponsors.
• Builds organizational support
• Maintains allocation of key resources to the critical path items

Flip side: What happens when momentum is lost:

• Project delays
• Missed expectations and reduced program credibility
• Cost increases
• Morale damage to program team
• Morale damage to clients, partners, or suppliers that depend on program deliverables
• Audit pain (potentially significant levels of audit pain)
• Priorities, deliverables, and scope fluctuate
• Continual retraining of staff, and support team
• Re-communication to consumers and stakeholders
• Momentum is something your program either has or doesn’t have. Once lost, it is extremely difficult and in many cases impossible to regain. We strongly suggest not losing it in the first place.

Some practical tips to achieve and maintain momentum:

1. Get high-level company sponsorship. Board-level preferred. C-Level if not. If neither of those is achievable, then get sponsorship from a broad cross-section of senior-level managers.
2. Narrow the scope of each sub-project until it is cleanly understood by all program members. When you think this clarity has been reached, go around the table and ask each team member to state his or her understanding of the deliverables. If the answers are not consistent, keep going back around the room until there is a single chorus. If you cannot achieve a unison chorus in three tries, it is time to re-scope the deliverable or change the team composition. Nine times out of ten, deliverable scope is the problem and likely too large to be consistently understood and stated.
3. Calculate the number of required resources, then add a minimum of .5 person as contingency (trust me ? you?re likely to need it regardless of your planning acumen). Do not…we repeat…do not…begin an enterprise-level IAM Program without contingency resources. If the organization and/or vendor partners cannot produce them, then stop until you can get them. Your program will fail without reasonable contingency planning.
4. If there is no dedicated PM for a given task or group of tasks, then rotate the tracking duties among team members. It is our contention, that rotating task tracking keeps everyone on the team involved in the day-to-day. Though it could run the risk of a task consistency issue, it dramatically lessens the risk of a momentum issue.
5. Make momentum a priority. Establish multiple milestones, and do not be afraid to manage a separate ?sub plan? just to track all the little details. Technical build plans are a great example of this. Build plans for IAM-related infrastructure can encompass literally hundreds or thousands of sub-tasks. Not likely that a CIO will want to see that on a project plan, but each task must be tracked and completed nonetheless. Organizations differ in the level of detail they like to manage to. Milestones are key to maintaining momentum. Err on the side of too many, rather than too few. Milestones can be sent in bulleted emails, green/red/yellow light project charts, and discussed in IAM Team meetings. Successive successful milestones, however slight (but they should always be reasonable,) maintain morale and “positive press” for your program.
6. Maintain high program visibility. Visibility is a key factor in momentum. Visibility keeps the pressure on, while reminding everyone from senior management on down, that there is a vital business project in motion. As my grandfather used to say, “A job worth doing, is a job worth doing right.” If your organization does not yet have the internal backing to “do it right,” then we recommend that you wait until there is literally a crushing tidal wave of support and momentum, or consider reducing your goals or even shelving the project. Establish a templated email or program newsletter very early on, and as you meet with individual stakeholders and support staff, add each one to the address book.Organizations vary widely on communication policies, so we can only provide a general suggestion. Make newsletters additive at first, until major milestones are reached. We like the model of “meet one, add one.” We like this model because it keeps communication within a context, and ensures that (for the most part…) only individuals that have received a presentation regarding the program, or clearly understand its goals and objectives, will get a status newsletter. It can be more detrimental in some organizations to send bulk mailings early, in which the recipients have no context for your program.

Conclusion

Momentum is a fundamentally critical force to harness for good. Unlike other factors in an IAM Program, momentum is binary — the program either has it, or it doesn’t. With it, great things can be achieved. Without it….well….let’s just say that you don’t want to be in the “without it state.” We hope that the tips provided may be of use to you, and assist your program efforts.

Have additional questions about IAM Program momentum? Have an IAM Program that is just getting off the ground or in the planning stages? 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.

Hello Readers:

Our blog upgrade is complete. Thanks for your patience.

Best regards,

Links Business Group LLC

Hello Readers:

During the weekend of 8/11 and 8/12, we will be upgrading our blogging platform. You may experience intermittent delays, or strange looking pages until the process is complete. We apologize for any inconvenience this may cause. Thank you for your patience, and for helping make our blog such a smashing success.

Best regards,

Links Business Group LLC

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.