How to make an architecture roadmap plan?
Some time ago in my current company, we faced a challenge of preparing the long term architecture roadmap.
Strategic planning is a very important part of architect work. We need to know what our destination
I want to present you with a basic template for strategic plan preparation. It works for us, but I encourage you to adjust this method to your organization and team needs.
Steps of architecture roadm ap preparation
1. Choose system quality attributes
Each IT system can be described using functional and non-functional measures. We can use system quality attributes to describe nonfunctional principles like scalability, security, testability, etc. As a first step, we need to consider which system attributes are the most important for us and for our company in a longer time period. It depends on our capability to handle technical architecture work, but at the beginning, I would recommend choosing only 3 system quality attributes that are the most important and which we want to improve on the next year. That number of attributes force us to focus on the most important work in the company, which could give us a bigger benefit in the longer perspective.
2. Analyze them one by one
We choose our focal points in technical improvement roadmap. Next, we need to analyze these areas one by one to recognize what is the current state and what can we improve.
3. Current state definition
On this phase, it is recommended to work closely with the business side. It could be a business representative like analytics as well. The input from the business side would be very beneficial. The main goal here is to define the biggest pain in this area. That could be a functional or nonfunctional problem. We should try to remind all the problems raised by business or developers recently. It defines the current state of our non-functional domain. It is very important to list all the problems here to make sure that our architecture vision will be focused on the solution for the biggest pain points.
4. Target state
Next, we need to define, what is the expected state of the system landscape in our company. The same as in the last point, it would be also beneficial to include business representatives in this work. We need to define the characteristic of quality level which we expect from our system. That should be answered for the problems found on the previous step. The target state is a long term vision, how our organization should look like from the technical perspective. Of course, it doesn’t mean, that we won’t solve other problems in the future, but it shows our priorities.
5. Define metrics
I remember the popular quote from Peter Drucker: “You can’t manage, what you can’t measure”. He said that about the business, but the same applies to the software development areas as well. To improve something we need to know what level of this “something” we already have and what level of it we want to achieve in the future. The measures could give us an opportunity to measure progress also in the middle of the road.
However, now the question is, what is the good metric to our particular system quality attributes. It should be easy to measure. It should reflect our main pain point in this area and it should be correlated with the level of improvement in this area. It is not easy to define a metric for this purpose, but we need to think, how it will be used by us. We need this metric to track the progress and check, whether we are on a good path to fulfilling our goals.
6. Actions to achieve it
This point is the most interesting one from the technical perspective. We already have defined starting and target states, so we need to figure out, how to change the current state into the target one. This step could include some more technical audience to combine the knowledge of more people.
We should think about all the possible actions which could lead us to the target. There is a possibility, that we would want to define more than one action here, which are redundant (when one will be done, the second one would be not beneficial anymore). At this stage, we can keep both, but also we need to choose the more beneficial for the organization. We will remove this redundancy later during a road map creation, so we should keep all possible options for now. We will decide on this at the next stages. Of course, we shouldn’t include here the options, which are not relevant to our company or technology stack. Let’s keep only the actions possible for us and which we would want to take.
When we finish the work of thinking, we end up with the list of steps/actions necessary to change the current state into our vision.
7. Tag all steps and set its importance
Now it is time to categorize all the actions defined earlier. At first, we need to define which quality attributes this action is related to. Then we need to decide, what is the impact of this action on fulfilling our vision defined earlier. We can just use 3 labels: HIGH, MEDIUM and LOW. This helps us to choose the right order of actions later.
8. Order and responsibility
We are getting closer and closer to create our road map. Next step is to define an order of actions which we would want to follow. The order should reflect the potential dependencies between actions and their importance. Moreover, we should define the owner of this action for future progress tracking. It should be a technical person, who will be responsible for the future development and integration of the solution for this action. We should also attach an architect to be a consultant for this subject.
9. Timelines
At the final stage, we should build a road map. I will describe this process in a more detailed way later on this blog, but we can do this very simply now.
The most important part of creating the roadmap is to get the general estimation of the work from the responsible person and to place it in a particular time. That’s it. To help estimate it, we would want to break this action down to the level of technical tasks and discuss it with the development team, but the general objective is to define how much time is required to do this, and when development team can do this.
When we gather all the necessary information, we can draw a simple roadmap to see how and when our vision will become real in the near future.
That’s a very basic process but it helps us to define long term goals for our organization. I hope it will help you as well.
What is your way to defining long term technology vision?