How to be a good architect?
Introduction
I've been thinking lately about how to not just use architectural tactics in a vacuum, but also when to apply them and in what context. Different companies have their own issues and some may be more important than others, but I feel like it's good to have a heuristic for what to prioritize. Otherwise, you might focus on architectural aspects that ultimately don't matter.
Focus on the mission
Programming is primarily a means to an end - it's a way to solve problems in the real world as efficiently as possible, usually for an organization. A lot of software is never truly done, so "efficiently" doesn't just mean the initial development cost, but the cost of adding features over time, fixing bugs, training new hires, and keeping knowledge within the organization.
You should ask the people in charge why they fund the technology at all - what would happen if all the technology was removed and all the tech-related employees quit? Why would it happen? The answer may start very general, but if you drill down you may find that some aspects of the technology is more important than others. This is a good starting point for what to focus on, at least initially.
Set aside your ego
Coming up with architectural ideas can be very fun, but it's easy to get attached to them. Once you do that, you may feel that critique of the idea becomes personal to you. Your attachment may mean that you don't feel comfortable with others implementing your solution, and you therefor decide to leave others in the dark.
Your area of responsibility will probably outgrow how long you have ownership of it. Due to the bus factor, the knowledge of the architecture should be distributed among more people in the organization. You should talk with other architects to get insight from them, and accept the fact that you might be wrong sometimes.
I'm opposed to the idea that architecture is fully separated from software development. In general, the people who know most about a problem, and are the most invested in it are the people affected by it. Scaling the Practice of Architecture, Conversationally provides a model for how to distribute architectural responsibility to where it makes most sense.
Being a good architect means letting go, focusing on the mission, and inspiring other to do as well. Google found out that what makes good teams depends less on the individual members of the teams, but their shared culture.
Maintain stability
It can be tempting to focus on all the long-term improvements for the architecture, while forgetting that you are working on a real system, used by real people who are experiencing problems today.
Focus on big wins when improving stability. If you have an issue in production that prevents users from performing essential operations, try to solve the immediate issue first. End users sometimes like features, but they always hate when existing features stop working. Target a base-line for stability - being able to detect when customers have issues and solving the most common issues quickly is essential. Long-term stability is achieved by relying on other architectural aspects.
Measure improvements
Improvement measurements can be considered both on it's own and the potential for improvements. In other words: "Do end-users like the technology?" and "How prepared is the organization to improve the technology?"
Do end-users like the technology?
There are a number of ways to measure how much end-users like your technology. You can either measure it qualitatively with personal interviews, or more quantitatively with questions whose results can be aggregated.
Quantitative measurements may involve surveys, but you can also automatically gather metrics of how end-users use your products. You can test whether or not end-users like a given change by running an A/B test and measure how many users in control group A or B performed the desired action(s) as a result of the change. Having good monitoring is useful to discover design issues, but also to detect when critical bugs are introduced that prevent end-users from performing desired actions.
How prepared is the organization to improve the technology?
By monitoring the key metrics from the Accelerate Book and aiming to improve them, you become more result-driven. For reference, the key metrics are:
- Deployment Frequency
- Lead Time for Changes
- Mean Time to Recovery
- Change Failure Rate
Divide the technology
In order for a given technology to scale, you need to be able to divide it and talk about the parts individually. I recommend dividing the technology into different organization domains based on what the technology is used for and can be used for. Different parts are more important than others, and the architecture should be built so that unimportant parts don't negatively affect the import ones. Advertising to end-users e.g. may be an important part of the technology, but it may be meaningless if the end-users cannot or aren't convinced to register accounts.
Putting it all together
Which of these aspect are more important to focus on that others?
I feel like short-term stability is the most important one to focus on, especially if the lack of stability can cause a lot of distrust in end-users that can be hard or impossible to regain.
The second most important aspect is the reality that you may only be a footnote in the history of the technology you are working on. Trust in others and multiply your footprint by inspiring them to become better architects.
Learn what is most important to the organization, and once you know what that is, make sure you are able to measure that it's not getting worse over time.
Once you know what is the most important part of the technology, isolate it from other parts that are not as important, and allow them to grow independently of each other.