The Membership Model: A New User Paradigm in Enterprise IT

8/19/2019 3:48:28 PM

The relationship between users and organizations in enterprise software is changing. Purchasers of IT should understand the shift, and developers should make conscious design decisions in light of it.

A new model

As a salesperson, your account belongs to your employer; you cannot take it with you when you leave for another job. Historically, enterprise software user accounts existed entirely within the scope of a single employer; is one such example. Software sold on a per-seat, license-maintenance revenue model is almost entirely structured in this way. We’ll call this the ownership model.

Now, however, a new model is emerging. Unlike in the ownership model, enterprise software user accounts have the potential to outlast any single job. Instead, individuals maintain their own unilateral relationships with enterprise software providers while adopting a more temporary relationship with employers. Examples here include Dropbox, Github and even LinkedIn. For Github, individuals create a single account, which they own indefinitely, regardless of which organizations (employers, open source projects, etc.) they may join and depart over time. We’ll call this the membership model, in which users of enterprise IT interact with employers in much the same way as Facebook users interact with Groups.

For a great example of the membership model in the while, take Github’s explanation of its own model:

  • Your user account is your identity on GitHub.
  • Every person who uses GitHub has their own user account.
  • Your user account can be a member of any number of organizations, regardless of whether the account is on a free or paid plan.
  • It may be tempting to have more than one user account, such as for personal use and business use, but you only need one account.

This example is largely representative of the membership model in general.

Visually, you can think of the two models as follows:

Ownership model
membership model

In the ownership model, users cannot exist without a link to a single organization, whereas in the membership model they may create and sever links at will. We can think of this linking dimension as follows:
To recap, in the traditional model, organizations may have many user accounts but each user account may only belong to one organization. In the membership model, however, users may belong to several organizations. Users who belong to multiple organizations have a separate user account for each in the traditional model, but share a single account across the organizations to which they belong in the membership model.

Why is this happening?

The emergence of the membership model has been driven by a mix of interrelated factors, a few of which include:

  • Cloud — enterprise services being offered directly from vendors rather than delivered via a company’s own servers and IT resources
  • BYOD — as employees bring their own devices in the enterprise, they implicitly take a larger role in IT procurement decisions
  • Consumer-led, freemium products — as companies like Dropbox have shown, the previous factors have turned consumer product offerings into a viable channel into enterprises; viewed from another angle, companies like Dropbox and LinkedIn are monetizing consumer product offerings by building enterprise products on top of them
  • Employee mobility — vendors stand to gain from maintaining relationships with users as they transition from one employer to another, if those users bring the vendor’s products with them into their new organizations

Thus, the membership model is a natural outgrowth of broader trends in enterprise IT and software in general. Should trends in enterprise IT continue, we should expect the membership model to become more prevalent across enterprise offerings with time.

What does it mean?

As a result, those developing software for the enterprise should consider the following when adopting a membership model:

  • Maintain end-user-centric design — while you cannot ignore the ultimate purchasing decision makers and IT stakeholders within your enterprise customers, end users should take precedence in guiding design decisions
  • Clearly define data ownership — be clear and confident concerning who owns the data, work and other assets generated by users while they are members of a given organization; While persistence of a user’s account itself is a necessary condition of the membership model, developers should clearly define which assets generated during an active membership the user can take with them when the membership is terminated, and which will be left behind as property of the organization to which they belonged at the time
  • Consider technology architecture carefully — in many cases, the membership model lends itself well to multi-tenant architectures, where both application logic and data are leveraged across organizations; For customers who insist on single-tenancy, a membership model may lead to significant duplication of data across database instances and may create challenges in accurately replicating assets across organizations

I believe the membership model will become increasingly prevalent in the enterprise, and developers would do well to begin grappling with the opportunities and challenges it presents.

Note: This blog post was heavily inspired by another blog post on Github’s organization model which, for the life of me, I have not been able to re-find. If you know it, please comment below and I will add a link here.