Preface
When I first started digging into the software-as-a-service (SaaS) domain, I expected to find plenty of existing best practices guidance. After all, SaaS certainly wasn’t a new concept. There were multiple examples of successful SaaS companies and a general sentiment that SaaS was establishing itself as the preferred mode of delivery for many companies. To me, this meant I’d mostly be absorbing and applying an existing set of patterns and strategies. Surprisingly, it didn’t go that way.
The more I wandered into customers’ solutions and the more I scanned the industry for guidance, the more I began to realize just how little clarity there was around what it meant to design, build, and operate SaaS environments. I think part of this was the byproduct of the natural ambiguity that comes with attaching a label to any technology. The lack of absolutes has created lots of room for competing definitions and opinions about what SaaS is meant to look like. This has opened the door for companies with fundamentally different implementations and approaches to brand themselves as SaaS. In fact, I continue to see a number of companies setting off on their journey to SaaS with wildly different, misaligned views about what it means for them to adopt a SaaS delivery model.
There’s nothing inherently wrong with this. It’s fine to have different ideas about what it means to be SaaS. This, however, becomes a bigger problem when you need to work with customers that are looking to you as ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access