Some Process Re-engineering Principles for Identity Management Projects (part 1)

I'm in the early stages of working with a colleague on a whitepaper on guidelines for business process re-engineering for provisioning projects, and thought I'd share some of our thoughts to see if I could get some feedback. (If we use anyone's feedback, we'll make sure we reference you.)

1. The first point is to put some parameters around the re-engineering effort. The most common mistake that IDM focused re-engineering efforts make is to overdo it. Once a current state process diagram is put together (preferably in BPMN) - many consultants find way too much to optimize, usually because of complaints from the customer. It's important to keep your scope in mind, otherwise the project can quickly turn into a much larger endeavor than you (and the client) had previously anticipated. It's important to focus primary re-engineering efforts on areas that can positively impact identity data. It may be tempting to re-engineer an inefficient interviewing sub-process of the onboarding process, but will most likely not impact your identity data either way. Furthermore, provioning platforms were not created to solve that problem (more on this later). On the other hand, re-engineering a self-registration process to prevent duplicate accounts will have a significant impact on your identity data. The lesson: pick your process re-engineering battles wisely.

Thoughts?

(to be continued...)

Pottery Making, Iterations and Identity Management

I'm a big fan of iterations in identity management implementations. The reason is pretty simple: you can't learn from lessons until you try. (You could learn from consulting firms, but not about your environment.) Which means that you don't get really good at delivering identity management until the 3rd or 4th time. (So take that 9 month project and break it down into smaller 3 month projects!)

Anyhow, here is the pottery making connection. It's a parable a co-worker forwarded to me from Art and Fear:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot—albeit a perfect one—to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work—and learning from their mistakes—the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

The lesson: Take on a small, well-defined, low-risk phase 1. Learn lessons. Take on a small, well-defined phase 2. Lather, rinse, repeat.

Nation's First CIO Has IdM Background

President Obama named Vivek Kundra as the nation's first CIO today. An interesting tidbit caught my eye.

Kundra also worked as vice president of marketing for Evincible Software, which provided electronic signatures and identity management for financial services companies and the Defense Department.

Evincible was acquired by Exostar back in 2004. On their site...

In 2004, Exostar acquired Evincible, a leader in PKI and digital signature technologies and best practices. The acquisition brought both proprietary technologies and leading subject matter experts into the Exostar organization, enabling us to deliver technology, policy and best practices leadership in the areas of PKI, federated identity management and physical and logical assess.

It's going to be interesting to see how his background in identity might influence what's happening in the federal IT space, and current initiatives (that seem to be lagging) to federate gov agencies. Hopefully, he takes identity farther than HSPD-12 did.

Where is the Motivation for Deprovisioning?

A series of blog posts on self-service deprovisioning in the federation world got me thinking about a simpler, albeit very real, problem with the "traditional" deprovisioning process in a company.

Most companies that have an IdM system have 2 ways to deprovision users:

1. Emergency Termination Workflow (where a manager logs on to the deprovisioning workflow, and kicks off the termination process that disables accounts across the board)
2. Automated Terminations (where the IdM system keys off of HR or Payroll or some authoritative store that provides the user's status and termination date which in turn automatically disables accounts)

The problem I've seen most companies face is with the second workflow because data is entered in late. So why not put a workflow together for self-service deprovisioning?

The only problem with this approach is the lack of motivation for an end-user to run through the workflow. Perhaps there is an approach to tie the completion of this workflow to some interest for the end user that will motivate him/her to run through it. Some ideas...

• Severence Pay
• COBRA Enrollment
• Continued Communications (to enter in personal e-mail address?)
• An iPhone? (seems to work for other things)

I bet that this approach would solve some of the data-timeliness issues. What do you think?

More on VDS and Cache

Mark Wilcox put up a post responding to my previous queries about the virtues of persistent cache and virtual directories. The bottom line of my post was around performance, so Mark gives some figures for OVD:

The overhead is absolutely minimal - it's generally around 2-5 milliseconds. And worst I've ever seen is around 50 milliseconds (remember that's still only 5/100s of a second). This includes doing a join of data.

Are Symlabs, Radiant Logic and other vendors seeing the same results? Perhaps, a skilled SI may want to chime in? If so, then why does anyone use a persistent cache? Anyone?

Also, Blink Technologies put the following comment on my previous post:

I thought the whole point of the cache is to lighten the load against the system as a whole. It's a compromise of data freshness for performance. Plus the entire point of a cache is to "cache" frequently used data, of course depending on the algorithm used (LRU, MRU, etc.). I also assume that the cache is adjustable and can have specific timeouts for freshness. I think for a highly trafficked directory this is a great trade-off.

Funding Doc Templates From VC = Saving $$$

Brad Feld just posted a set of 5 docs entitled "Model Seed Funding Documents" that I really wished I had a few years ago. (It has a term sheet and subscription agreement!)

Anyone who is going through a seed round should/must go read Brad's blog thoroughly before speaking with attorneys. Educating yourself on your time rather than the attorney's could save you a ton of money. I wish all VCs were this helpful.

Deprovision. We're in a Recession!

Hot off the Canadian Press:

The Canada Revenue Agency has issued at least $3-million in paycheques to people who don't work there, says a new audit.
"Overpayments generally occur when employees leave the agency and through errors or omissions their pay is not stopped on time," says the internal report.

I often hear something like this from identity management workshop participants: "I wonder how much payroll gives away for free because of a broken deprovisioning process."

Me too.

Here's a quick example I saw last week. The daily inactivation report that gets sent out to all admins from HR contains an "entry date" that is weeks, sometimes months, passed the "effective date". How's that for an ROI analysis for your next identity project?

Another Entry into the IdM Managed Services Space

I just read an interesting press release this morning from Watson SCS, an IBM Identity Management SI. They've announced an off-premise managed service offering offering called Identity Management On Demand, bolstering the following:

implementation of a simple Identity Management program can be executed in twelve weeks – about half as long as the quickest deployment of a customized solution.

I have special interest in this area. (Last week, Identropy announced the expansion of its off-premise managed identity services offering (iMIS) by adding support for Novell Identity Manager.) What's interesting about Watson SCS's play is that they're opting to offer a fully managed service, hosted off-site. A few days ago, I was speaking to a colleague at another integrator who recently pulled the plug on their off-site offering, for reasons I've already discussed.

Anyhow, it's great to hear more offerings in this space. It validates what we've been hearing from our clients: Why is this stuff so painful to implement and manage?

Welcome to the party, Watson SCS...looking forward to seeing you out in the field.

On Identity POCs - From a Vendor's Perspective

I pinged Joe (Nobody?) on Twitter last week regarding Identity Management POCs. Joe put up a lengthy post on his blog regarding some of his thoughts from the perspective of the vendor (so it seems). It's always great to get thoughts on the topic from another vantage point...some great points, with my $.02 in-line:

"a POC is that they are a dangerous sales activity used against a vendor rather than for it (I used to be a customer and did just that)"

I've witnessed that before. So Joe, how do we make sure the POC stays on the right track?

"But a POC is should not be a repeat of a demo in a customer's environment. On the flip side, a POC should not be an installation exercise based on the customer's demands.
A POC should be a onsite installation to show at a minimum, key use cases for the defined phase 1 and 2. Self service, HR feeds, provisioning into the key systems and de-provisioning for exmaple. Which means Phase 1 and 2 should be defined prior. How do you know what to show if the customer doesn't know where they are going?"

Use cases. I like. Tell me more...

"Prove the concept. Prove the process. Prove the business improvements and solving of business needs rather than proving when you hit this button this technical thing happens."

Completely with you.

"Don't prove installation, don't prove configuration, don't prove how many components it takes to do it. "

Hmm....not so sure about this one. A POC should prove business use cases as well as allow the technical team understand how it works in order to judge integration efforts and supportability...no?

"Another reason why POCs are often an embarrassing cluster is the customer's environment. I generally require, based on the customer's hardware, that I have sterile servers, patched specifically, nothing else on them and require the pre-req software installed on them before I walk in the door...What GPOs are set that is locking down a service and takes you 2 days to find it. Regardless on the cause, any delay is bad impression on you and the product."

Fantastic point. I've seen POCs blow up because of a misconfigured DC, DNS problems, etc. And the vendors end up spending time troubleshooting environment problems rather than working on the actual POC.

"If, as a vendor, you drive the use case creation with the customer you will show your knowledge and leadership. You will have a controlled flow from start to finish they will make you look successful and show the customer their needs. Your time will be shorter and cost less for you. The success rate will be higher. You miss these things, the customer will push you into a hole of broken knowledge. We are the experts, not them."

Well said, Joe. Nobody.

Poor Man's Deprovisioning

In this economy, I've been repeatedly pinged by clients on how to maximize their investment in their existing Identity Management software investment. In other words "I want to do all this stuff, but I don't want to buy more software, and barely buy any services."

So here is an idea that came from a conversation with one of our engineers. This is for clients that own a Password Management solution only, but want to be able to deprovision users. They could create a workflow to change the password to all target systems to a random password that no one knows. In effect, the user would be locked out of all accounts. A small program could be written to call the workflow's SPML interface (assuming it has one) based on a feed from Payroll or HR as well for a nightly process. No new software, barely any services, but an effective deprovision of accounts.

I'm noodling if this would pass an audit, but I doubt it would since the account is still active. But it would work, it would leverage the clients investment in connectors built for all target systems, and could be accomplished in no time.

I think it's the best thing since sliced bread, but I'm sure I'll find a new favorite tomorrow. Would this work?

Identity, Holidays, and a Little Marketing

Fun.
Enjoy!

Virtual Directories and Persistent Cache

I got drawn into a debate lately about the pros/cons of persistent cache in a virtual directory, and the practical implications of it. (I know this is an old debate. Better late than never?) A persistent cache is basically storing a copy of data locally at the virtual directory, so it doesn't have go get the data each time.

The first question is 'why add this capability? isn't the whole point of a virtual directory provide real-time access to backend data?' In my conversations, I basically received one answer: performance. Virtualizing and transforming the data can slow things down a bit.

Clayton Donley makes a case against persistent cache in an older post. To summarize:

• Persistent cache will mean data isn't real-time, which means the 'freshness' of data will be compromised.
• There are security concerns with adding another place to keep the data.
• There is pain associated with managing yet another directory.

(i.e., if you want a metadirectory, then get a metadirectory!)

So, I've come up with a few questions, and was wondering if anyone has any thoughts about it...

1. Since performance is the main point here, does any one have numbers on the performance hit caused by virtual directories?
2. Is performance the only real justification for persistent cache?

Managed Identity Services Winner

Thanks to everyone who filled out the Managed Identity Services survey. We finally identified the winner of the giveaway....and the winner is Niall McLoughlin! Enjoy your new iTouch! Thanks Ian for all the work on the survey, and thanks Matt for aiding with the whole winner selection thing.

A Few More Snappy IdM One-Liners...

In response to my request for snappy one-liners that would be applicable for identity projects, Jeff Bohren and Mike Conklin (welcome to the blogosphere, Mike!) provided some input. Here are some of my favorites:

• The dirty little secret about provisioning is that it’s really all about deprovisioning.
• You shouldn’t start out trying to do account management by adding another account to manage.
• It doesn't matter what you do on the back-end -- if the end users (and project sponsors) can't see tangible results that affect their day-to-day activities, all the process re-engineering and data clean-up in the world is going to go unnoticed and unappreciated.
• For whatever reason, hearing the exact same thing come from an outside consultant actually sinks in with management, but this never seems to happen for internal people :)

Seems like fun so far... so, I'm tagging Matt F., Matt P., Azeem Khan, Mike Trachta, Ian Yip and Jackson Shaw (just to throw a little product in the mix) to contribute their wit to the conversation.

It's About the Business...

I just got back from another long day with a client to aid them lay out their identity management roadmap. I've noticed a few interesting recurring themes:

• Good technology can't compensate for bad processes (although it might make it less painful)
• Fixing your data without fixing your processes is like painting your house on a rainy day
• Throwing more software at an identity problem usually exacerbates it
• A dollar in an identity project doesn't take you as far as you'd expect (even though its well worth it)
• What business users think is happening is quite often vastly different than what is happening under the hood
  

Any other snappy one liners?

Repealing SOX and Identity Management

Newt Gingrich and David Kralik wrote an op-ed in today's San Francisco Chronicle about repealing SOX. I've been following the buzz around this for a few months, but it always has a bit more bite when it comes from a former Speaker of the House. Gingrich and Kralik outline a number of convincing reasons to repeal SOX, including its negative impact on the IPO market as well as its failure at "...preventing insolvencies and accounting shortfalls in companies such as Bear Sterns, Lehman Bros., American International Group (AIG) and Merrill Lynch." The last lines of the article are very action oriented,

With a new presidential administration and a Congress convening in less than three months, now is the time to begin thinking through the solutions needed to address our economic challenges. Economic growth in a sound market economy requires smart regulation, not destructive regulation that hurts economic growth. Sarbanes-Oxley fails that test. It should be repealed.

I've written previously on the need to move away from compliance as *the* driver for identity. A legislative act such as this could force our hand as an industry. Being personally involved in the process, I am acutely aware of the impact that compliance has on quickly approving budgets for projects, and the way IT has leveraged SOX in order to push projects of their liking (even if its true ability to demonstrate compliance was suspect). This hyper-compliance environment may have created complacency on our end from the perspective of demonstrating the true value of identity for the business. Anyway you slice it, if SOX gets repealed (or slimmed down, as I expect it will be), we're going to have think a little harder, and I think that's a good thing.

Random Thoughts on Hitachi and Construction Cranes

Looking outside of my window this morning, I noticed a construction crane with the label "Hitachi" on the side. I kind of chuckled at the notion that a company could provide Identity Management software and construction machinery at the same time. Being part of startups nearly my entire career, where focus and niche is everything, my narrow view of the world makes it difficult to comprehend that a company could do such vastly different things effectively. Then again, it's not the first time. Siemens has its foot in the Identity world, and makes hearing aids and dishwashers too.
Does laser focus in the startup world not apply to larger corporations? I'm sure there are a few dozen books on the topic...time to go find 'em.

The Answer is...On-Premise Managed Identity Services

Ian has posted his findings from his Managed Identity Services survey. My primary interest around the survey was to see if data could be collated that could identify characteristics of a managed services solution around IdM that would make customers "comfortable". (In the past, I've posted on the "comfort vs. security" notion). Anyhow, some tasty nuggets are below. Go to the real survey findings for more.

• 67% of respondents have already completed a provisioning implementation (3% as SaaS, 10% have done it in some type of managed service offering, 37% have host and manage it themselves)
• When asked what model they would prefer, 19% wanted SaaS, a whopping 36% wanted an on-premise managed service, 19% wanted an hosted managed service model (that's a total of 55% who are looking for a managed service offering!), while only 13% want to handle it all themselves.
• When asked about what was the barrier preventing them from outsourcing IdM, 22% identified security risks around data being held outside of their infrastructure, 20% said risks regarding external people access their environment, 14% said cost, 11% said loss of control.

So, it seems that although most respondents managed it themselves, over half wanted a managed service model. The risk around data being held outside of their infrastructure could be alleviated by an on-premise model, although I don't think that the significant 20% who didn't want outsiders accessing their environment will be appeased by any solution.

A Few IdM Vendors Responding to the Market

Courion put out a press release today around their Jumpstart program for Password Management deployments. Undoubtedly not a coincidence given the market conditions. It's worth a look - 4 target systems, ROI in 30 days, fixed-price delivery. Not too shabby.

Also, Symplified has a webinar coming up entitled 'Scary Economic Times Heighten The Need for SaaS Security' with Jeff Kaplan: "With the current economic downturn pressuring enterprises to freeze capital spending on software and quickly find ways to lower spending on IT, the move to SaaS has never been more compelling. This has accelerated already rapid SaaS adoption in an effort to save costs and reduce IT spending."

I'm sure more to come....

More on IdM in the Economic Downturn

Over lunch with an NYC VC, conversations inevitably turned to the economy and it's impact on startups. A telling takeaway was that cost cutting in IT budgets is going to be deeper than previously expected. Gartner and Forrester until just last week stated that IT spend will grow less than expected (Gartner placed it at at 2.3% and Forrester at 6.1%). On the other hand, the gentleman I had lunch with stated that those predictions will most likely be changed dramatically, and that the number on the street is that cuts will be in the ballpark of 20%. Now given that typically 65% of IT budgets are dedicated to maintenance and upkeep, that leaves about 15% on the table for new initiatives. Ouch is right!

In my opinion, if IdM projects are to survive these cuts, it has to be positioned around 2 areas simultaneously: 1. The project has to be linked to core business and 2. Cost cutting capabilities. If the project can't rally around both, it's probably a gonner.

A good case in point is how salesforce.com made it through the 2000-01 scenario. It provided an easier way to do CRM (critical to core business) in a more cost effective way.

So the question is...who's going to be the salesforce.com of the identity world? Or from a project perspective, which initiatives will be able to survive?

A few random thoughts: I like SSO/Context Management in healthcare. Great impact on the business (especially for clinicians) and cuts cost. Password Management is pretty good, except impact on the business in most cases is negligible. The same goes for provisioning and role projects, although a better case could be made for impact on core business. Unfortunately, I think the new kid on the block, privileged access management is in trouble because of its positioning as primarily a security play. I'm still noodling this, but I'm sure this scenario will bring about some interesting innovations in our space in the coming year. Nonetheless, the forecast is pretty cloudy from where I stand.