Last Updated on September 23, 2023 by KnownSense
In this article we’re going to discuss the ownership culture in microservices. It doesn’t sound like as if it’s got anything to do with design, but in reality, it has a massive impact on the way we design our microservices architecture.
Service as a Product
The first idea behind this principle is that we treat each one of our microservices as a product, as an asset that brings value in terms of data and functionality, and it’s something that we should make visible to both our own organization and to our customers. This is because if everyone’s aware of these products and what data and functionality they bring, this will lead to new use cases and potentially new products that use that data and functionality. Sometimes it takes someone outside of the immediate product team to realize the potential, where the microservice’s specific data or functionality, when combined with other data, to create a new product or service. This is why it’s key that we make all our microservices visible as premium products. If everybody’s aware of what microservices you have and what they are, this will also help you scope your microservices and avoid duplication because everybody’s aware what data and functionality are available across the organization. There’s unlikely to be any unnecessary accidental duplication of that functionality and data.
Product Managers or Owners
As part of this ownership culture, like any other successful product, each one of your microservices should also have a product manager, or using Agile terminology, a product owner. This product owner would act as the representative, the reference point, the advocate for each one of your microservice’s data and functionality within your organization. These individuals are responsible for bringing people together in terms of business, technical, and other product owners in order to discuss the scoping of a specific microservice or the upgrades or the enhancements of a specific microservice, as well as reviewing new use cases for the data and functionality.
Technical Development Teams
We should also have a technical development team that’s assigned to each microservice, and they’re responsible for long‑term maintenance and collaborative development when it comes to discussing specific microservices, contracts, and interfaces and the data and functionality available to work with other teams and other microservices. Having this kind of concentrated knowledge behind each microservice in terms of technical detail will not only encourage concurrent development, but your organization will also be more responsive to change. When you quickly need to bring in change to remain competitive, you know behind each piece of data and functionality you have a team with the intricate knowledge that knows the consequences of those changes.
Business or Domain Teams
As you’re also aware from the domain‑driven cohesion principle that each microservice represents a specific part of the business in terms of data or functionality, and therefore, each microservice should also have ownership from the business end from a business department. This kind of business team ownership and insight into what data and functionality are available will again encourage new use cases, new solutions, and new products. Those water cooler conversations will be a lot more effective if the entire organization are aware of what data and functionality is actually available. From a design perspective, you have clear ownership from a business team and a technical team that you can involve in scoping sessions for microservices and in sessions like event storming.
Collaborative Design and Visibility
How we can actually make our microservices, in terms of the data and functionality they provide, visible.
One of the key ideas is, is to make available an API catalog to your organization, which is basically a product catalog which shows off exactly what microservices you have and what data and functionality they provide. So this kind of visibility and ownership from the business end and the technical end and from a product owner or product manager will lead to design sessions that are truly collaborative using methodologies like event storming. This kind of insight into what data and functionality are available will lead to more productive design sessions where everybody’s feedback and insight is included. As part of this ownership culture and collaboration, you will also start to see that your organization starts to develop a ubiquitous language where everybody is using the same terminology to refer to data and functionality. There’s no longer confusion about what actual assets the organization has in terms of data and functionality provided by your microservices.
Architects
As another key part of the ownership culture, there should be ownership around the architectural standards and guidance, and I believe there should be a central team of architects which help with this. For some reason, architects can be seen as an anti‑agile pattern, but our teams here are still allowed to work autonomously on the microservices they own. But remember, as part of our microservices architecture, we will need to centralize a lot of components. Things like security will be centralized. Things like monitoring and logging will also be centralized. Therefore, we need a team of architects to ensure that the right standards and guidance are available to all our teams so that they can use these centralized components effectively and nothing is duplicated. Architects can also ensure that long term the software architecture, our microservices architecture, is going in the right direction in terms of business requirements. It will also be the job of the architects to listen to the challenges that the teams are facing when working with our microservices architecture and then potentially research and provide solutions for those challenges so that we have consistent solutions across the board.
Conclusion
In conclusion, fostering an ownership culture in microservices architecture is a strategic approach that enhances visibility, collaboration, and efficiency. Treating microservices as products, assigning dedicated product managers, involving technical development teams, and ensuring business ownership all contribute to a more agile and responsive organization. Furthermore, establishing a ubiquitous language and centralizing architectural standards facilitate consistency and innovation. Embracing this ownership culture empowers organizations to navigate the complex landscape of microservices architecture effectively.