By Luc Perkins | Posted on June 14, 2013
TL;DR: The answer is yes, it probably is . Here’s why:
It’s 2013, and user management has become an absolute must-have. Long gone are the days when web properties simply had visitors. Now, it’s essential to know with whom you’re interacting and to store that data and make it actionable. It’s a subtle art that involves leveraging technologies like social login, social profile storage, single sign-on capabilities, and more.
At the same time, the tech world is slowly becoming a web service API-driven world. IT departments have begun seeing the value of the SaaS model over the on-prem model. And yet user management still tends to follow the on-prem model. I think that this is about to change. Here’s why.
Once upon a time, servers were expensive, hard to maintain, and always—always—on premise (after all, where else would they be?). Then, data centers came along and produced massive economies of scale in computing resources. People started calling it "cloud computing." The world took notice and began to take advantage of the possibilities opened up by this new technological horizon.
Where IT departments once built most if not of all of their software stack from scratch—sometimes everything but the operating system (and sometimes even that!)—the rise of cloud computing meant that they began to externalize core elements of their tech stack and workflow by relying upon external vendors. The result, in short: the *-as-a-Service paradigm .
Okay, so that story might just gloss over a fair amount of detail (!), but I do think that it captures the basic thrust of the *-as-a-Service paradigm and how it has developed thus far.
Early on, critics contended that IT departments would never be willing to outsource core functions to third parties. The gut feeling of CTOs and other technological decision makers, this way of thinking goes, will always be to keep things in house. Control is the name of the game; technological trust stays within four walls.
But the critics are increasingly either changing their tune or simply being ignored . Why? Because the *-as-a-Service paradigm makes a very powerful thing possible: it enables companies to whittle away extraneous tasks and complexity in the name of a near-total focus on core business logic. This whittling away might ruffle the feathers of some old-guard decision makers—and yes, sometimes they have a point—but even they are increasingly seeing the writing on the wall.
And so if you could boil the *-as-a-Service paradigm down into a single core ethos, it would be this: have someone else build and manage the things that you don’t absolutely have to build and manage . This ethos amounts to a genuine passing of the baton to external parties. It’s a refusal to re-invent the wheel from scratch and an affirmation of buying a Firestone tire instead.
Although it’s foolhardy to attempt to locate the historical origin of the *-as-a-Service paradigm, we can at least pinpoint a few major players that were crucial in its establishment: the Salesforce and eBay APIs in the early oughts (marking the birth of the Software-as-a-Service (SaaS) model), the surprising emergence of Amazon Web Services in 2006 (the first stirrings of the Infrastructure-as-a-Service (IaaS) model), and the AWS-driven Platform-as-a-Service (PaaS) Heroku , which came along in 2007 (now owned by Salesforce in an interesting twist of historical fate).
More recently, *-as-a-Service has expanded well beyond these initial pillars into a variety of other domains. Nowadays, you see a much broader landscape in SaaS (too many to mention), IaaS ( Rackspace and others in the OpenStack ecosystem, Google Compute Engine ), and PaaS (AppFog, OpenShift ).
But you also see entirely new domains, from Database-as-a-Service ( 10gen , Cloudant , Heroku Postgres , Redis To Go ), Backend-as-a-Service ( Backendless , Parse), and Analytics-as-a-Service ( New Relic , KeenIO ), Email-as-a-Service ( Mailchimp , Sendgrid ), Telecommunications-as-a-Service ( Twilio ), and so on. This is merely a fraction of what’s actually going on in this space.
In all of the above cases, companies have come along and offered to do things that other companies could conceivably build in house. This is often what makes *aaS anything a tough sell. Companies always have to carefully weigh the costs of going DIY against the costs—not to mention risks—associated with delegating significant portions of their technology stacks to an external vendor.
The *-as-a-Service paradigm has been driven by CIOs, CTOs, and others putting their trust in external vendors. Granted, Plenty of major companies are not yet ready to deploy applications in production on Heroku or manage email campaigns through Sendgrid or let Stormpath handle their authentication and security.
Simply put, it’s going to take years and a lot of fundamental shifts in the cloud space for their decision-making process to shift in the direction of *aaS solutions. But the movement is well underway, and the techno-economic factors driving it are simply unstoppable.
Most companies can build and maintain just about anything they want, and many do a perfectly satisfactory job of building user management infrastructure. But remember that the *-as-a-Service paradigm is emphatically not about that. It’s about division of labor. I could grow, process, and prepare all of my own food—and here in Portland, that actually wouldn’t be all that weird—but that would detract from all of my other activities.
If I wanted to become a marathon runner or learn cello or crack open my high school French books, I’d be hindered in all of these pursuits by the need to constantly provide for my food intake. I’m quite happy to delegate that whole food acquisition thing to external vendors. The freedom I gain—the freedom to pursue activities like self-improvement and learning and exercising and making music and working at Janrain and so on—is well worth the cost and risk.
Analogously, if you’re building a SaaS product focused on, say, developing complex algorithms for targeted email marketing, the case for doing things like buying and managing your own servers or building your own in-house CRM for organizing your contact information or an in-browser product management tool is growing weaker and weaker every single day.
Making the case that user management is the next major star in the as-a-Service firmament is difficult because, to put it bluntly, there are far sexier things going on in the technological universe.
I recently co-organized a NodeJS conference here in Portland called NodePDX , and what I saw on display was a diverse set of dizzyingly cool new technologies, from HTML5 game engines to NodeJS running on Raspberry Pis to people running Node on temperature sensors. What we do at Janrain isn’t quite like that.
User management won’t get a lot of play at bleeding-edge conferences like RICON or Google I/O and it hasn’t spent much time climbing the ranks on Hacker News and Reddit . But that’s okay because the importance of user management lies not in the sexiness of the technology but rather in its proximity to both the business logic and core technology stacks of companies that want to remain in step with our current technological horizon.
What on Earth does that mean? At the risk of painting in overly broad strokes, I think it goes something like this: once upon a time, it was perfectly okay for major websites to have anonymous visitors. People would visit OmniCorp.com, see some static (and probably not very illuminating) content, and then leave. So-called Web 2.0 changed all of that—we all know this story—and now vastly more is demanded of the relationship between web properties and users.
Now that the world has become as device- and data-driven as it is, users demand the ability to see what others are up to, to share their experience with known others—not just the anonymous multitudes—and to have an experience that is tailored to their interests and particularities. The case for actually providing that kind of experience—not to mention for building rich datasets around selective targeting of users—is growing as quickly as demand.
Up until just a few years ago, everyone was simply building their own user management stack from scratch. This meant all of the following:
When lots and lots of organizations begin building things like this in a redundant fashion, it’s only a matter of time before a SaaS marketplace emerged ready to fill this gap. And this is precisely what we’ve seen and precisely the movement of which we are a part.
The Janrain User Management Platform (aka JUMP…you see, my lame Van Halen joke is actually not a complete non sequitur) was designed to solve the kinds of technological problems I listed above and to do so with aplomb.
Perhaps most importantly of all, JUMP provides an abstraction layer that keeps you from having to get your hands dirty with all of the above. We built a system with the following in mind:
Again, skilled engineering teams absolutely can do most or all of the above. Some of them have even done it well. You, Dear Reader, might be a part of—or even leading—such a team.
But it’s important to bear in mind that the ones who have done it well in the past did it in the absence of a well-established User-Management-as-a-Service marketplace. This has begun to change dramatically, and I think it’s safe to say that we’re on the cusp of a day when the build-vs.-buy decision will push most companies, even technologically advanced ones, to trust the *-as-a-Service space to handle nearly everything outside of that ever-smaller space where companies actually should build from scratch. That space now includes user management, and the sector is full of win.
How to tell if your identity management is ready for the new data protection regulations…
We just released the latest member of the Janrain product family: Janrain Advanced Policy Manager…
Janrain Information Security Manager, Lisa Nicholson, shares her thoughts on why CSA Level 2 and…