38 architecturalist papers: A minimalist SaaS definition for enabling Service ownership

In the tech industry, there are as many ways to buy products as there are companies.

Today there are two big variants. The first variant is what we call “Packaged Software,” and the other variant is what we call “SaaS.”

And the corporate transition from selling one variant to the other can feel like the ocean hitting land. And the transition is made worse because organizations insist that the problem is culture and mindset and not how the software is built. No amount of mindset can overcome software architecture. And because software architecture is hard, and because the two teams are screaming at each other, the real problems never get addressed.

But, as I stared at the problem recently, I realized that we architects must provide meaningful guidance. Saying “but the architecture” is as useful as “but culture.”

So let me try.

Packaged Software is when you go to a store, buy the bits, and install them.

The other variant is SaaS.

Now the word SaaS translates to “Software as a Service,” but like any FLA (Four letter acronym), it’s so devoid of specificity to mean nothing.

I claimed that you were a SaaS service many years ago, not if you run in the cloud or on-prem but if you satisfied one criterion.

1. The provider of software decided when software gets upgraded

This definition was interesting, but big enough customers can demand special upgrade cycles even for SaaS.

So I started adding all sorts of other criteria, “easy to use, consumable, freemium, cloud delivery, DevOps,” and every single time, it floundered because I could trivially point to how packaged software offered the same features.

But SaaS was different. And then it hit me; SaaS is different because of another important criterion.

2. If someone other than the provider wants to extend the software what’s important is how to connect, not where the Software is.

The significance of this — is that the software consumer assumes the software is always running and that the consumer and integrator doesn’t have to care about how it’s deployed, how many resources the SaaS system requires, etc.

Integration doesn’t involve step 0; install the software.

Elements 1 and 2 starts to separate SaaS and non-SaaS.

But there is in my mind this third criterion:

3. The producer of the SaaS software chooses where it can run, not the consumer.

Now, this is a weird one. Almost every piece of software written has some minimal hardware and/or software requirements. So, at some level, why is this different from non-SaaS? The answer is that in non-SaaS, the actual location of where the software runs is opaque to the producer.

So now we have — in my mind — a minimal test for a team that wants to be SaaS.

1. Does the team owning the software decide when it gets upgraded and consequently what features the software has?
2. Does the team/customers that use the software just care about how to connect to the software?
3. Does the team that owns the software get to decide where it physically runs?

These are necessary conditions, although not sufficient.

But they are necessary for service ownership to become a thing.

Service Ownership?

In any SaaS company, service ownership means you have a pager (or someone/somewhere on your team) has a pager.

When a company first goes to SaaS, they typically install much software from a bunch of teams into some cloud and offer that as a cloud offering.

The team that installed the software then finds itself triaging bugs in all of the software installed.

The team that did the installation then screams at the other teams: “You need a culture change. You don’t care about customers!”

The teams that produced the software look at the cloud team and said: “How dare you! We respond to every bug!”

The cloud team says: “We are a service.”

The other team says: “we produce software.”

And the screaming continues.

The truth is the following. The cloud team built a service out of packaged software. They control the version; they control how you connect to the service; they control where the software runs.

From the other team’s perspective, the cloud team is just another unhappy customer, running the wrong version of the software, has done all sorts of weird things that don’t quite match other customer usage patterns, etc.

And like every other customer, they just want people. And the product team has mastered the fine art of saying no.

But why does it feel to the product team that they are just another customer? Because the product team doesn’t have any control over when a bug gets fixed and deployed, the cloud team does. Because the product team doesn’t control how you connect to the software, the cloud team does. And finally, because the product team doesn’t even have any say in where the software runs, the cloud team does.

And the SaaS standoff occurs.

The SaaS standoff ends when the cloud team demands a specific service, not support, not cultural shifts, but a service. And that service has to be well-architected and engineered to provide both teams with what they want.

And the minimal requirements of that service are the three things I enumerated.

1. Does the team owning the software decide when it gets upgraded and consequently what features the software has?

2. Does the team/customers that use the software just care about how to connect to the software?

3. Does the team that owns the software get to decide where it physically runs?

Originally published at http://wrongtool.kostadis.com on March 20, 2021.