Minimum Viable Architecture

Today I’m going to pen down about an interesting topic on architecture - Minimum Viable Architecture. Often, most architects try to design the entire product upfront. They try to think about what might be needed one year down the line, two years down the line etc. And then most of it ends up in the bin because their work was based on assumptions and not actual requirements.

It is a bit worrying that this way of working has been carried forward into Agile. Agile should be about quick feedback cycle and ability to adapt to changing requirements. So the way of building the entire architecture upfront goes against the very fundamental principles of agile.

The reason this might be happening is because it’s not easy to recognize that over-architecture might be the problem. I mean, you will still user stories being delivered, everybody busy etc. So as a scrum master or the product owner you might be thinking that everything is alright. In reality, the developers might be spending a lot of the time on implementing a bullet proof architecture while all you needed was a life jacket.

So, what is the alternative? Let’s call it “Minimum Viable Architecture”.

Minimum Viable Architecture

Minimum Viable Architecture or “Just enough architecture”. What it means is that the architecture that’s good enough for the product to be released, and needs to be continually improved during the lifetime of the product.

The most important aspects of this type of architecture are

1. Architecture not built for the least-likely worst case scenario. Instead the product will be built by keeping in mind the most likely scenario.
2. Built in small increments over a period of time. For this to work out smoothly, the programming language and the major technologies must have been already evaluated and decided. Minimum viable architecture does not mean that we change the programming language or major technologies midway in the development life-cycle.
3. Based on concrete or at-least reasonable requirements, not built on pure assumptions.

If you are not already building and implementing Minimum Viable Architecture, what can you do to get there? Let me suggest some things that you should and shouldn’t do when dealing with this situation.

What you should do

1. Nonfunctional requirements - Make sure you are architect understands the nonfunctional requirements of the product. If you have many releases planned, and if each one of them have a different set of nonfunctional requirements, present those to the architect. Say for example Release 1 of your product needs to support 50,000 users and Release 2 needs to support 75,000 users. So while implementing Release 1, don’t try to support anything extraordinarily over 50,000. This keeps the architect focused on the immediate needs.
2. Functional requirements - I have seen in many organizations the architect and the product owner being out of sync. This is especially true when the product owner is non-technical, the architect assumes that the product owner cannot understand anything other than user stories. So they avoid having in-depth conversations about the feature request. They both think they understand the requirements, but unfortunately their interpretations will be different. So I suggest regular in-depth discussions between the product owner, the architect and the developers.
3. Code - As surprising as it may sound, many architects do not understand the code in their project. Even if you do not expect to architect to code, the architect needs to be aware of the day to day issues that the programmers face. Without having an understanding of the code or the modules, the architect will never have a realistic picture of whether he’s going overboard or not, whether his ideas make sense in practicality etc.
4. Planning - 90% of the architects are perfectionists, they can’t easily let go of something unless it is 100% complete. Discuss and choose an approach that delivers the required non-functional and functional requirements on time, don’t spend the time trying to get the perfect solution - Apply the 80/20 rule.
5. Culture - The organization as a whole should have a cultural shift and architecture should not seen as something that stands the test of time for years to come. Make it clear to the architect but he will be given time to address issues in the future - and mean every word of what you said. Convey to him that it is okay for some part of the architecture to be reworked in the future.

What you shouldn’t do

1. Blame - Don’t blame your architects for not creating minimum viable architecture. It’s not their fault at all, you should be happy that he or she is so much involved in the work and cares about it. The only reason they are working that way is because they’re passionate about the product. Blaming your architect isn’t going to solve any problem. You should inform about creating minimum viable architecture but not in a confrontational manner.
2. Pressurize - Don’t start setting unrealistic deadlines thinking that it is going to result in simpler architecture. That is not the way to handle the situation.
3. Ignore - Don’t implement without architect’s input. While it might sound like a quick solution around the problem it is going to cause more harm than relief in the future. Diminishing the importance of architect and architecture is not the solution.