Personal Fire Trucks and Overengineering Identity Solutions
By Clayton on May 19, 2008
So I noticed an odd headline in a news feed from the Chicago Tribune this morning: Neighbors seeing red over man's firetruck The gist is that a man purchased a fire truck on e-bay, built a garage near his suburban home for it, and engineered a solution to bring water from his pool to the rescue in the event of a fire. Note that there are 4 fire stations in the vicinity and a fire hydrant 1,000 feet away from the house. His take:
Quote from the Fire Chief about using this water:
"When you don't have hydrants, you need water," said Mitchell, 59, who does not claim to be a firefighter. "The peace of mind of having the water made my day."
What does this have to do with technology, and in particular, identity?
"That's really an option way down on the list," Gallas said. "It's available and if we ever needed it we could use it."
The number one thing that I've seen delay projects related to identity and directories -- as a customer, consultant, and software provider -- has been the tendency to over-engineer these solutions.
In the case above, the odds of a fire are relatively low. The odds that the personal fire truck will be needed is even lower. The odds that the water in the pool will be needed is lower still. By the time you're done looking at the real risk of this happening, you'll have realized that if you thought this risk was real you probably should have just bought some extra insurance, stopped smoking, and stopped cooking with grease (the later two being two of the most common reasons for residential fires).
Similarly, identity management projects need to be designed around realistic goals. These goals should include the right amount of availability and disaster recovery to deal with real business impact in the same way that business deals with other risks.
My favorite case of this tends to be around customers that present requirements for very sophisticated caching in order to circumvent real or perceived catastrophic disasters (complete loss of network connectivity to data sources, those data sources crashing, etc...).
What this tends to forget is that these underlying data sources are often used by many things. For example, if Active Directory goes down, can my users get to their workstations to login? If not, will they mind the fact that their web application can't login either? Similarly, if the database attached to my ERP system goes down and I can't pull their ERP roles, won't the impact of ERP being down be the element that I should be fixing, given that it will impact my company's overall ability to conduct business?
These are just a few examples. There are many more. Other personal favorites would include project delays and complications caused by over-active schema design and planning processes, connectivity to obscure systems that aren't actually core to the business, solving unrealistic and arbitrary latency "issues", etc...
I've mentioned the caching thing several times. Another popular one there is the idea that identities need to be cached for performance. Let's think about this:
- Your underlying directory will support thousands of requests per second
- Any good database supports that same neighborhood of selects per second
- Most databases, directories, and web services have ways of being made highly available if they contain important data
- Actions such as termination require rapid removal of privileges
- There is no standard way of detecting changes (for #4) from arbitrary databases and web services that wouldn't require additional complexity.
- You're probably using #1 and #2 for other, business critical things