This week was all about software architecture as we hosted the international conference on software architecture in Gothenburg (ICSA 2017). At the same time, I hosted a company get-together between, among others, Booking, Spotify and Klarna. During the get-together, the role of architecture also came up a number of times. I realized that the research community (and the traditional systems engineering companies) has a very different view on the role of software architecture as compared to the online Web 2.0/SaaS companies. When comparing these two perspectives on software architecture, four fundamental differences jumped out at me.
Just-in-time architecture: Traditional software architecture thinking is focused on doing architecture work early and before others start. The thinking is that you need to put a structure together for everyone to operate within before the rest of development can start. The online companies focus much more on just-in-time architecture work: just before a more structural change to the system is needed, e.g. due to scaling, work is kicked off in a bottom-up, “concerned engineers” style that addresses the concerns at hand.
For online companies, the focus seems to be on doing as little architecture as possible as it puts structures in place that constrain development. Which leads to the next observation…
Decouple teams: Traditional systems engineering companies and the academic community at large seems to design architectures to satisfy multiple, conflicting quality attributes and focuses on the performance of the system in operation. The online companies focus their energy on architecting their system such that teams can operate with as few dependencies on each other as possible.
This may sound like traditional component teams, but it really isn’t. Component teams carry responsibility for a specific component in the system but requirements tend to affect multiple components and consequently, the component teams have very high coordination cost. The alternative organizational structure, feature teams remove this coordination cost, but have other areas where coordination cost may be substantial. The online companies architect such that teams can truly work independently with as simple interfaces between the different systems as possible and allow teams to (almost) run their own products.
No architects: Traditional companies tend to be big on job titles and specialization including developers, software architects, systems engineers, systems architects, development managers, etc. In the online companies, it seems to be the opposite. One of the companies explicitly states that they don’t have architects and this is very intentional. The traditional idea behind the architect is often concerned with taking the decisions and then policing the teams to ensure compliance. This goes straight against the notion of empowered teams that can operate without coordination overhead and that feel both the freedom and the obligation to protect the architecture.
Development inefficiencies: Finally, traditional companies treat any development inefficiencies, e.g. two teams building similar functionality, like the plague as this is viewed as the worst use of precious development resources. Consequently, vast amounts of process, oversight, management, governance and otherwise is put in place to increase the efficiency of development.
The online companies, on the other hand, tend to be very much focused on data-driven development, such as measuring feature usage, and experimentation, such as A/B testing, and know that most of the R&D work never leads to a significant contribution to the business. That makes the R&D in a way waste, but at the same time, you need to try things out to figure out what works. The awareness of the lack of effectiveness of R&D efforts causes online companies to focus on enabling teams to try as many different hypotheses as possible and if this means doing double effort in different teams, so be it. The cost of controlling what teams do is much higher than the occasional double effort.
Concluding, although every system has an architecture, accidental or intentional, and this architecture needs to be governed and carefully evolved, there are fundamentally different ways of doing this. There are significant differences between traditional embedded systems companies and online Web 2.0/SaaS companies. Although some of these differences are driven by the domains in which these companies operate, I believe that there is a lot to learn from how online companies work with architecture as it applies across many industries.
