Man*ged *dentity Serv*ces, Trademarked!

I received the following email today from our friends at Fischer:

http://identityman.blogspot.com/2009/01/another-entry-into-idm-managed-services.html

Dear Ashraf Motiwala,

We note that one of your recent articles used the phrase "Managed Identity Services" This phrase is a trademark owned by our company and is also the subject of a U.S. trademark application examined and approved by the U.S. Trademark Office. When you use the phrase in your articles, please place the "R" superscript after the trademark, and please make a reference in your articles that "Managed Identity Service®" is a trademark owned by Fischer International Identity, LLC. In addition, you should use the trademark as an adjective, not as a noun. These steps will help us continue to protect our trademark rights and also allow you to properly refer to it in your various articles.

Thank you for your support and proper usage of our trademarks. If you have any questions, please feel free to contact us.

I see. It's all about trademarks (and grammar). For some reason, I thought it was about innovation and making the (identity) world a better place.

Anyhow, I wonder if they are going after Citi, Arcot, Wipro, and IBM. Wait, they barked at my blog...so I also wonder if they also went after Ian Yip, Felix Gaehtgens, Matt Flynn, Nishant Kaushik and Jonathan Penn. Anyone else get an email? or should I feel honored that they are singling me out because of the 6 readers who read my blog?

C'mon Fischer, you guys should really let the trademark go. The term belongs to the industry. Remember, trademarks don't buy marketshare.

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...

On SaaS Provisioning

Jackson Shaw posted some of his thoughts today on enterprise-class SaaS provisioning...

"If you consider an SaaS application as "just another application" you will understand that your end-user identities still must be managed in that SaaS application...We have a standard called "Services Provisioning Markup Language" (SPML) which was specified to help provision identities via a web service. Does your SaaS vendor support that standard? I'll bet they do not! What do you do then? I've met with hundreds of customers over the years and many are still struggling with provisioning inside the enterprise! Throw in SaaS provisioning - via some hairbrained interface because the vendor doesn't support SPML - and it only adds to the organization's identity management complexity."

I have to agree. The real pain point here is the connectivity into SaaS apps, and the lack of standards there. Ian had talked about this in a previous post. Recreating a workflow engine, role management, delegation, etc. in the cloud seems to just create redundancy for these capabilities, especially for organizations that have already dropped a few dollars to deploy an IdM solution on premise. Why would I drop my existing investment here? (Perhaps there is a compelling case, but I just don't see it.) I would much rather find a solution that proxies the SPML requests from my existing provisioning solution that handles all the complexities (or "hairbrained interfaces") for the SaaS apps on the backend! More on this soon...

DIY: Identity Management Project Scoping Exercise

-

Identity Management Project Scoping, Part I

Identity Management Project Scoping, Part II

-

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."

Virtual Directory Whitepaper

Oracle just put out an interesting whitepaper on how to use their virtual directory product with Sharepoint. A few interesting scenarios:

• Allow users to authenticate to SharePoint with Windows credentials but control access based on job codes maintained in a HR database (without having to sync!)
• Allow a SharePoint workspace to be used by two different business units who each maintain their own AD domain

On another note...sharepoint has been getting a lot of attention from the identity folks, hasn't it? Microsoft was promising a new "Identity Portal" in ILM 2, until they blew their release date by A YEAR(!!). Courion's been marketing their solution for Sharepoint as well, which is basically an attestation/segregation of duties play. Bitkoo has their fine grained authorization management stuff for Sharepoint.

I wonder why the trend? Hmmm....
Well, here's a billion reasons.

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.