This post is Chapter 2 of my notes from the book Building Microservices: Designing Fine-Grained Systems. Subscribe to my newsletter to follow updates. (Read Chapter 1 here)
Comparing software architects with architects is inaccurate. Physical-world constrains architects while the software is designed to evolve with user requirements. Maybe the most harm caused by the word architect.
We tend to assume that the software we develop will live forever as it is. But whenever we finish the task at hand, it already becomes out-of-date or produces technical debt. We need to design systems that are changeable because of the nature of our work. We're not civil engineers, and we're not building one building to let it stand for many years.
Software Architectures are more like town planners. Town planners don't plan every building; they specify zones. Industrial facilities can only be in industrial zones. Town planners try to fulfill the citizens' current needs while keeping the future in mind. This approach is applicable not only for software architects but also the organizations without that specific role. The idea of planning a city is very similar to software planning or software development in teams. The teams can build beautiful buildings. But it's a software architect’s role (or a shared practice in some organizations) to keep the city beautiful by putting some limitations around.
The changeability is often ignored in software architecture design. We try to create loose-coupled systems or modules. But at the and we build our whole system to stay put. We don't make the bigger picture easily replaceable.
Software architects should worry more about what happens between services rather than what's going on inside the service.
Guideline: Be worried about what happens between the boxes and be liberal in what happens inside.
The architect must be sitting with the team and working on regular stories. It helps the architect to understand what the everyday work looks like. This method is more effective than having a meeting or reviewing the code.
The Coding Architect
"Ideally, the architect should work on normal stories, to really understand what normal work is like. I cannot emphasize how important it is for the architect to actually sit with the team! This is significantly more effective than having a call or just looking at the code."
Strategic goals are overall and high-level company goals that might not include technology. These goals can be defined at the company or division level.
Principles are the rules. These rules are aligned with strategic goals. They are not the same as goals but rather define the directions on how to achieve these goals. Principles can and will change in time. For example, if the company wants to quickly deliver new features to the market, principles can be making teams independent to prevent groups from blocking each other.
Practices are detailed and practical guides to ensure the principles are followed. Due to nature, practices are more technical. Therefore, it can also change more often than principles.
"Practices should underpin our principles."
Combining Principles and Practices
The value of having principles is showing people where we would like to go. The practices are there to help people how to implement the ideas stated in principles.
Defining a standard is like answering "What is a 'good citizen' service in your system?" It is one of the key points to define explicit attributes that each service should have.
There has to be a common practice for both logging and monitoring.
It doesn't matter either you push data into one service or pull from all services to a central location, pick one and use the standardized way everywhere.
Make the monitoring box opaque.
Pick one or a maximum of two standards interface technologies. It helps integrating new consumers easily.
Shield the service from failures that happen in underlying systems.
Agreeing on how things can be sounds always a good idea. But following decisions and seeing them implemented is a dreading task. There are two methods to help people to follow these decisions: using examples and templates.
Don't hesitate to write an example code. Written documentation is good, but when you support it with code, the developers tend to understand better or have a higher interest. Also, the developers can run and explore the standards or best practices we encourage.
Templates and including all the decided set of development practices inside is a great way to kickstart a project. The template makes everything way more straightforward in the beginning. It handles the groundwork, and the focus can move on to developing the service itself directly. Maintaining the template is a collective activity that team(s) should take joint responsibility for updating.
When we deviate from our technical vision or change it, we create technical debt. One job of the architect is closely following this situation and keeping the balance. An architect should look to the bigger picture and understand the trade-offs and when to keep the balance.
It’s possible to have exceptions in the overall system. When our systems deviate from principles and practices, we start creating exceptions. One way to make sure we can react to these changes is by keeping a list of exceptions. If there are enough exceptions, it may be wise to change the principles or practices and reflect the new understanding of our work.
“If one of the architect's jobs is ensuring there is a technical vision, then governance is about ensuring what we are building matches this vision, and evolving the vision if needed.”
There should be a group of people from every team (most likely the lead), and the architect should chair this group.
Growing people in monolithic systems are more challenging than microservices. Owning a system and shaping the implementation and the vision in microservices are more comfortable than monolithic systems. In microservices, we create autonomous codebases with their independent lifecycles to support people to own the full service and significantly impact the overall system. This way, we enable people to step up in their career.
The evolutionary architect's core responsibilities are vision, empathy, collaboration, adaptability, autonomy, governance.