Clayton Donley's Blog

Pitfalls in Moving from Services to Software

Wed, 01 Oct 2008 13:03:24 -0800

Got a lot of positive feedback on my post from yesterday about some lessons learned while growing OctetString, so will write a few more articles along these lines...

Given that consulting billing rates and hours go down in tough times, many consultants will undoubtedly decide to build businesses to "product-ize" some of their solutions.

This is completely possible -- our own Oracle Virtual Directory started out that way, as mentioned yesterday. Some of our best partners were started this way as well.

However, there are a number of common traps that consultants fall into when they enter the software business.

1. Repeatability, not complexity...

Repeatability in software gives you the ability to scale your customer base.

Consultants often work in the role of car mechanic -- look under the hood, find scary problems, suggest some solutions that will require parts and labor, and finally plan and implement that solution. Each customer has a new problem requiring different parts, plans, and execution.

Software is a very different business. You're looking for as much commonality as possible between customers so that what is delivered can be repeated at other customers with the minimum possible effort.

This doesn't mean that you can't solve complex problems or require services to implement. It simply means that the product-ized part of your product shouldn't be different for every customer.

It also goes without saying that building your software on standards-based middleware will help reduce the amount of post-sales time spent doing customized integration with each customer.

2. Don't design around one big customer...

Even companies that don't originate from consultants tend to fall into this trap a lot, but consultants do it almost every time because they tend to be solving a problem that they encountered at a particular customer.

It is wonderful finally finding a customer or prospect who will spend a significant time helping you understand their requirements. You should certainly listen to them -- they are the customer, eh?

The trick is to use that customer to validate your approach rather than try to solve every esoteric problem that the customer might have through your software.

You might consider providing extension points, allow for customer designed templates, and so forth to accommodate their needs without building less repeatable stuff into the product. You'll also want to consider that your product may not be the right place to solve a particular issue.

3. Consulting isn't Software Sales

Many consultants have great people skills. They can help customers understand complex technology as it relates to the customer's own environment. Customers often base decisions about technology purchases in-part on recommendations from expert consultants.

However, this doesn't always (or even often) translate into being able to actually sell software. Not that you can't learn to do so, but the process of selling is very different from the process of pitching a solution as a consultant.

As a consultant, you have high credibility in part due to your independence. As a vendor, that credibility is diluted to some degree, even when you're still trying to help the customer do the right thing to solve their problems.

The overall process goes far beyond what you say and how credible you are with a customer. You're going to need to educate yourself and bring in the right people to help you be successful.

What happens when you don't know what you're doing?

A (now) funny story from our very first sales call (with Fannie Mae, oddly enough) back in early 2001 before we hired our first sales person or took the time to better understand the sales process:

I was on the phone with the customer while another person from the company was acting as the "account manager". Nobody is in the same room. The customer's first question: "What does this solution cost?" Oops! We hadn't priced it yet and hadn't discussed how we would handle this question. After an uncomfortable silence, the customer's question was answered (after a flurry of background instant messaging).

Thankfully we got better at this with time, brought in people that had experience selling enterprise software, and things worked out well.

I should also point out that the very first customer we did end up selling to was BEA Systems. This is why a portion of Oracle Virtual Directory's original 1.0 release is actually embedded in every copy of WebLogic 7.0 and above.

Start-ups in a Down Market? Absolutely...

Tue, 30 Sep 2008 14:33:05 -0800

Many of you know that I came to Oracle through the acquisition of OctetString. You may not realize that I co-founded OctetString in early 2001, which was during the last downturn. In fact, we were negotiating our first software sale when the 9/11 terrorist attacks occurred.

So I read with great interest Jason Calacanis's email (and blog post) discussing how startups can better survive an economic downturn. Given that he too started his last company (WebLogs, acquired by AOL--think Engadget) during the last downturn, he's got very solid advice. I don't agree with a few specific items (never had a reason to test dedication with Sunday morning meetings), but overall a great read.

I thought I'd share a bit of advice and a few tales from that same period of time, but in the enterprise software space.

When we first started OctetString and created what is now the Oracle Virtual Directory, we had a number of pre-baked customers that were lined up to buy our software. Unfortunately, most of these were telco customers and by mid-2001 our phone calls weren't simply finding people who had been pink-slipped, but entire divisions that had been abandoned and certainly weren't going to be buying software from us anytime soon.

What kept things going was pretty simple:

1. Keep costs low -- especially recurring

While all expenses should be reviewed, you're going to want to pay particular attention to things that are recurring, including people, rent, etc...

When we needed hardware, I just made a trip to the local liquidator. HP-UX server: $800. Solaris box: $995. A bit like going to a junk yard and not as glamorous as handing over a check to your local rep, but it works.

Until almost 2003 we didn't even have an office, and even then I just used a Regus facility in order to share some common services with other companies (and not worry about anything related to maintaining the office itself). Not to mention the lease was relatively short-term (and I loved their coffee machine).

2. Retain an insanely dedicated core group

Jason makes this point and mentions seeing who shows up for a Sunday morning meeting or such to see who's dedicated. I think you'll know who the right people are even without having to test them.

These people won't care about fancy offices or silly perks. My first sales guy closed a critical deal with Pfizer in the United economy class line at O'Hare Airport on the way to Germany. Another critical deal with Coca-cola was closed in a phone booth at University of Illinois while a kid was breaking up with his girlfriend in the next booth (it's not you, it's me). Not having an office or business class for international trips didn't seem to stand in the way of his performance.

Others were equally (and probably more) dedicated. In the earlier dry times it wasn't uncommon to be deferring paychecks.

3. Make something people actually NEED -- particularly during bad times

When we started the company, we noticed that most enterprises were still doing multi-year projects to consolidate and synchronize all of their user repositories with a technology called "meta-directory".

The underlying need was to get all user information into a single place for portals, ERP, HCM, CRM, and related business applications. These are big, important applications and every one of them needs information about usernames, passwords, roles, department numbers, reporting hierarchy, and so-forth to function.

This may seem trivial, and today using software like Oracle Identity Management it's a lot easier, but at the time it was a black art requiring lots of consultants, lots of software, and Big Dig style project timelines (and success rates, unfortunately).

We simply shrank many of these projects from years to days and the results couldn't be ignored.

One particular customer implementing a CRM solution with a lot of consultants estimated that they saved something like $10m in consulting over-runs alone.

You have to be having a huge impact that can't be ignored simply because you're not the right vendor. This is especially true when times are tight and customers become more conservative. Customers know that a lot of smaller vendors won't make it and don't want to be stuck with abandonware.

Looking forward to comments. Thinking to do a few more posts on this topic if there's any demand.

Presenting Security Exceptions to the User

Tue, 19 Aug 2008 11:08:11 -0800

There is a post today on Pingdom talking about the new Firefox SSL error page that appears when you try to connect to a site with a self-signed or invalid certificate.

As you see in the image above, it actually doesn't show the page you're going to until you explicitly allow it as an exception.

Pingdom goes on to talk about how this can create a lot of issues (particularly for internal sites), but then goes on to estimate that 18% of Fortune 1000 web sites would be affected my this.

Much of my comment on the laws of identity yesterday were related to the user experience and how we need to look at how users really use their computers and identity to understand the best real solutions to identity problems.

The question here is whether Firefox is over-warning. I would argue that it isn't. SSL with valid server certificates is one of the most basic steps a site can take towards being secure. Just because the US Army site above isn't using a valid cert and many other large companies neglected to update their certs doesn't mean that Firefox shouldn't be aggressive in its warning.

This is similar to the experience many of us had with white page directories in the 90's. At first the data in them was highly inaccurate, but once people started using them to find you or authentications were hooked into them, suddenly you couldn't work with inaccurate information and were motivated to fix the problem.

The same thing will happen here with these sites. Unless they want the millions of Firefox 3 users to be put off, they'll upgrade to this minimum level of security. Once they have, the exceptions will look particularly outstanding and be an instant red flag that a site might not be what it seems.

Technorati Tags:
security

Revisiting the Laws of Identity

Mon, 18 Aug 2008 14:50:22 -0800

Kim Cameron of Microsoft just reposted a shortened version of his laws of identity.

I really didn't comment much when these were first being developed, though I recall being at a number of forums and conferences where discussion about them took place.

While they've gotten a lot of focus at times, I have my doubts about how important and practical some of the "laws" are. Rather than just parrot the laws, I thought it would be useful to discuss these possible issues and see what others may have found that either mitigates these issues or bring them to focus.

Here are the shortened laws in bold and my take on them:

1. People using computers should be in control of giving out information about themselves, just as they are in the physical world.

There are two ways identity information gets populated and shared:

1. We put it there, or

2. Someone else put it there.

We can all control the first path. I can choose to fill out your web form or not based on whether I will exchange elements of my personal information for the value that you are providing.

For the second path, we use enterprise systems every day where the systems in use have some existing knowledge about us. Marketing databases are bought, built, and sold every day -- often by the same publications that will actively run shrill articles about how your privacy is being invaded at this very moment.

In effect, often times once you've done #1, it's hard to prevent #2. You can give a web site the technical ability to reduce #2 and actively enforce a stricter privacy policy, but the reality is that the Web 2.0 world is often driven by "free" content and services that will drive more, not less, of this collection and sharing.

2. The minimum information needed for the purpose at hand should be released, and only to those who need it. Details should be retained no longer than necesary.

Nothing wrong with this particular ideal.

For example, when I get mailings from third parties as a subscriber to Harvard Business Review or TheStreet.com, they are always sent by those entities, not directly by third parties -- or at least they appear to be.

In general, this is actually a good business practice. Oftentimes the data you're collecting has proprietary business value in itself. If your business has made the decision that you're willing to part with it, you're highly unlikely to worry that there's a law of identity related to this.

You might be a little worried if there is a REAL law related to this. It's not like hospitals can go around selling lists of patients to drug companies. This is where privacy laws come into play.

3. It should NOT be possible to automatically link up everything we do in all aspects of how we use the Internet. A single identifier that stitches everything up would have many unintended consequences.

So I guess I should stop using FriendFeed, Facebook, and LinkedIn, eh? :-)

Ok. I know that this isn't what's really being said here. What's really being said is that using a shared identifier across a large number of systems allows people to know things about you that they shouldn't.

True. That said, this is hard to do within an enterprise. Are we really on a path for convergence across the vast Internet?

4. We need choice in terms of who provides our identity information in different contexts.

All of the references to control remind me of how most Windows firewall products work.

Basically I click on an application or link and get a pop up window in the lower right corner of my screen that says something like this:

"Application XYZ is attempting to access the internet to connect to 192.168.1.5 on port 848. Would you like to allow this? YES/NO"

The one thing all users learn quickly is that if they click YES, the application works. If they click NO, it doesn't. After a while, the pop-up is just another annoyance for the user such the actual applications, hosts, and ports aren't even noticed.

Now translate this to most web applications where if I click YES, some amount of information is shared and I can access what I want. If I click NO, nothing is shared, but I can't get access. What do you think the typical user will do? Do users read the EULA and privacy terms before they click?

And keep in mind that if we automate the process of entering all of this information by keeping it on a electronic card, they'll actually notice even less about the information that they're sharing because they won't be entering it. It'll become Yet Another Dialog to Accept (YADA?).

5. The system must be built so we can understand how it works, make rational decisions and protect ourselves.

6. Devices through which we employ identity should offer people the same kinds of identity controls - just as car makers offer similar controls so we can all drive safely.

It's hard to disagree with these last two points. They're very attractive points and give the users a lot of control.

I do like things such as the new Firefox address bar, which actively help me figure out whether I landed where I intended:

I also like the auto-form fill-out functionality in most browsers that makes registering for the myriad of sites easier.

Combined, this lets me know that I'm sharing my information with the entity I think I am and can visibly see and adjust the information I'm willing to share.

What's missing here is user education. A year ago, you had to look at the link you were following and know the structure of a URL to understand that you were being phish'ed...or just not click on anything. Incremental enhancements, such as those in the address bar, give us a path towards training users to avoid these negative situations without requiring them to be geniuses.

After you've verified that the vendor in question isn't fraudulent in itself, the question becomes whether you want to give the information requested.

Portable identity is probably helpful here, but if I were an enterprise I'd be more focused on the back office.

Just as it's a bad waiter that stole your credit card number and not an evil plot by TGI Friday's, it's not the intent of most organizations to actively compromise private information.

The difference here is that instead of a handful of credit card numbers, we're talking about whole repositories of data.

This may be an identity management problem (e.g. user with too much access and not being audited), but it's just as likely to be a data management problem, backup security process problem, or other issues that can lead to massive insider compromise (accidental or intentional). If you're not solving these in a concerted way, it won't matter much what your privacy policy is except for any liability you've created for yourself.

In Summary...

Not saying that the laws of identity lack value in the real world. Not saying that users shouldn't control their destiny.

Am saying that we need to be careful to ensure that these laws line up with the reality of how people use computers and that the embodiment of the laws doesn't open up additional risks, while keeping us from focusing on systematic risks that might be taking place behind the browser in or applications, middleware, databases, directories, and back office systems.

Technorati Tags: identity management, privacy, security

CNET: Oracle is grabbing a lead spot in identity management

Fri, 25 Jul 2008 10:45:45 -0800

If you had any doubts about Oracle as a player in the identity management space, this short article from Jon Oltsik on CNET summarizes the situation.

Once again, common wisdom was completely wrong. While others struggle or abandon this space, Oracle has vaulted to a leadership position. In fact, my sources tell me they see Oracle in every large deal these days.

I'll let you read the rest for his summary of how why this is the case...

Technorati Tags: identity management

Where does he get that wonderful identity data?

Mon, 21 Jul 2008 12:03:41 -0800

Finally getting around to participating in the latest stream of blog postings following up the "meta-directory is dead" and "daddy, does Active Directory grow on trees?" discussions...

Nishant has already addressed some of these comments in his post from July 16. Mark has hit on other items in his post on the same day.

Now you just have to wait until Ian boils this down to a single sentence again and Dave Kearns finds me secretly agreeing with Kim Cameron on something and the discussion will have come full circle. :-)

James McGovern - July 13

James wants to know 5 things (paraphrasing and with my replies embedded):

1. Why shouldn't we all just put our identity eggs in Microsoft's basket since everyone already has some Microsoft?

[CLAYTON] If you consider that most companies also have Oracle databases and most of the information you'll be needing for fine grain entitlements (meaning the stuff beyond username/password) is stored there, shouldn't this question be why you're not putting your eggs in an Oracle basket?

[CLAYTON] Or better, yet, most of you are using some form of Oracle application (HR? CRM?) to master things like reporting structures, department-based groups, cost centers, who's purchased what product, and so forth. If we're going to pick de-facto standards based on existing deployments, why stop at the directory niche? This information is all coming online with web services and ultimately via identity services.

[CLAYTON] I'm using these examples to demonstrate that very little reusable enterprise information outside of username, email, and some groups are mastered in Active Directory. Sure, some people do use it for more, but it can't be counted on...

2. Are current provisioning products too dependent on central sources?

[CLAYTON] Not to my knowledge. I think it's the opposite. They assume that you don't have a central source...at least ours does.

3. Should virtual directory technology be embedded in new software or stand-alone?

[CLAYTON] We're doing both. We know that nobody will rewrite the old stuff, which needs to work in new identity environments. We also know that some vendors will just never get identity. On the other hand, with Oracle products the push is definitely to at least include a base level of virtualization to improve open-ness.

4. The ideal solution is for people to just write better apps and avoid using virtual directory.

[CLAYTON] Agree. I'd like my car to stop using gas, too. :-) Until that date when every app gets there, we've got virtual directory. We'll continue to publish our own best practices and tools via Liberty Alliance's IGF project and enable our own applications to take advantage of mixed environments.

5. Why aren't more people talking about CARML?

[CLAYTON] There's not been the kind of controversy that sometimes keeps things in the headlines. Quiet progress, if you will. VERY good and impressive progress, though. I think you'll start hearing more about this, though hard to tell if some of the more system-management focused vendors you mentioned will be at the forefront here. After all, most of them don't even have (or understand) virtual directory yet...

Jackson Shaw - July 15

I'll visit some of Jackson's other comments in another post, but wanted to address this part, which goes with James' question #5 above:

What's CARML? Can someone explain it to me? Certainly, until Gartner says it's important I won't be thinking about it... ;)

I'm very glad that Jackson puts his full and total faith in Gartner, because as we all know, the latest Identity Management Magic Quadrants look something like this:

Oracle -> Leader

Everyone Else -> Not So Much

Forester is pretty much in the same boat. So I guess you can all just make those checks payable to Oracle. :-) Joking aside, while I love a nice roll up, especially when they're in my favor, the truth is that things aren't always what they seem.

As I said, I'll drill into his specific comments in my next post.

Jeff Bohren - July 21

I'm in pretty awesome agreement with Jeff that the problem is in the apps that are out there today being account-centric vs. identity centric. Not to mention his experience with Active Directory deployments:

To answer the rhetorical question, the vast majority of AD deployments are not intended as identity stores (at least from my experience). In most enterprises AD is used to manage and control user access to Windows workstations, the intranet, email, and enterprise web applications. AD is not usually intended as a central repository of identity, although it often becomes that with varying degrees of success.

Of course, the hard question is how do you solve it, eh?

A few commendable vendors such as SAP support SAML, but it’s a very small list. Support for external identity services or other identity standards such as SPML and XACML is nearly non-existent.

Wow. Those are the most glowing words I've ever heard about SAP's efforts in the identity realm -- ever. Certainly not the kind of words I'm used to hearing from analysts. :-)

SPML certainly isn't a cure-all. XACML helps and we've got a strong product and even better strategy in this area, but it comes down to application adoption. This is certainly why we're building key integration with fine grain authorization into the platform stack as much as in stand-alone products.

Technorati Tags: directory, identity management, LDAP, meta-directory, virtual directory

Ian Yip Just Saved You 3 Hours - Metadirectories are dead?

Tue, 08 Jul 2008 19:36:38 -0800

You can read the 18+ blog postings covering all of the recent discussions about how dead or not-dead meta-directories really are.

Or, you can read Ian's post that summarizes this whole discussion and save those three hours to line-wait for your iPhone 3G.

As for his conclusions:

1. Use the right tool for the job - Sure. Hard to argue with that.

2. There's room for provisioning, meta-directory, virtual directories, and directories - Sure, all the tools are available, but if you look at most meta-directories, the trend is still to try to make them more like provisioning tools. Not sure why you wouldn't just pick a tool that's already where you want to be.

3. Go with a service oriented approach - Our strategy here is certainly to be more application centric vs. more system management vendors and I think that's shown well when it comes to tie-ins with SOA and serices in general.

4. Meta-directories aren't dead, they're evolving - I agree, but see them evolving more into provisioning tools than virtual directories. This is already happening. I like to think that meta-directories aren't dead in the same way Monty Python's black knight isn't dead, but the reality is that they're trying to get where we already are. :-)

Running Orace Directory Manager on Your Laptop...

Tue, 08 Jul 2008 18:34:21 -0800

Dan Norris just gave me a heads up on Twitter that Peter O'Brien from Oracle in Ireland posted a short "how-to" for running the OID Directory Manager client on a machine that doesn't have a full copy of OID (e.g. your laptop).

Get it here.

Directories vs. Virtual Directories? Really?

Tue, 08 Jul 2008 12:18:05 -0800

Still picking my jaw up off the floor from this comment from Alex @ the ApacheDS project on Jeff Bohren's blog.

Seems Dave Kearns noticed it as well. :-)

So for those of you worried that Jeff and I might never agree on anything, you can put your worries to rest. Jeff's response is right on target...

Being that I'm responsible for both our OID and OVD product lines here at Oracle, I see first-hand that our customers are seeking very different things from directories vs. virtual directories.

With directories, it's all about data management. How can I scale and manage a repository that can store all of my identity information with the same kind of security that I get from my transactional data.

With virtual directories, it's much different. It's about lightweight integration, minimizing infrastructure changes, minimizing code changes, reducing project risks, and providing the flexibility that helps make both application deployments and identity management deployments successful.

It's not either-or, it's 100% complimentary.

Oh, and I'm wondering if Alex's comment means that I should be saying I'm sorry to my customers for solving their problems without ApacheDS's forthcoming "real" virtual directory. :-)

Re: Meta-Directories Not Dead (They're Aging)

Tue, 08 Jul 2008 11:50:52 -0800

Some of the points that Matt Flynn raises in this post were addressed in Nishant's reply. However, I wanted to spend a little time on this part of his post:

... There has been a ground swell of apps that directly support Active Directory as the user store. So, maybe the next versions of the HR and LOB apps in the above scenario would attach directly to AD eliminating the need for any solution here. As prevalent as AD has become, that seems more likely than mass-consumption of virtual directory technologies. ...

What's more likely: 1. everyone standardizing on Active Directory, or 2. everyone not standardizing on Active Directory.

Requiring Active Directory means everyone needs to be using Active Directory for everything. Using a virtual directory places no such requirements on the customer or application. It actually REDUCES the need to have a single, unlikely, unified standard.

This is the case because virtual directories emulate what applications expect from many existing directories. This means it's less about writing to a "virtual directory" than writing to your favorite directory standard and having the virtual directory emulate that in a view.

Not going to argue that the LAN guys have a lot of Active Directory sitting out there. Some of it is very strategic, other times it's used only for workstation authentication (and often outsourced to the people managing desktop user populations).

But there's also a lot of portals using Sun. Lots of databases and applications (e.g. eBiz Suite) using OID. Many people are even using Novell. Plus, even the topologies being used for Active Directory in a company often aren't predicted well by people writing off-the-shelf enterprise applications.

Simply "move everything to Active Directory" rarely works except in the smallest of organizations that will rely entirely on a Microsoft stack (no Java, no other directories, no non-Microsoft compliant infrastructure). Basically Microsoft lock-in.

This isn't to say that Microsoft can't be your strategic enterprise directory, or even extranet directory. But expecting every application from every vendor (including your legacy applications written before Microsoft even had a directory) to suddenly not just support Active Directory, but YOUR DEPLOYMENT of Active Directory is pretty unlikely. And it's exceptionally unlikely that everyone in the world will do so at that precise time as well. :-)

Customer Example

A simple example from a customer a few years back:

- 100% Microsoft Active Directory
- 100% ADSI-enabled application

Unfortunately:
- Global replication with a nasty replication delay (30 minutes)

This meant that if a user (traders in this case) changed their password, it might not get to all of the domain controllers until 30 minutes later, meaning that the traders would be unable to login to their application.

Clearly this wasn't foreseen by the application developer as a possible issue. The real solution may have been to completely re-architect their Active Directory environment in a different way, but you rarely have that luxury in the middle of a fire-drill.

What did the customer do? They spent a few hours installing Oracle Virtual Directory, configuring it to know about their domain controllers, and basically said that when a password failed, try it on the master. The master only sees these requests in "exceptional" circumstances and the replication delay has no material impact on the user's experience.

This provided time to come up with a more strategic solution to the problem. Having ultimately solved the underlying problem, the customer went on to deploy the product for other purposes (better loadbalancing and failover, etc...).

Is Connecting to Multiple Directories Really Easy?

Tue, 08 Jul 2008 10:58:06 -0800

Back from vacation and finding a whole army of people writing about virtual directory while I'm gone.

Working backwards, I saw the following quote from Jeff Bohren in his entry about vendor independence in response to a few posts from our own Nishant Kaushik:

BTW, having written code that supports multiple LDAP vendors at four different companies and three different programming languages, it’s really not all that difficult. The real power in virtual-directories is the ability to consolidate data from disparate sources, not abstracting the vendor for a single directory.

Having written similar code, I'll agree that some of the basic differences are pretty easy to navigate (differences between attribute names, for example). However, others are much, much more difficult.

Some examples:

Active Directory returns groups larger than 1000 members in ranges. Other directories don't. This requires significantly different logic.
Authenticating to Active Directory without Kerberos doesn't (or didn't) trigger actual logins, meaning that doing simple binds wouldn't respect bad password counts, etc...
Account lock, account controls, password policies, etc... are completely different between directories
Setting passwords is very different between AD and other directories

Now add in issues with using basic LDAP to navigate multi-forest AD environments, mixed-vendor LDAP environments, access to databases and web services, etc... and the requirement that applications would need to hit each of these...

Now you have a picture of why virtual directories are so widely deployed (and they are, though I can't share our numbers here at Oracle).

It's one thing to navigate this complexity in one application with a person like Jeff that has strong LDAP knowledge, but a completely different thing to expect that all of your off-the-shelf and in-house applications will have all of this knowledge and execute every step properly across all of these different kinds of systems.

Virtual directories remove that complexity by putting it at a service level. Change directories? Change a setting. Change applications? Change a setting. Add a web service with real-time data from an external source (perhaps a social network or real-time HR)? Change a setting.

Contrast that with the extra code, application rewrites, infrastructure changes, etc... that need to happen without a virtual directory and you see why Virtual Directory is the right way to go in almost every case.

And we wouldn't be pushing standards, such as the Identity Governance Framework and CARML, which will improve Virtual Directory interoperability, if we weren't fully committed to our customers' desire for standards and minimal vendor lock-in.

Personal Fire Trucks and Overengineering Identity Solutions

Mon, 19 May 2008 20:46:40 -0800

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:

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

Quote from the Fire Chief about using this water:

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

What does this have to do with technology, and in particular, identity?

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

Looking at the above, caching is about like buying a personal fire truck. You're adding a lot of complexity for a problem that may not even exist.

Technorati Tags: directory, identity management, LDAP, virtual directory, irrationality

links for 2008-05-19

Mon, 19 May 2008 11:38:30 -0800

Some Thoughts on Facebook Connect, Google Friend Connect and MySpace Data Availability

(tags: identity socialnetworking)
blog.pmarca.com: Friend Connect, Open Social, Ning, and the web

(tags: socialnetworking)
The Tao of XDI: Did Info Card help?

Apparently Kim Cameron's integration with InfoCards is keeping poor Andy Dale from authenticating and thus providing his feedback on the latest distributed identity access discussion... I think the answer to his rhetorical question was no, but maybe he en

(tags: identity infocards)
Shops secretly track customers via mobile phone - Times Online

Interesting article. Seems similar to the way that sites track visitors through cookies -- at leas when you ignore the underlying tracking tech.

(tags: privacy)
Your Identity in a USB

Couldn't help but chuckle after coming across this, given Kim Cameron's recent (and excellent) post about the anti-excellence of fingerprints...

(tags: identity)
LifeLock CEO Had His Own Identity Stolen Numerous Times, Suit Alleges

Tip of the day: Don't publish your private information in magazines. Then again, doesn't take a printing press to get your ID stolen.

(tags: identity privacy)

links for 2008-05-17

Sat, 17 May 2008 14:31:18 -0800

Network Security Blog Â» Data isn't "private" if you put it on a social networking site

Martin McKeay makes a similar point to mine from earlier. If you register for a service and "ACCEPT" that you're going to share the information in that service, you've given up a degree of privacy to be part of it. This is doubly-true with the case for In

(tags: identity privacy security)
Birthing pains in the colonization of the social Web

links for 2008-05-16

Fri, 16 May 2008 14:33:21 -0800

Data Portability: It's The New Walled Garden

To some degree this is the classic identity politics situation that we talk about all the time with identity virtualization. Basically if I give you a copy of identity data, I lose control of it. Will be interesting to see how this plays out at Internet s

(tags: identity privacy)
What Data Portability Means for Business - Covering All That's Social On the Web

Another good article that puts the Facebook-Google situation in perspective. Users give up privacy nearly every time they click "Accept" on a registration form. There's no reason to think that they will stop doing so anytime soon. Even with InfoCard and o

(tags: identity privacy)
IdentityBlog - Digital Identity, Privacy, and the Internet's Missing Identity Layer

Kim Cameron of Microsoft summarizes the most recent set of discussions we've all been having related to his initial scenario involving a combination of identity and purchase order data being used by the same application.

(tags: identity)
The Virtual Quill

Dave Kearns follows up on the responses from Kim and I. Seems to be in agreement, though points out that we've got to make sure we consider the needs of today's (and yesterday's) applications as much as the next generation. Couldn't agree more.

(tags: identity)