Monty Python had a great skit years ago on both record and television - "How to do it..." where they promised to show you how to play the flute (blow in one end and move your fingers over the holes), etc.  So basic were the instructions, they are really useless.

Within such a context,  today we discuss some "how to do its" rules of thumb and identity architecture. This came up recently in sizing out a client architecture when the client wanted to know "how to do it".  In the end, you won't be that much closer to being a real architect, but you could play one on TV.

First, we work with a series of "rules of thumb".  Don't ask where they come from; many are based on years of trial and error on many projects, but you cannot point to a definitive study that proves them right or wrong. Here are some we work with:
        1) When you start working with 1 million users that are frequently updated, consider using IdM Service Provider Edition (SPE).
        2) Its tough to justify IdM projects for user populations under 5,000. Not enough users to justify the investment usually and they are most likely an entrenched MS AD user who has not out grown it yet.
        3)  While LDAP directories can scale to millions of users, you have to really optimize your DIT  as you get to 15 million entries and really should consider partitioning the data set when the entries get into the 25 million to 30 million range.  Not that the directory cannot handle more, but back up and recovery times are so long as to be unacceptable.

There are others out there, but these are quite handy.

So how does one architect an IdM architecture?  Everyone wants to do this before the project so they can buy the needed hardware. Which, of course, is a pretty backwards way to do it.   Would you order all of the supplies to build a house if you have not architected it yet?  Why does everyone want to buy before the project has had a chance to got through its "Design and Analysis" phase.

By waiting to order gear til then (okay, order some to start development), the actual payload the system must handle will be clearer and the rate of transaction will be better understood.  An IdM system may manage 1,000,000 entries, but the overall load might be light.  One user record change per week in a field of 1M users is a light load. Each user record changing once a week is a different story.

So, try and determine payloads you will need to support. Its not the number of users, but the number of updates per hour/day/week thats important. Its not the number of entries in the LDAP directory, but the number of updates the system must handle.  Its not number of password resets of critical importance, but how many concurrent users doing password resets online that matters.

So make some good estimates on the payloads the system will support. That will give you transactions per hour, concurrent user sessions needed, etc. Then size up the hardware needed to support that payload. This can be done from published performance and stress testing.

Granted, there is much more to properly architecting a system during design and analysis, but I did say this was "how to do it...".  Your systems integrator and software partners should be able to help you in this area.  However, you need to be able to tell them how much power you need.