Building Software Platforms. A guide to SaaS transition with AWS

This agile paradigm is easier to follow when technology is at the center of the business, not just a means to support it. This approach is nothing but applied science, a clear manifestation of the hypothesis-driven scientific method, backed by Agile software development doctrines such as Extreme Programming.

It depends on the industry but as a general rule, whatever makes them obtain better business outcomes.

For example, for an insurance company, better results mean selling more policies, whereas for a car manufacturer, it translates into selling more cars. Complementary, for a SaaS company, a core system is whatever they help obtain more. Everything else is the cost of doing business.

Transitioning to on-demand software (or SaaS) will help you in moving your customers away from a capital expenditure (CAPEX) toward operational expenditure (OPEX) or outcome-based pricing models.

You have to design, build, and test your whole system for failure from the ground up, so the higher-order systems that are core to your mission rely on stable and tested infrastructure.

Focusing on the stuff that had nothing intrinsically to do with your business function is of utmost importance for the success of your project. Even the things that you take for granted need to be designed, built, integrated, and tested thoroughly to ensure you can achieve your mission goals.

It is critical to point out that internal software platforms are not buckets of independent shared services. Instead, the platform approach is based on the balanced correlation between transversal solutions that share a common goal, thus introducing a new architectural style. Under the precepts of this new style, the various business services that run with the platform will enjoy revitalization opportunities for their architecture and technology direction.

• Cloud Compute. The rationalization of access and consumption of managed cloud services.
• Lifecycle Automation. The heavy-lifting of repetitive and low-value tasks through automation, especially for the provisioning of environments and the deployment of services on top of them. 
• Multiple APIs. A curated developer experience that makes software engineering an enjoyable job.
• Infrastructure Design. The offload of the cognitive burden from developers so they can concentrate on building quality software. Can be achieved by industrializing all the undifferentiated functionalities.

Without you taking any action, the collection of functionalities that you will have tomorrow is probably richer than the one you have today and will cost you nothing.

On the contrary, once you start writing code for your applications, you will incur execution costs. That’s because code in a rich serverless environment is debt.

With serverless computing, there is one more NFR to consider when making design decisions: costs.

Low-level, technical design decisions at the component or function level also have a direct impact on costs. For example, an ill-designed algorithm with an unnecessary high cyclomatic complexity can incur charges that otherwise would not have happened had the logic been optimized.

We need to be careful with layered architectures so that domain-specific services are not deployed on top of that platform infrastructure. Instead, they are deployed with it, side to side.

Serverless computing is entirely based on industry standards and protocols (in many cases even open-sourced) that, combined with evolutionary design patterns, allow clean and easy interoperability between providers.

Even if you take the best software engineers to build your software, you can’t guarantee that the end product will be successful.

You need processes.

Processes help improve the chances to create quality software, and that’s precisely a core engineering property: learn from the mistakes and put in some corrections to make it better in the next iteration.

As you mature as an engineer, you will realize this more and more: it’s not about the code, it’s not about the design, it’s not about the tools, it’s about the coordination between people.

Opening the business APIs and letting partners and external contributors build new applications is vital for your future. As the Jevons paradox31 has taught us, new higher-order systems and innovations will emerge from this move, enabling you to compete in an elevated playfield that will boost the consumption of your APIs.

• People have a flawed "thing", call it X.
• In order to escape the flaws of X, they turn to Y. Y is flawed too, but it's flawed in different ways. These people compare the flaws of X to the flaws of Y and decide that Y is more appropriate for their use case.
• Use of Y spreads. Over time, fewer and fewer people use X and more people are use Y.
• Eventually, most people are only familiar with Y. They don't remember X and don't remember why people chose Y the first place.
• People use Y. Y is flawed.
• In order to escape the flaws of Y, they turned to X'. X' is flawed too, but it's flawed in different ways...