I have been developing software for 7 years and having worked in 3 early stage startups i have realised that there are few aspects of an architecture which are not as much talked about as they should be. In this blog post, I will try to cover those different aspects as well as talk about the decision making process to select the right architecture for your job.
In early stages of a product, there will be a lot of uncertainties and iterations. Every product in its early stage typically follow a model to learn from the users and iterate as quickly as possible. This essentially means you have to be ready for feedback and incorporate those changes within your product. A company’s success or failure depends on how quickly their product can adapt to feedback and provide maximum value to its users.
So, the next question is how can one enable these quick iterations in the product without changing too many of the internal details. Now, if the product needs to change quickly with iterations, then the architecture of the product becomes one of the most crucial aspects in making the product successful or a failure. If the architecture is not agile enough then iterations in the product come with a heavy cost and if it is, then the iterations would be much faster and much cheaper in terms of development work.
So in the context of this blog post, we are going to talk about 2 important dimensions for evaluating software architecture:
- Product architecture should support quick launch
- Product architecture should supports quick iterations and feature enhancements
Launch a Product Quickly into the Market
Every startup / product should definitely strive to launch a product quickly. I think most of the people doing startups or going to do startups must be aware of this by now that the timing is key.
If you are not embarrassed by the first version of your product, you've launched too late.
This above quote from Reid Hoffman, co-founder and executive chairman of LinkedIn, beautifully summarises when to launch the first version of the product. Launching a product quickly means that you are going to spend more time understanding the needs of the customers rather than theorising on the white board as to what they might want. Iterating quickly and understanding from feedback is the most crucial form of learning that you can get in the initial stages of product development.
In early days of a product, architecture is one of the most important aspects to focus. There is a constant tussle between “the product team” who are trying to get the end product as quickly as possible to the customers and between “the engineering team” who are trying to make sure the architecture is scalable and supports a number of product features.
This behaviour can be summarised with this graph below
Analysis
- Any architecture in Section 4 is the best as the hours are on the lower side and the number of product features which are supported is on the higher side. Architectures in this section will provide maximum value to the customers very quickly.
- However if there is no architecture then in Section 4, then one needs to choose one of the architectures among Section 1 i.e. Low Hours but Low Product Feature Support or Section 2 i.e. High Number of Hours with High Feature Support.
- In this case, as we already have 2 architectures in the Section 4 i.e. Low Hours + High Number of Product Features, so we need to choose among these 2 but the story does not and should not end there.
Making Quick Iterations in the Product
After we have filtered down the list of architectures, one needs to ask this simple question that which architecture among the listed ones supports rapid iterations or has a high iterability. This is a very important dimension on which we need to evaluate an architecture because every time new requirement comes from the product, new things needs to be built to keep the business growing so if the architecture is not iterable enough i.e. having low iterability, then the company / product might run into a huge crisis. So having an architecture which supports quick iterations is a win-win for all.
Iterability is the factor which defines that how easy is to add product features to your current architecture without adding a lot of man hours. High iterability essentially means that you can add more and more high quality features to the architecture without wasting a lot of man hours. Whereas low iterability means that it will take a lot of man hours to build features of high quality.
Now let’s zoom into the different architecture in Section 4 and see how do they fare on this dimension
Analysis
- As we can see in the above diagram, we have 2 architectures which had almost similar feature support and almost similar hours spent.
- But on the dimension of iterability, Architecture B does badly as compared to Architecture A which would make Architecture A an obvious choice for any product. This is because Architecture A would probably give future values to the customers in a much quicker way.
Let’s take one concrete example to understand this point in a better way. Let’s say you were to start a new product within your company which offers “Analytical capabilities to the internal teams on their machine log data”. Now on day-0, you sit down and start noting down the different options:
| No. | Architecture Details | Feature Factor | Iterability Factor |
| 1 | Use Flink engine to provide this analytics capability. – UI Interface needs to be build on top of the Engine | High- ( 4 ) | High ( 5 ) |
| 2 | Use Apache Solr to provide these analytics capability – Everything is available within the product – Iterations are really difficult even though Open Source | High. ( 5 ) | Low ( 2 ) |
| 3 | Create Everything From Scratch – Very low Feature Factor – Iterability is on the higher side because of knowledge | Low. ( 2 ) | High ( 5 ) |
| 4 | Use Product’s like Splunk, Sumologic – Quality will be High – But cannot be iterated as Closed Source | High. ( 5 ) | Low- ( 1 ) |
Analysis
- If you were to look into this above table, you will figure out Flink Option although has a relatively lower product feature support than Apache Solr Option because of no UI interface, but still many among us would prefer Flink Option as this offers better iterability which will allow us to add more and more product features as time comes.
- Nobody would prefer Creating Everything from Scratch ( i.e. Architecture 3 ), as it would have low feature support which is required. Although it would have a high iterability as everything can be developed on top of it
- Architecture 4 is also not preferred as there is no way one can iterate on top of these architectures as these are closed source architectures.
Drawing Parallel with Overfitting
For better understanding of this above product features vs iterability dilemma, I would also like to draw a parallel with Overfitting in Machine Learning domain.
Like any overfitting curve tries to fit all the training data, in the same way “not so good” architecture fits around all the current required product features without thinking about any future features or in machine learning terms future data points.
Analysis
- As one can see in this diagram , that if you were to fit a curve wrt to all the features ( important or not so important ) i.e. Architecture B , then you might end up having an architecture which might be ok for current set of feature demand but might not be ok for upcoming or future features in the product.
- Architecture A on the other hand does not try to over-optimize on the feature set but rather takes a simplistic approach to cover all the important features + focussing on high iterability.
So in other words, if you were to look into all the required features and try to fit the architecture which fits all of the required features but has a poor iterability ( i.e. future features might not be easy to add ) , you might end having a suboptimal architecture. So before finalising any architecture, you must look into both the factors i.e.
- If the architecture supports current set of required features to some extent
- If the architecture supports adding features in the future.
References
