How many times have you been asked which architecture you would use to start an application? Exploring the common interrogative in this blog post.
From mobile apps to APIs, this question arises in interviews or even in day-to-day scenarios at the inception of a new product. The answer can be straightforward, a company-defined standard, or guided by a software architecture team. Sometimes, it involves ready-made templates. Other times, developers engage in technical discussions, drawing from their experiences or online references.
Many find themselves in these scenarios. Junior developers learn that they must study an architecture well enough to advocate for their implementation to managers or product owners. This perpetuates the notion of architecture as a rigid, one-size-fits-all solution, stemming from a concept believed to fit all problems. But first, let’s establish what software architecture truly entails.
We have the classic Gang of Four - Design Patterns - that aids in categorizing a range of problems and, more importantly, their solutions that recur within the realm of software development. This is the simplest definition of a design pattern: for instance, the Observer pattern addresses the perennial issue of tracking changes in a value or element’s state. Now, what constitutes the architecture of an application?
In my perspective, architectures are essentially the same, but when we talk about applications as a whole, they become a way to tackle a set of challenges the program will face holistically, not in isolated parts. Under this lens, architecture becomes a collection of software pattern decisions aimed at addressing these challenges. It’s not uncommon for it to consist of design patterns along with other choices in documentation and file organization. But the question remains: How do we assemble this collection? Through a favorite book author, influential YouTuber, or perhaps Twitter (X)?
What defines this collection is the problem the computer program aims to solve. Hence, the first step should be determining the nature of the problem we’re addressing (and then picking a JS framework - just kidding). Following that, we need to list things like the environment requirements for running the application and contextual factors such as authentication mechanisms. This checklist encompasses not only developers but also involves product and management teams.
So, what’s the best architecture for an application? The answer is, it depends. It depends on various factors, and in practice, if this question pops up in an interview exercise, the answer would be any, given the lack of context and time for discussion. Yet, that doesn’t stop you from studying models. After all, your solution doesn’t come out of thin air but rather from a collection of past experiences. However, don’t champion models as the sole, perfect solution without understanding the actual problems. Software architectures aren’t one-size-fits-all shirts, much like how rarely do we have an absolute solution for shirt sizes. Just like the sizing issue, in software, we often have to experiment and perhaps, we should build software incrementally, embracing an ongoing quest for the best solution, just like finding the right fit for a shirt (or body).
So, how often have teams gathered beforehand, sans acronyms, understanding data flow and the problem’s essence? They’ve called in product and project managers, hashed out product goals and time-to-market. They’ve commenced with something simple yet scalable as their comprehension of the issue expands. Maybe this is as utopian as clothes that fit all sizes.
PS: And yes, I struggle to find clothes that fit me.
Thanks, Rodrigo