When an organization moves away from a centralized monolith to more decentralized and distributed architectures, such as microservices, the development culture, and therefore, the culture around the system’s architecture also changes. It too must become more distributed and less centralized.
Development teams, because they are ideally autonomous in a microservices environment, require more freedom than they did in a monolithic world. This comes both from being an autonomous team, and from the responsibilities and narrowed focus they must now take on. By virtue of being an autonomous team, they have more freedom to choose and implement things like their build and delivery pipelines to fit their particular needs. Since they are the ones running the services in production, they should have the freedom to update and modify the monitoring solutions to fit the needs of their owned services. The team is now directly responsible for the quality of the code, rather than passing it over the wall as “somebody else’s problem”, so they need the freedom to implement testing strategies that work best for them.
This can be a nightmare for architects and folks in other roles that thrive on having a coherent and consistent set of principles that are enforced, and violations of these principles can be pointed to as a kind of safety net when things go wrong. Moving to and embracing a microservice model will feel very much like a Wild West, with no enforceable rules, and all the teams just going off and doing whatever they feel like doing.
Without being guided by the architecture decisions we are used to making in a monolithic world, how do we help guide teams to make decisions that will not only work for the team itself, but also be good for the company? As an example, a team that needs to store PII information in a database, they should choose a database platform that supports encryption. But those aren’t always things teams will think about, even these autonomous teams that are supposed to know about all these cross-cutting concerns. Governance now is less centralized, and the teams have more freedom, but they still must have guard rails put up around them to protect them from making poor decisions. Architects, and other “governing” bodies such as security, are now tasked with laying down guidelines for the individual teams to operate in.
Instead of decisions, or dictations such as “you must use Java”, the guidelines are typically more general. They focus less on technologies, and more on attributes. Instead of “write the code in Java” it becomes “whichever language you choose, it must be scannable with our static code analysis tool, support this monitoring tool, etc.” Many times this is really just exposing the reasons behind decisions you’ve already had to make in a monolithic world, but instead of prescribing one thing that fits the needs, you are allowing teams to decide which of the tools, that all meet these criterion, they will use.
This changes the architect’s job from one of translator, taking the business requirements, analyzing them, and providing the teams with a set of tools and patterns to use, to more of a guide or counselor. We now take the business requirements and expose them to the teams, saying these are the lines you need to stay within, and offering suggestions and support for ways to stay within those lines.