Users are almost always the simplest entity in your application. I mean, they usually just look like this:

How complex can something like that be? The answer is that as simple as something like that is, people still get it wrong, and quite often they get it horribly wrong.

Just to set the proper context, I am talking about applications that provide Software as a Service.  For example, we may be building an Accounting SaaS system.

A user logs into the system, and gets to see his invoices, outstanding bills, etc. This sounds simple enough to do, so what is the reason for this post? The reason is that while this may sound simple, it is also wrong.

The User Is The Account

Let us introduce a few other semantics into the mix. I don’t want to do accounting, so I get Pkida to do that for me. But, since my data is tied to my user account, I would have to provide her with my username and password. Now, I am willing to let Pkida do my accounting, but I am not going to give her my credentials.

This is usually the first stumbling block for systems where “user is an account” model. You want multiple users to manage the same account. A good example of a system that for a very long time failed to handle this properly is Amazon AWS platform. For a long time, there was your AWS Account and your username, and they were pretty much one and the same. Consider the case of an IT department that wanted to use Amazon AWS. Until as recently as May 2011, they didn’t have any way to have multiple people manage the account, because they would need a single user/pass for the entire thing.

That is a huge problem for most scenarios. Sharing user/pass means that you lost control on the account:

• You don’t know who of the people who have access to the account made a particular change (no auditing).
• You can’t use standard approaches for detecting fraud.
• It is much harder to change the password.

Accounts Owns The Users

The next step is to ask what happen when you have something like this:

Now we have a way to have an account, and it can have multiple users. And all is good in the world, right?

Not so fast. What happens when it turns out that Pkida isn’t just working for me, but actually manages the accounting for several companies, each of them is using the SaaS accounting package. In order to use the software, Pkida would now have to have a separate user account for every customer she manages. That sucks:

• It may mean that you charge her for each account (she will go to a competitor).
• Some users would show very little activity.
• The amount of information you will have to do things like cross selling or targeted offers would be far reduced.
• It is annoying for the users.

A much better option is a total separation of Users and Accounts. A user can have several accounts (usually with a default one selected), and they can use a single login to access each, and each account may have multiple users associated with it.

This brings to question how you are going to handle charging people, but that is an issue for another post, and another day…