A particularly inspiring author for many people who work with computers and the tech industry is the architect and mathematician Christopher Alexander, who discusses the architectural design process in works such as Notes on the Synthesis of Form (Harvard University Press, 1965).
According to him, the construction of buildings and cities follows systematic patterns, something like, there always must be a “bathroom” and a “bedroom” module in a home, and, at a lower level, the “bedroom” module should have windows. At higher levels, such as in a “community” module, there should be leisure areas and parks for people.
These reusable modules encapsulate rules for building functional spaces, from cities to buildings and houses. Similarly, when developing systems, some platforms are already built and tested, and encapsulate complex business rules. These platforms guarantee the correctness and cohesion of ideas, and they can also be extended and adapted to different scenarios.
Anybody can visualize what should be part of a “swimming pool” module, both in terms of design structure and variations in formats and finishes. But at some point, an architect thought of how to extend that basic module to create an innovative, borderless pool, which came to be known as the “infinity pool.” The “infinity pool” still preserves the properties encapsulated in the “swimming pool” module, such as having a foundation, holding water, and so on. The same principle is true for software platforms: they can be reimagined and evolve over time.
Platform stacks composed of layers
Can Lego bricks be seen as limiting because the standard piece is square or rectangular? Perhaps. But even with this limitation on shapes, you can build anything from a spaceship to an ice cream parlor to a princess’s castle out of Lego pieces. The limitation is not restrictive in the sense that it doesn’t prevent anyone from creating whatever they want.
When you build reusing larger structures made with Legos, there is obviously a bigger restriction. However, if the larger structure meets your needs, the restriction has a positive side: a builder who starts from pre-built boat structures to build an entire marina can save time when compared to building boats from scratch. The pre-built structure encapsulates the complexities of boat design, allowing the builder to focus on the marina. And it is much faster to build a marina once you have the boats.
Platforms can follow a similar logic and allow a company to innovate without wasting time reinventing the wheel. There’s no need to recreate an entire computing framework every time a product or service idea comes up. The applications and services built on top of generic platforms can give a company its business edge.
Platforms should also be built with growth in mind. Let’s say you build a platform that will support 10x your current number of customers. When you go beyond that scale, it may still work, but not at its maximum efficiency. The response time for some services may no longer be satisfactory and with the number of customers increasing even more, that platform will eventually no longer work, needing to be either improved or rewritten. If you don’t do anything, you’ll have to deal with technical debt that will continue to accumulate over time.
The applications and services built on top of generic platforms can give a company its business edge.
Layers of a computing platform
Unlike Lego pieces, which are easy to fit together, computer interfaces are more complex, so they require modules that communicate well with each other. If the way the interfaces fit between the different levels of a platform is more perennial, changing it is easier. If the design is not conceived in a scalable way, you must constantly rethink the abstractions.
Architecting these layers and evolving them is hard, and that is why organizations need experienced engineers with solid technical knowledge. Those are the people who can best gauge the advantages and disadvantages of building scalable and generic platforms that meet present and future needs at an acceptable cost. It makes no sense, for example, to write a platform that can handle a volume of data on a global scale if a company plans to operate in a single country.
If companies had a crystal ball to get all the abstractions of a platform right from the start, it would be very simple. Since that doesn’t exist, the best they can really do is rely on scalable and reusable platforms with simple abstractions.
Marcus Fontoura
Marcus Fontoura is a technical fellow and CTO for Azure Core at Microsoft, and author of A Platform Mindset. He works on efforts related to large-scale distributed systems, data centers, and engineering productivity. Fontoura has had several roles as an architect and research scientist in big tech companies, such as Yahoo! and Google, and was most recently the CTO at Stone, a leading Brazilian fintech.
