Almost a year ago, I started my blog by mentioning how Scott McNealy and Steve Ballmer took the stage to give an update on interoperability between Sun and Microsoft software technologies. Last week at a customer workshop, I met Eve Maler, who has been a key player in the ongoing interoperability efforts.

A delightful person, Eve was one of the inventors of XML and is now a technology director at Sun Microsystems, “developing interoperability strategies and leading partner engagements related to web services, security, and identity.” It was also interesting to learn that she cross-stitches and plays in a rock band! She publishes a great blog, Pushing String.

Pleased to meet you, Ms. Interoperability!

Technorati Tags: Identity,
Digital Identity,
Identity Management,
Sun Microsystems,
Microsoft,
Eve Maler,
XML

A customer remarked today that Identities should apply not just to people, but machines, software code, or any item that may be individually addressed. They call these items “Entities.” Hence, the moniker “Entity Identity.”

Sounds cool. I haven’t had much time to think if the relevance extends beyond the cool sound.

Technorati Tags: Identity,
Digital Identity,
Identity Management,
Sun Microsystems

When I was a junior engineer, I kept pestering my hiring manager with a plethora of questions. Finally, in exasperation, he responded, “Mark, I hired you to give me answers, not questions!”

Nonetheless, I have found throughout my career that posing probing questions to myself and others has been a valuable tool in discovering solutions to vexing challenges.

Are you considering an Identity and Access Management implementation? Have you defined your requirements? Here are a few questions that may help you organize your thoughts on the matter.

Administration (Managing Identities, Relationships and Identity Policies)

1. Who are the users (people and systems) that need access to resources within my sphere of responsibility?
2. What are the resources within my sphere of responsibility to which users will be granted access?
3. Who will be granted access to what?
4. What privileges will need to be granted?
5. What restrictions must be invoked?
6. Who can approve access rights, privileges and restrictions?
7. How will privileges be revoked?
8. How can we grant access in accordance with specialized regulatory requirements (e.g. Separation of Duties)
9. How can we define access policies in the context of the client’s organization?
10. Who will be responsible for Identity Administration (e.g. Human Resources, IT Administration, Help Desk, Self-Service)?

Control (Enforcing Identity Policy)

1. How will policies for access to resources within my sphere of responsibility be enforced?
2. How will users be authenticated?
3. When will strong authentication (e.g. UserID/password + token card) be required?
4. How will users be authorized to use specific application functions, systems or data sources?

Auditing (Proving Adherence to Identity Policy)

1. How can we prove that IAM policies are being followed?
2. Who has access to what resources over time?
3. Who has access to what resources right now?
4. When was that user granted access privileges?
5. Who approved that access?
6. What user privileges violate specialized regulatory requirements (e.g. Separation of Duties)?
7. When did users successfully gain access?
8. When were unauthorized accesses attempted?

This list of questions is not exhaustive. Hopefully these questions will help you craft more questions that will help you define requirements for your enterprise.

Technorati Tags: Identity,
Digital Identity,
Identity Management

I had an interesting conversation yesterday with our project team that has been shepherding an Identity Management implementation for an educational institution. The project had been languishing because the customer frankly didn’t place enough priority on the project to allow key resources to spend the required time to meet scheduled milestones.

However, the customer made a seemingly unrelated business decision to implement a new system. All of a sudden, they realized that provisioning user accounts on the new system could be most easily done with the Identity Management system our team was trying to implement.

Voila! All of a sudden, the customer’s priorities for the Identity Management system were aligned with their new initiative. Now, almost magically, resources were available, the customer was hungry to accelerate activities and our team could make meaningful progress once again.

The lesson? Magic happens when customer and vendor priorities are in lockstep. Real life business value really does drive progress.

Technorati Tags: Identity,
Digital Identity,
Identity Management

I love to watch professional basketball. The incredible moves, accurate shooting and tenacious defense exhibited by these polished, experienced players never cease to amaze me. I’m not a great fan of the Los Angeles Lakers, but it has been really entertaining this year to see how Kobe Bryant’s progressive experience blended with his raw athletic talent has produced incredible results.

One of my misguided college professors once proclaimed (seriously) that our minds are so powerful that any of us could become a star NBA player by thinking about it with enough focus and commitment. Maybe my thoughts could have made up for my short legs!

Unfortunately, too many companies subscribe to this same misguided philosophy: “We can implement Identity Management by ourselves, without guidance and expert assistance, by reading the manual and thinking about it long enough.”

Yesterday, I listened to Kevin Saye of IC Synergy, a Sun systems integration partner, give a great presentation about “Best Practices for IdM Workflow Development.” Before joining IC Synergy, Kevin implemented Sun’s Identity Management solution for 7-Eleven.

Wouldn’t you rather have someone like Kevin guide you through the process of implementing your Identity Management System? Someone like Kevin could help you avoid pitfalls he’s already experienced. Like Kobe Bryant has learned just the precise way to give a head fake, step back from a defender, and sink a long three-pointer, Kevin will help you know the intricacies of making your Identity Mangement stand up and work for you.

On the other hand, consider what an inexperienced team may do:

• Make poor design/implementation decisions. Like it or not, you can implement these systems the easy way or the hard way. Why should you be the one to find out?
• Choose a customized approach rather than leveraging built-in strength of the product. Too many implementation teams give up too soon and write some custom software before they discover how the product can fulfill their needs without all that customization.
• Extend the testing/troubleshooting cycle. Experienced teams know how to test, how to look for problems, how to fix things quickly.
• Undermine stakeholder confidence. Lack of experience can extend project schedules and erode confidence stakeholders have placed in the Identity project.

What should you do? Here are some of my suggestions:

• Choose a qualified, experienced systems integrator. Get someone who has been there and done that – not a wannabe.
• Use trained, experienced technical specialists. Demand the A-team from your integrator. Put your best people on the project.
• Get good training for your people. Admit to yourself that focused education can shorten your learning curve.
• Have experts mentor less-experienced participants. Lean on your integrator experts to help you become self-sufficient.
• Engage your product vendor for expert services. You bought the product. Your vendor’s product experts can help you succeed.

I’ve come to grips with the fact that I’ll never be an NBA star, no matter how hard I think. I’ll depend on Kobe and his compadres to hit jump shots. And I’ll always encourage you to get expert, experienced guidance for your Identity Management project.

Technorati Tags: Identity,
Digital Identity,
Identity Management,
Identity Risks,
Kobe Bryant,
Lakers,
IC Synergy,
Kevin Saye

“How do you eat an elephant? One bite at a time, chew well.”

Those who Implement Identity Management systems would do well to learn from that old, trite saying. Because Identity Management promises such broad benefits, we may be tempted to capture all those benefits in one large mouthful. In practice, great big bites are much more difficult to swallow than judiciously small nibbles.

Large Initial Scope can:

• Exponentially complicate system testing. Multiply 10 resource adaptors times 10 user roles times 10 workflows and we have a huge testing problem. Start with a couple of managed resources, a few roles and a few workflows. It is much easier to build the foundation and layer on functionality when the first small steps are well-proven.
• Require too much business process change. Identity Mangement systems can have broad impact on users and business processes. Trying to change too much all at once may not challenge the technology, but can wreak havoc on your organization.
• Delay perceived system value. Business managers want (and deserve) quick payback on investment. Building too much into the first phase of your Identity Management project can delay that benefit.
• Undermine stakeholder confidence. Successful Identity Management projects need consistent, strong sponsorship. If things stretch out too long, it is easy to undermine the confidence of the stakeholders who are so vital to the success of a project.

So, what is the recommended approach? Simple – eat one small bite at at time, and keep eating:

• Choose “Quick Wins.” A Quick Win is a subset of the overall enterprise solution which delivers high business value in a short timeframe. This allows a vital part of the Identity Management strategy to be delivered quickly, demonstrating that the approach is sound and establishing a foundation for further enhancement.
• Implement in phases. By segmenting the overall solution into manageable parts, you can deliver value quickly and steadily, thus sustaining executive sponsor support and progressively implementing additional Identity functionality.
• Tightly manage scope. Avoid the insidious scope creep demon like the plague. A few simple additions here and there can quickly add up to a schedule- and budget-killing monster.

I’ve experienced both the quickly-earned joy of well-planned “Quick Wins” and the drawn out agony of “eat the whole beast” projects. The former lays a foundation for further success; the latter spoils everyone’s appetite for more.

May all your Identity feasts be joyful!

Technorati Tags: Identity,
Digital Identity,
Identity Management

“You’ve got to be very careful if you don’t know where you’re going, because you might not get there.” – Yogi Berra

I doubt that Yogi Berra knows much about Identity Management, but his advice is appropriate. I believe that careful requirements definition may be the single most important thing we can do to implement Identity Management systems that really deliver value.

Poorly defined requirements may yield:

1. A system that doesn’t meet your business objectives. A colleague of mine calls Identity projects that don’t deliver real business value “Science Projects.” If business requirements are not carefully defined and if the technical design is not linked to each business requirement, the Identity Management system may have been fun to build, but won’t be worth much to the enterprise. And you probably won’t get the chance to deliver Phase 2.
2. Difficult technical challenges. Too often, requirements are defined beyond the scope of what can economically be delivered. For example, if you allow access control requirements to be included in the scope of a provisioning project, without using an access control product, extensive custom development may be required to force the proverbial square peg into a round hole.
3. Schedule and budget expansion. If careful requirements definition is delayed, the implementation team may find themselves sitting on their hands while requirements and design are debated. This inefficiency usually results in busted budgets and painful delays.
4. Poor stakeholder satisfaction. If the system doesn’t meet stakeholder requirements and expectations, stakeholders will be disappointed (or worse). Understanding and documenting requirements of each stakeholder early in the process is the best defense against such dissatisfaction.

The recommended approach?

1. Demand a formal requirements definition process. As a high school math teacher, my Dad used to say, “If you don’t have time to do it right the first time, when will you every have time to do it again?” Requirements definition is like that. Many resist the time and effort to define requirements right the first time – either skipping the exercise or failing to drive to the level of detail that is necessary. We must have the professional discipline to demand formality in this process, knowing that the investment up front will pay off handsomely as the project proceeds.
2. Define requirements from your selected Identity Management product point of view, not from a custom point of view. This is a subtle, but important distinction. If you have spent a lot time, energy and budget on selecting an Identity Management product to deploy, make a concerted effort to leverage the strengths (and ideosyncracies) of that product. Defining requirements outside the framework of the product that may be difficult and expensive to implement and support. If you choose to frame your requirements within the scope of what the product can offer, you will deliver value more quickly and end up with a system that is much simpler to support.
3. Conduct formal requirements acceptance. Each Identity Management project has many stakeholders with a vested interest in the successful outcome of the project. The requirements that affect each area of interest should be formally accepted by an authorized representive of that area. Either do it early or do it later. Later is always more expensive.

One of the most famous quotations attributed to Yogi Berra is, “It ain’t over till it’s over.” Through good requirements definition, we will define success – so we can know when a project is over. That may be the best reason for defining requirements, after all.

Technorati Tags: Identity,
Digital Identity,
Identity Management,
Project Management

“Chance favors the prepared mind.” – Louis Pasteur

My post on Identity Management Implementation Risks seems to have struck a chord with a few people.

Shekhar Jha asked for specific real-world examples. James McGovern posted a comment on Ash’s blog that he wished that I had videotaped the presentation for people to watch. Michael thought the term “resource” was de-humanizing. In yesterday’s Identity Management Newsletter, Dave Kearns wrote about my list of deadly risks. (This specific newsletter will show up on the Network World website in a few days; it always lags the email version.)

It is heartening to see people realize that Identity Management is more than just technology. These projects touch a lot of systems, require business transformation and impact a broad range of stakeholders. But aren’t Identity projects just like other IT projects?

Consider this equation:

Identity Management Business Complexity
(cross-functional business impact, many stakeholders, high visibility)
+ Identity Management System Complexity
(many integration touch points, many moving parts)
= Identity Management Project Complexity

Proper planning is an important key to managing the inherit complexity of Identity Management projects.

So, let’s consider the first risk – Poor Pre-Project Preparation (how’s that for alliteration?)

Lack of preparation for an Identity Management project can:

1. Set false expectations in the mind of stakeholders. Lack of good communications early in the cycle will have many people expecting more than can be achieved in a short time.
2. Force the implementation team to spin their wheels when they should be doing work. If the project is not well planned, key decisions will still need to be made, even if they disrupt the orderly flow of implementation work.
3. Cause implementation engineers to define business requirements. This hurts. Identity projects must deliver business value in order to be effective. But if business and technical requirements are not well documented and understood, and if the design is not linked tightly to those requirements, the folks on the front line with fingers on the keyboards, may be force to make bad assumptions or wait around until correct requirements definitions are provided.
4. Result in additional time and expense. The inefficiencies described above will be revealed in terms of over-budget and delayed schedule. Note that these budget busters are usually not technical issues, but business and planning issues.
5. Undermine confidence in the project. Business units need to see business value quickly. Delays and increased costs due to poor planning will drain away confidence and support

So, what should be done? Here are some key areas where plannning must occur:

1. Project sponsorship, governance and organization. Who is really the project champion? Who really holds the purse strings? How can we assemble and work with the right set of stakeholders that will help this project succeed? How can we organize and marshall available resources to assure success?
2. Requirements (Identity Management software + infrastructure). We must really know what defines success for our project. Too often, requirements are ill defined or poorly documented. Time spend carefully defining requirements, not just for software functionality but for the hardware and networking infrastructure in which it is to operate, will be paid back many times over.
3. Extended project resources. A technical project team is often inclined to think of itself as the center of the universe. However, the success of an Identity project depends on many people beyond the technical team: systems administrators, data owners, subject matter experts, testers, system users, trainers, business unit representatives.
4. Communications. Because of the so many people, in many roles in an enterprise are involved with Identity Management projects, it is vital that a strong communications plan be implemented up front. People need to know what is going on. Much has to be decided and approved. We must be prepared to communicate and communicate well.
5. Change Control. Despite our best efforts to define requirements and plan projects, things will change. Modifications will need to be negotiated, documented and managed. Planning for and agreeing upon a change control process up front will smooth this bumpy road.

An example? Let me give a glimpse of two. I know a project manager who spends half time on each of two identity projects. In the first, before he took over, all these rules of preparation were violated – fuzzy requirements, weak governance, shoddy change control, poor communications. We are still patching things up after 14 months.

The second? We arm-wrestled the customer into funding a requirements/architecture project up front so we both knew what was to be delivered. A change control process was defined and agreed to in the Statement of Work. The deliverables from extended project participants were defined in advance. Now, does the project have its hiccups? Yes. But it is under control. It will be a success. Planning really pays off.

Tags: Identity
Digital Identity
Identity Management
Project Management

Forrester Resarch named Sun Java System Identity Management Suite as the “Provisioning Industry’s Undisputed Market Leader.”

“By a large margin, Sun Java System Identity Manager came in as the most-function-rich solution in Forrester’s evaluation. The product led all of its competitors in several categories: connector functionality, policy management, auditing, and architecture. … Sun Java System Identity Manager does everything a user would want a provisioning product to do.”

Tags: Identity
Digital Identity
Identity Management
Sun Microsystems
Forrester Research

I taught a class today addressing best practices in Identity Management implementation. Part of the presentation was entitled “Seven Common Risks.” I lobbied to call this “Seven Deadly Risks,” but some folks thought that title was a bit over the top. Nonetheless, here are seven risky behaviors that could kill your Identity Management project.

• Poor Pre-Project Preparation
• Poor Requirements Definition
• Large Initial Scope
• Inexperienced Resources
• Poor Project Methodology
• Scope Creep
• Not Using Available Support

I’ll elaborate on each in the next few weeks – discussing why each is important and what you can do to migitate the risk.

Tags: Identity
Digital Identity
Identity Management