How to start iterating architectural solutions?

The question is if not everything can be done upfront, how to iterate without making a mess?

I was discussing in the past, that the problem is not about doing upfront design is more about how much upfront design is enough because its impact is limited over long term.
It’s usually much more important to practice changing your architecture so that it’s able to change over time as we go.

I’ve said a lot of times that you cannot predict the future, and also that any decision you are taken now will be invalidated at some point in the future if your application lives enough time.
Thinking in this way, you will agree with me that it is much more important to create architectures that are able to change in the last responsible moment.

The point of the last responsible moment is basically to reduce the cost of changing your architecture, because after passing that moment, the cost of changing your architecture will be so high that your organization will always regret it. This scenario is common, because people don’t revisit architecture decisions, and ends starting from scratch again.

Ok, but let’s discuss today on how to start in this field of architectural evolution. Let’s talk about these activities like threads that are happening in parallel, not like steps.

• To start the process we need to learn about the problem we have to solve, this means to talk with stakeholders, understand what competitors do, check the current solution if exists.
  Anything that helps you to understand the problem. The first goal in this thread is to find a subproblem to start with, one that is simple enough and solves some blockers of the current big problem. The learning experience is not finishing here, it continues, think on how to make it a continuous.

• When we identify that subproblem that is simple enough for us, we can start thinking on creating a team with a goal to solve that problem, in the case we don’t have that team yet. This small team does not need to solve it in the best possible way.
  Its goal is to learn about the problem, putting in production a solution for the customer, the simple possible solution that can possible work. Don’t confuse being fast with being without quality, quality here is key because if we have bugs, the collected data will be invalid. Try to have in teams people that follow the tenth man rule.

• We need to release in front of the customer a solution earlier because we need to probe with real data if our solution works and solves that small problem.
  This can mean anything, you will also need to balance reputational costs or anything that is important for your company. Please don’t confuse release to customer to deploy, deploy multiple times before releasing.
  Time is key, if we are not able to do this in weeks, let’s rethink our approach. Perhaps that first subproblem was not small enough, perhaps our approach to solve it is too complicated. Remember, try to create the simple possible solution that can work and design as if you were wrong.

• In case the solution to that problem is not good enough, you will probably have to iterate it through the data that helps you to understand, because you at least collected real data.

• Repeat this with each small subproblem you find interesting to solve now. Don’t solve problems that are hypothetical. Create the data to probe problems.

In fact what we are trying to do is to take smaller decisions based on smaller problems and learn from them.

If you do this at some point you will have a vision of where the architecture needs to go, based on the learnings you collected with those initiatives.
You will need to understand the decisions taken in the teams, their architecture, their problems and then think on a plan to solve those problems.
You are close to the architectural vision that will help you to start your first architectural refactors.
Now that the vision is there, you can start doing small steps on your current architecture to change it to the new one, you are refactoring your architecture in small steps.

The same with the previous things, now you need to continue understanding the problems of your architecture, that perhaps change your vision or gives you new steps to go in the current one.

What this means at the end is:

• Create or rethink one or some teams that can solve your small subproblems with the simple solution that could possibly work.

• Try to generate your architecture based on evidences of problems your current simple solutions have → talk with the people of your teams and listen to their problems.

• Try to do it in the last responsible moment → use fitness functions to identify that you are close to the last responsible moment.

• Repeat this.