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.

ESSO and Healthcare, in the Trenches (Part 1)

I've been involved in the early stages of a fairly large ESSO project as of late. Since it's been a while since I've been involved hands-on with a project, I've decided to write a short series regarding my experiences. The goal is to impart some practical lessons that a PM could use the next time they decide to undertake an Enterprise Single-Sign On project, with special emphasis on healthcare.

I love working with healthcare institutions. There's always hundreds of apps to support, disparate teams with fragmented goals, and pushy users with lots of power (clinicians). Sarcasm aside, its always interesting given the unique landscape.

Lesson 1: In-House Homework first, Hold Back the Vendors

The client had been embarking on this project for nearly two years. Out of the gate, they called every vendor under the sun to see which products fit their needs. The problem was that they didn't clearly identify their needs up front. The good news is that the client was smart enough to recognize their mistake. They put the vendor calls on hold (indefinitely), and decided to do some in-house homework. The client identified that improving the clinician's experience was their primary driver, which helped a ton with the steps to come (as I'll demonstrate in future posts). They followed this up with the following very intelligent steps:

* They garnered some serious executive sponsorship
* They completed a thorough application inventory


In my next post, I'll dive a little deeper into the two points above. Anyhow, this experience rang loud, especially in light of the recent storm of articles on KPMG's Identity & Access Management Survey findings (here, here and here):

"More than two thirds (68 per cent) of executives surveyed for KPMG’s 2008 European Identity & Access Management (IAM) Survey believe the effectiveness of projects is hampered because they put too much focus on technology and fail to address the organisational and procedural changes that are required. As a result, only a handful, (11 per cent) are fully satisfied with the outcome of their IAM projects."

Ouch...SIs better do something and quick. (I'm sure that KPMG has nothing to gain from that!)

Federation Woes

Techtarget has an insightful article on the difficulties surrounding Federation and its abilities to penetrate the market. Alot of the content arises from Burton Group's Neuenschwander, and his work on the topic. Neuenschwander eloquently sums it up: "Businesses have inescapable constraints and markets are brutally pragmatic."

Very true. In my experience, companies who may have a business need for managing authentication and authorization for externally facing apps more effectively with specific partners - BUT don't view it as absolutely critical for their business will opt not to deploy federation for two reasons:

1. The invasiveness of the technology vis-a-vis the partner's environment. i.e. the requirement of deploying a federation server in the client environment.
2. The legal ramifications involved as to liability and data ownership ("who owns the data associated with various identities and who has the final say when the data doesn’t agree") ... Phil Windley has written some interesting points regarding this.

I've dealt with a number of companies that were very interested in the technology, but decided to go with other, less elegant solutions because of the complications involved with these two concerns. On the other hand, when the business case is strong enough - federation is a wonderful solution.

A few years back when I got interested in federation, I was very impressed and was looking forward to aid federating the world. Unfortunately, it didn't turn out that way. As Neuenschwander stated... "the world isn't as it is in developers' dreams...businesses have inescapable constraints and markets are brutally pragmatic."