Own is much more than have

JIT economy

JIT economy changed many industries. Owning a SaaS (environment) is an asset. Just having it slows your process. Owning an environment means knowing how to go to new vertical, adjust, overcome, or pivot.

Let’s compare it to similar trends in home construction as they are more relatable than abstract in nature software development.

Home construction metaphor for SaaS blueprints

There were always rapid development approaches to home and cabin construction. It is possible to take a standard shipping container, cut a few windows, doors, create an outlet for electricity, and that’s a dwelling which gives a roof over your head. It will protect against wind and rain in pleasant conditions. You even can combine a few of these to have multiple rooms. When temperature goes higher or lower of course comfort of being in such “home” is questionable.

Better technology would have at least insulation, and air conditioning. Further improvement will need to have outlets for water and bathroom waste to allow for connection of such unit to main foundation and utilities.

Boxabl [1] has offering to have kitchen with amenities, bathroom and air-conditioning already pre-built at a factory. Unit comes in shippable dimensions, which transforms into full size during installation. They offer these days units which can be combined into multi-room dwellings.

And if you are a developer - that's the exact piece you need. If you want to move into a house to live there, then someone still needs to figure out how to design a blueprint and lay a foundation and hook up utilities to the unit’s infra outlets.

[1] - https://www.boxabl.com/

Drawing parallels

The parallels can be drawn now. The unit in the world of SaaS is application, or are services needed for buildout. Infrastructure as a code (IaaC) and SDLC pipelines are that foundation, and connections between container outlets to utilities. These three components define typical SaaS environment.

Their quality defines how shippable it is from one place to another. Of course, what a copy is in digital world differs tangibly from a world of construction. The quality of these three components defines whether you own or just have your software.

Similarly to physical world unit infrastructure built into the “walls” differs. Defining how flexible it is to be deployed to an environment (“foundation”), combined with other services and reshipped to a new one.

The foundation in place has similar qualities, and flexibility of its own blueprint.

Cloud-infrastructure changes how SaaS companies provision servers, as cloud providers can offer servers in a matter of minutes. Beforehand similar provisioning easily could start months and quarters ahead.

Similarly to the physical world, actionable blueprint for SaaS is like having a factory which builds units, instead of having a container which was built. Automation in both cases ensures standard and quality across the entire production line.

It improves strategic positioning of SaaS companies in three main directions: human capital, operations and risk management, and of course existential adjustments.

Below are symptoms which appear independent at first look. They have the same solution – owning an environment.

Human Capital

1. Remember when a new engineer came and was afraid to touch the environment? – as a result it took a long time to ship new features.
2. Remember that new product which never went live because all engineers who enabled company to have it, don’t remember what they put in into these years? Think about it. Some of them might never have met.
3. Remember that feature engineer was overthinking for months because environment is fragile? IT is a practical discipline and “break things fast” is an excellent way of learning when you have dedicated environment(s) for it. Especially when the goal is to find out what you should not do to break production.

Risk management and operations

4. Remember the DR (disaster recovery) process which was added as a separate checkbox item, and took a year and half for teams to complete?
5. Remember the time when production went down because configuration management was not predictable and in code? - sad story of Knight Capital
6. Remember the performance testing which never took place and then customers had to experience every single bottleneck, and the team spent hours troubleshooting this?
7. Remember that security patch which brought a company to a stall, or full halt?

Existential adjustments

8. Remember the other day when your sales did not go because demo environment is development environment?
9. Remember a dedicated customer you had to abandon because it was estimated that onboarding would take a year?
10. Remember that vertical you did not go into because it was just too many controls to add on top of what is supported?
11.  Remember the certification process which took ages to complete because product deployments were so ad hoc it required due diligence to investigate each one for the processes in-place?
12.  Remember the product pivot you were overthinking, instead of testing it as a standalone brand?

Line on a sand

These are 12 symptoms which can be resolved with a comprehensive resiliency and reliability program and SaaS blueprint.

Alone mentioned directions are quite difficult to prioritize when a company is pushing another feature or product, but together they replace constantly amortizing have by steadily compounding own. This is a practical way to implement strategy of change, and lay foundation of infinite game for a business.

See also

Cross-cloud credentials

 Still spending technological time on management of static credentials?


Multi-cloud is the last thing to recommend to keep technology menu short [1]. Unless, you have a really strong case for it. But when you do multi-cloud - do it without static credentials. OpenID is a well-tested technology, which wipes boundaries even between separate clouds through federated principal.

If even multi-cloud can do it, the rest should follow.

[1] - Keep technology menu short