You don’t need Software Architecture for your startup
Currently, I am working for a rather small start-up. Once, I was thinking late at the night about our new product and how to design it properly. And below I will summarize a couple of the outcomes from that evening.
This article aims for those who participate in fairly early-stage start-ups either as technical leaders or as product owners. If you are working on a project which has defined scope which is unlikely to pivot for 180 degree you probably won’t be able to apply any of these ideas.
First of all, let’s ask ourselves a question:
Do we need to spend hours and hours planning in detail all of interactions in our system and each of its components?
Before answering this question I will share couple of my thoughts regarding it.
Software Architecture not needed?
For quite a long time I have believed that before going coding we have to plan. Even with agile-ish approaches, we should have a design of a whole system.
And truly, having a solid plan makes development easy. You and the developers’ team will appreciate having well done QML diagrams and API definitions.
But. You do give up the very basic thing for your business instead. Flexibility. Indeed, software architecture is all about setting borders.
When you have chosen between cloud and the on-premise solution you put quite vague limitations in available tools and what’s important on this stage pricing and scalability. It limits ways in which you can flex your product, but still allows plenty of options.
However, when you narrow boundaries further down by defining single language or framework, way to run your components (e.g. AWS Lambda or AWS EC Containers), and even internal structure (for instance, entities relations in form of QML diagrams) several problems arise.
Not only you spend a good amount of time not to bring value to your product. You also give yourself a bias about what is possible in your system. And can measure it not only by business requirements but also based on the cloud castle of your design approach. Sometimes it’s quite easy to forget that all the technical aspects should serve the product, not vice versa.
Software Design
While it is quite taxing to design your system as one entity what I find very helpful and beneficial in the long term is designing each more or less self-contained module as “well” as possible.
This applies not only to microservices or serverless functions but also to separate modules of your monolithic application as well.
By “well” here I generally mean maintainability, readability, test coverage. Probably, you won’t spend days and days optimizing for performance, as the more important result in the early stages is to get some feedback from real customers. However, I will tell about the opposite case in one of my next writings, so stay tuned.
On one hand, such prioritization doesn’t take much time for planning ahead of time on something you might not even need. On the other hand, it helps with building robust independent modules.
Eventually consistent architecture
When your product comes to a point when the business model is quite stable as well as a set of core features you are going to provide it is time to go further. By this moment you should have pretty good knowledge of the domain you are in as well as the main performance bottlenecks of your system.
You collected knowledge you need to refine your chaotic architecture while spending zero-to-very-small amount of time directly.
Now you should be able to afford that time to be spent on architectural decisions and documentation. Also, you will likely grow quite fast from now (if the business model is proven and the backlog is quite long), so a set of boundaries will be really helpful to get a communication framework between developers as well as between applications.
Conclusion
Congratulations, you have come this far.
So, finally, do we need that Software Architecture thing about which guys at Google, Facebook, and other cool names will ask us during interviews?
I must admit, I have lied to you in the title. We do need it. But not in a way one might think about as something steel-hard which defines what we can and what we can’t do to make our customers happy.
Through clean and maintainable individual components, we will be able to reorganize them when the business we work for has a stable business model and needs which can be solved by complex architecture.
Before that point, we should concentrate on lower levels of abstractions as I maintainable and readable modules (not that great different will it be separate parts of your good old monolith, production-proven microservices or new shiny serverless functions). It will allow fast pivoting without throwing us back in time to redesign the whole system.