Identity Management Is a Lifestyle
by Tom Ebner on September 30th, 2009

After the Suncle series covering the Sun/Oracle identity and access portfolios, one of the most popular posts on our blog was an article talking about best practices for Active Directory provisioning by guest blogger Martin Sandren. To continue with the thought of providing interesting (and different from our usual ruminations) content I am pleased to introduce Tom Ebner as our guest blogger.

Tom Ebner has spent the last 7 years leading the creation and deployment of Identity and Access Management infrastructure and services for a Fortune 500 financial services corporation. Tom successfully delivered IAM in the real world despite the challenges of new technology risk, changing organizational objectives, scarce resources, and vanishing budgets. Tom is now helping other organizations to plan and execute IAM deployments.

Do you like solving tough problems? Enjoy working with new, evolving and often immature technologies? Like being dependent on new business processes and multiple data sources over which you have no control? Welcome to Identity and Access Management! After 7 years spent creating and deploying Identity and Access Management infrastructure and services for a Fortune 500 company, I recently took time to reflect on the experience. As a colleague of mine often reminds me – “Identity Management is a lifestyle”, minus the yachts and Rolls-Royces.

I started with a basic corporate directory and evolved to a full-blown Identity and Access Management infrastructure and services. We went from web single sign-on to provisioning of accounts to role management and entitlements. Here are a few things that I learned while living that lifestyle.

Rule #1. Understand the problem and the opportunity One of the smartest things we've done was to approach IAM as a fundamentally data-driven domain, even though the problem was initially framed in the context of security. Audit findings created high-level awareness of the need to do something, but the concrete dollar value we delivered was based on improved operational efficiency and better customer service. For example, the data required to answer the access control question “Is system access commensurate with job responsibility?” can also be used to route a customer call to the appropriate customer representative. We found we were able to deliver quantifiable business value using this approach.

Rule #2. Assess the quality of the identity data We were fortunate to have a unique internal identifier that had been established for each member of the workforce and this made it easier to correlate data across multiple sources. Having a single, preferably opaque, unique identifier is critical but not necessarily sufficient. Other attributes may be required for correlation but data sources may not have these other attributes or may not assign the same meaning to them. Furthermore, if you have an identity service that provides identity-related information to the rest of the enterprise, it is desirable to extend the data quality rule to each data attribute you expose. While the Identity services provider may not be the “owner” of the various attributes, the identity services are used by the enterprise as an authoritative source and you as the provider will be held responsible for any quality issues. Ensure your authoritative sources understand their responsibilities. We spent a lot of time educating and influencing in this area.

Rule #3. Create a strategic technical vision ..and stick to it! Early on the team created a one page vision for the identity lifecycle. We started with Burton Group’s representation and customized it for our business. This is the familiar on-boarding / registration, provisioning of accounts and associated entitlements, job change and transfer, and finally termination and de-provisioning cycle. We made it speak to our specific business process goals and systems. It was critical to help executives understand the “what” we were planning to deliver ...which brings me to the next rule.

Rule #4. Get (and keep) an executive sponsor IAM is an infrastructure play and with no readily discernible business value as such it is tough and risky from a sponsorship perspective. It involves change to operations and it is not a revenue generator BUT it's a critical enabler. As time went on, it became seen as essential to security and compliance but this wasn't true in the very beginning. You will need an articulate, visionary sponsor who can bring visibility, business reality, and funding. Don’t minimize organizational inertia and tension between different layers. Organizational communication and alignment of objectives still required constant time, attention, and adjustment. Make sure the overall program goals are in sync across security policy, access administration, operations and technology groups.

Rule #5. Build a great team I’m a huge fan of small, smart, creative, and collaborative teams. My core team included an architect comfortable with enterprise architecture and hands on product configurations, a data analyst (DBA quality but with business analyst savvy), a technical lead (expert in the IAM product suites), a business analyst (highly analytical and business relationship oriented), a security expert with software development background and PM skills, and a production operations specialist. We also had an offshore team of skilled production support and software development folks. The breadth and depth of specialized skills required should not be underestimated. Allocate time and money for training and mentoring of staff and offshore teams.

Rule #6. Add great partners to your team In keeping with the theme of “Identity Management is a lifestyle”, you will need significant help from product vendors and professional services all along the way. Make good choices...or they will come back to haunt you. You want partners that help you think creatively about solutions, will take the time to understand your use cases, and will stick with you in a long run. In my case, I worked with product vendors (from major players to startup), IAM services specialists, and offshore vendors. While deliverables are critical, I always looked for partners that I could work with. These relationships paid off when the going got tough.

Rule #7. Create a strategic technical architecture Another key to our success was our selection bias and approach to architecture. We created a domain boundary and clearly articulated what services belonged inside or outside the boundary. This was extremely helpful when it came to detailed design and product selection over the years. It also helped with our internal discussions in the technology enterprise. State your design philosophy. Our bias was buy rather than build, and never do both. We only created custom applications where no product fit our requirements. This meant we created our own White Pages presentation and custom developed web services to expose our identity info. This gave us the ability to control access to domain data and enabled us to control the release process (vs. being dependent on a vendor release schedule).

Rule #8. Deliver something valuable to the business Do it fast, often and preferably yesterday. For us it was making high quality data about the workforce available via a friendly web interface and via secure web services. This allowed us to deploy web single sign-on to virtually all intranet applications and eliminate many individual stores of identity data, providing tremendous operational value as a result. These early successes gave us credibility and paved the way to funding for the next steps… Be opportunistic. We kept our ears open for business problems that could be solved by our services AND would further our strategic vision. For example, instead of a large cross-enterprise role-based access control (RBAC) project, our philosophy was to avoid roles unless we had a very strong business partner with a very well-defined and limited number of roles to implement.

Rule #9. Manage your risk. IAM is a program or a portfolio with inherent risk. Monitor and manage your risk across the portfolio. As with all technology projects – especially those in new product or process areas – be sure to have a plan B (and a plan C, plan D, etc…). While our program was very successful overall, we did encounter significant setbacks in certain areas. One of the biggest lessons I learned had to do with provisioning accounts and entitlements to the mainframe. In this particular area we had a lot of heartburn and not many alternatives so our risk to contingency plan ratio was disproportionately high (high impact with high probability with inadequate contingency plans). While it is often convenient to think that in a buy vs build scenario, if you buy a product the risk has been offloaded to the vendor, this is a fallacy. You own the risk. Spend the time and energy to go through what-if scenarios and be fully prepared to switch gears if and when needed. Balance the opportunities for funding with product and business process maturity. Choose incremental steps carefully.

Rule #10. Understand and communicate “What does success look like?” Manage your stakeholders. Create an annual business plan with clear objectives, expenses, strategic vision (business and technical), and be clear about what is “not going to be done”. I also kept a slide that listed accomplishments in the prior year and to date. I carried this everywhere and used it to keep a persistent message flow on our accomplishments, plans, and value delivered. Never underestimate the communication required for a successful IAM program. It is not an easily explainable topic to most business and/or technical execs. Whatever amount you are currently doing I assure you that you need to do more!

Posted in Identity Management, Access Management, Change Management, Data Quality, Business Perspective    Tagged with guests


Brad Tumy - September 30th, 2009 at 3:43 PM
Nice post Tom. I completely agree with these rules. I'd like to add that you can never under-estimate the value of a supportive executive sponsor. It is critical to have a channel into your executive group and they need eyes into your project. Just because you know it is important doesn't mean anyone else in the company will know that too. Rule #10 seems like such a no-brainer but it is probably one of the most common issues a team faces. I describe it to my team as, "how do we know when we get there?". Everyone's view of success is different and you need to understand what your key stakholders will view as success and then deliver that to them.
Julian Knight - October 2nd, 2009 at 4:40 AM
Excellent and well written post. Thanks for elaborating these key principals for IdM implementations. I've added this to my important bookmarks for future reference.
Mark Dixon - October 7th, 2009 at 8:52 PM
Excellent post, Tom! I really like to read about real-world advice - things that work. Here's my post about yours:
Leave a Comment

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)