On Developing a Deprovisioning Policy

An interesting discussion emerged out of a blog entry over at the Identropy blog on developing a Deprovisioning Policy.

I've reproduced both the contents of the blog and the comments section (which is probably more interesting than the article) below. Enjoy!

----

Identity Management technology can be tricky. But in most instances, it's not the technology that trips up an implementation. It's the policy development (or lack thereof) that causes the heartache.

Deprovisioning Policy is typically more complex than a simple policy that states that when HR says a person is terminated, the identity system terminates the user's access to all systems. Here are a few things to consider when developing your Deprovisioning Policy.

1. Deprovisioning Policy (Technical View)

The technical view of a deprovisioning policy is concerned with what the identity system should do once we know that the user should be deprovisioned for each target system.

• Should the user's account be hard deleted or just disabled?
• If disabled, how is that done? (Move the AD account to a disabled users OU, place the row into an archive table, etc.)
• How long should disabled users be kept in the system?
• What should happen to the person's shares, mailbox, etc.?
  

2. Deprovisioning Policy (Business Process View)

The business process view of a deprovisioning policy addresses the states that should trigger a deprovisioning action. Here are a few questions to ask your policy team:

• How do we calculate the actual last day a person should have access? Is there an effective date that can be used? Is HR using that field properly?
  
• How should 'leaves of absence' be handled?
• What should happen if a person wants to use his/her vacation days directly before retirement? What if the person may still provide off-site help during this time period and therefore needs access?
• How should sabbaticals be handled?
• Should a user's current access be terminated in a department transfer? What if they still need their old access for some time?
  
• How should unused sick days be taken into consideration?

3. Take Compliance Policy into Consideration

Besides the business process view of the policy, sometimes existing regulatory compliance rules may have an adverse impact on an otherwise sensible policy. For example, definitions of 'termination', 'employee job role change' and 'leave of absence' will directly impact the overall policy and should be taken into consideration.

By thinking through these issues, an effective Deprovisioning Policy can be put together prior to implementing an IAM solution.

----

Comments:

Hi Ash, my suggestion (as always with IAM related decisions) is to start from the business view and try to stay out from the temptation to start analyzing the event from a technical standpoint.

Using business as starting point can be very helpful for example in fragmented, complex or very dynamic environments where could be very hard to find a common agreement on the right behavior to follow and where, probably, it can give you also a longer-term solution.

What do you think?

Posted @ Tuesday, April 13, 2010 7:10 AM by Luca

Hi Luca,

Interesting point.

From a policy standpoint, both sides (biz process view and tech view) have to be defined. And although the business process view (i.e. defining the states of the user should trigger a decommissioning of the user's access) is critical, the policy would simply be incomplete without the tech view.

From a dependency standpoint, I really don't see that one piece of this is dependent on the other...(although I'm still thinking through it). It's almost as if both sides of the policy can be developed independently.

Thoughts?

Posted @ Tuesday, April 13, 2010 11:13 AM by Ash Motiwala

Ash, for sure both sides (biz process view and tech view) have to be defined. My suggestion is to avoid developing them independently and where possible to start from the business view and requirements and understand how those requirements can be fulfilled from the technical standpoint.

My idea is based on two main assumptions:

1) Technology should support business and so we should start from it and try to define the best suitable tech solution. So, is it possible to keep them independent?

2) Deriving technical view from business view allows to have more stable policies because in my (very very short) experience I’ve saw more stability on the business requirement than that on the technical one. Technical side of policies could be more fragmented, detailed and sometimes system dependent and for this reason more subject to modifications when changes happen in the technical infrastructure (mergers, new systems, etc.). In my opinion, this approach allows to keep unchanged business view and most of the decisions related to the tech view.

Are, in your opinion, my assumptions valid?

Posted @ Wednesday, April 14, 2010 2:47 AM by Luca

Hi Luca,

I'd agree in general that business process development should happen before technical analysis, (as I've mentioned in other articles here).

In order to think through this, I posed myself the following: should the following 2 questions (1 business process oriented, the other technically oriented - as defined in the article) be answered in a specific order?

1. Should a leave of absence translate to termination of access?
2. What should happen to a person's shared folder contents once terminated?

Thinking through this, the 1st question should be posed to the business process owner - whose answer will provide context to the technical owner to answer his part of the question...since a leave of absence (as a state) will probably have a direct impact on how long to hold on to a person's mailbox or shares. And will probably have a different impact on a person who was terminated for cause.

So yes...I agree. Thanks for the insight, Luca!

Posted @ Wednesday, April 14, 2010 5:42 AM by Ash Motiwala

Identity Services, SaaS, and Another Matt

Matt Gardiner over at the CA blog makes some interest points regarding identity services and SaaS. (I'm a new reader of Matt's blog, and want to personally thank him for adding yet another Matt to the list of identity bloggers I have to keep up with. What's up with identity bloggers and the name 'Matt' anyhoo?)

Matt questions the value/feasibility of providing identity services in a Software-as-a-Service format, since there's a difference between apps and infrastructure. Infrastructure, he argues, must be "appropriately integrated into the enterprise premises and processes". He continues to argue that identity services in a SaaS format can't ignore on-premise apps in favor of identities in the cloud, and mentions the traditional concerns around "outsourcing" compliance and security.

Ironically, I had an interesting conversation just yesterday with an industry colleague regarding the exact issues mentioned by Matt, where he presented some new emerging paradigms in the 'Identity as a Service' world, including what he dubbed "Enterprise Looking In" and "Enterprise Looking Out" (more on this in future posts). Here are a few questions/direction for the conversation (more questions than direction)...

• Let's nail down the definition of 'identity services'. If not for the industry at large, at least for this conversation at hand. In my opinion, a lot hinges on that.
• Is the notion of 'Identity Services' in a SaaS format an either-or paradigm for on- and off-premise apps?
• Can technology help blur the internal vs. external line? Does this lead to a new category of infrastructure?

Matt does acknowledge that he sees the opportunity for some areas of identity to be outsourced. Perhaps this conversation could help clarify what areas in specific...

FUD Swings Both Ways

Salesmen are an interesting bunch. They have to drink the company kool-aid to enable them to sell with conviction. But what happens when a salesperson starts to waver in that conviction? What happens when they start losing their religion? Fear-based selling! Easy peasy!

Since I noticed that my last post on FUD based selling and Vendor Selection was being used to spread more FUD (with Oracle being the victim this time), I decided to do my part to rid the world of keep-the-client-ignorant tactics and try to put the facts out there. It's interesting how fear always finds a home ("they're too small!" vs "they're too big!")...anyhow, here goes:

• In a solid article by techtarget, Jonathan Penn points out that customers have no need to panic today, and that Oracle will have the resources to support both product lines for a while, noting that it has continued to support the ERP products of both PeopleSoft and JD Edwards following its 2005 acquisition of PeopleSoft.
  
• Instead of spreading fear, let's spread facts - namely regarding Oracle's track record with acquisitions. Siebel hasn't gone away. Also, Oracle now supports multiple app servers with the BEA acquisition. (Someone else may want to chime in on this since I'm not an expert, but remember: facts over fear!)
• Anectodal evidence: a casual conversation with a VP at a financial firm uncovered that in the past years, Oracle has acquired nearly all of their major systems, effectively turning them into an Oracle shop. The result? Fear and mayhem? Not really. In fact, Oracle offered up a free inventory analysis from Oracle Consulting to guide the client to maximize their existing software investment and determine how they might benefit from updates resulting in tighter integration between systems (although the client stated he would have opted for a deal on maintenance).

That's my $.02, and I hope it moves the conversation away from fear and closer to the facts. And although I know I didn't cover all the facts and I welcome folks to chime in with their side, the point should NOT be boutique vs. large vendor, large vs. small, red vs. twitter blue, but simply the product's capabilities to "scratch your itch", as Dave Kearns put it. Remember this, young salesman: Sell your product, not fear, for FUD is the path to the dark side. FUD leads to anger. Anger leads to hate. Hate leads to suffering.

A Story About Vendor Selection and FUD

The shocking (at least to me) story of Oracle acquiring Sun yesterday made me think about an experience I had helping a client in the vendor selection process late last year.

The client was seeking an identity solution, and with our help, reduced the vendors to Sun, another large vendor and a small boutique vendor. After their demos/POCs, the vendor scoring matrix we helped them put together showed that the boutique vendor actually ended up with the highest score.

After some great FUD work from the sales folk, the client decided to add a new metric in the matrix for Company Viability. All of a sudden, Sun came out on top...and the solution was purchased and implemented. The whole reason the boutique vendor lost out was because of fear and the likeliness of acquisition or failure, etc.

A few months later...Sun is on the block, and finally inks a deal. Now I'm hearing that the client is worried about the direction of the Sun product line post-acquisition, because of the heavy overlap between the Sun and Oracle product lines. (And also worried about what Oracle will do to Sun's open source initiatives.)

Now the smaller vendors are having their say (and they should). Here is an interesting perspective from a Network World article:

"Figuring out what stays, what goes, and integrating the remaining pieces is going to be an enormous task that will undoubtedly create consequences for deployed customers," says Andre Duran, CEO of Ping Identity, which develops identity federation software. "This is yet one more reason companies should consider standards-based, loosely coupled approaches, as it insulates them from the potential for single vendor lock-in, which is occurring irrespective of how they are selecting their vendors."
...
Blakley says as the deal closes, Oracle management likely won't address identity until the more compelling strategies, such as the database, are worked out. "So there will be a period where not much happens and it is business as usual."

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.

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.

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?

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?

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.

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.

Selling Identity in an Economic Downturn

Rough week. And it's Tuesday. In the wake of the current financial crisis, I've received 3 phone calls in the past 3 days from potential customers (who were almost surely moving forward with an Identity Management deployment) to tell me that the project is in serious jeopardy. All three happen to be in the healthcare sector. One of them was given a mandate to cut $1m from his budget. Another simply stated that all new initiatives that haven't been inked yet are frozen indefinitely. The third stated that their organization's revenues were deeply impacted because of cuts in Medicare/Medicaid, and any and all projects not directly related to core business will be cut.

I've been able to position the projects to be possibly salvaged by quickly shifting drivers from compliance to ROI and cost avoidance opportunities. Thank God we're in an industry that supports multiple and varied drivers! I think that trying to sell Identity from a compliance and security angle in this environment is just a lost cause, which will probably impact the types of technologies that will be deployed. Any thoughts on other business/tech drivers that might be used? Which types of identity projects will live and which will die?

Why (most) Identity Management POCs Suck

For those unaware, POC is an acronym for "Proof of Concept", and consists of a client requesting a vendor to bring their software in to demonstrate ("prove") that their software can perform in their environment as promised ("concept"). The engagement usually lasts for a few days to a week, and typically the vendor foots the bill (if the potential deal is large enough). Most often, POCs are borne out of a conversation between a client and an industry analyst who completed a 2 hour identity management market briefing, concluding that it would be a good idea for the client to host a POC. A few vendors are selected to strut their stuff, and after reviewing which vendor did a better job, a winner is hailed and ultimately awarded the contract.
After being involved in one too many POCs, I've come to the following conclusion: IdM POCs suck. Usually. And here are a few reasons/scenarios that explain why:

1. A typical POC is just a glorified demo. So, wisdom states that if the vendor is integrating their software with your target apps, then it's not just a demo, but undeniable evidence that their software is good for you and your organization. That is both true and false. Just because software can be made to "seem" to work with your apps is not evidence that the integration is robust or production ready. Hacks are very common in POCs, and a lot of what is demo'd at the end of the POC is a lot of smoke and mirrors and doesn't prove that what was completed is production ready, or more importantly, can ever be production ready.

2. The success of the post-POC demo is highly dependent on 2 individuals on the vendor team: the Sales Engineer (the guy who duck-taped together the POC) and the POC-demo-guy. The vendor that has the best duo typically wins the deal, which may not reflect the best software solution for your environment. A good SE can make crappy software work (with his arsenal of scripts and tricks), and a good POC-demo-guy can bedazzle almost any audience. On the other hand, a bad SE can make good software break, and a bad POC-demo-guy can put a lively audience to sleep.

3. A POC is typical technology focused. Most IdM deployments are business process centric. When decisions are made based on the number of out-of-the-box connectors or the long list of supported standards without considering how it all applies to your specific set of business processes, the wrong vendor can be selected.

Well, I'm sure there are more reasons, but I'll leave it at that for now.
But the picture isn't that bleak. There are ways around the problems above, and exciting approaches that will not only make POCs not not suck, but actually make them effective and useful...a topic for another blog entry.