"Let's introduce Microservices, they will make our delivery faster." A sentence which I hear over and over again and which I consider to be an oversimplification of a complex challenge. A thread 🧵with ten points: 👇
1. How do you define "fast"? Daily releases, hourly releases, weekly releases? What are your quality goals? Do you want to be "fast" in every area of your domain or only certain parts?
2. Are you aware what enables being fast? There are technical, infrastructural, modeling, organisational and cultural parts to "becoming fast".
3. The technical and infrastructural parts are certainly complex but in my experience over the past years most organizations were able to tackle them quite well. Investing in automation is key here and you should make sure that this is understood by all stakeholders.
4. The modeling, organisational and cultural parts are the hardest ones to tackle. None of these are simple and none of these can be done quickly by bringing in some high profile experts: YOU need to do the work and have the patience.
5. With (domain) modeling we need to find boundaries within which teams can make a high percentage of decisions without having to coordinate with others. Cross-team coordination will always slow you down, no matter what fancy tech you will use later on.
6. You want to align domain modeling boundaries, with team boundaries and module boundaries in your software. This sounds straightforward but it isn't because you will realize that your first takes in the modeling may not turn out to be the best ideas.
7. You will gather news learnings along the way that can have an impact on the team org.
7. continued: Of course you shouldn't reteam every month but make sure that the stakeholders understand that this will happen & that doing so is NOT a failure from the past but a learning for the future.
8. This brings us to the cultural part of such endeavours. In my experience you can only become "fast" (with or without microservices) if you manage to establish a culture of trust. The management has to shift decision making competencies in the teams and trust these teams.
9. But with trust comes responsibility: Your teams have to be willing and also be enabled to take on those responsibilities. You need to establish a culture of continuous learning in which teams aren't afraid to kill some darlings from the past based on new insights.
10. Think of it as a set of gears that mesh together. It makes no sense to extremely optimize one of the gears. Instead, it is better to optimize all of them evenly and moderately in a continous fashion
@bitboss Thanks for the insight!
So far, I've mostly viewed the domain modeling / boundary process (5.) from the "breaking down technical and domain complexity in reasonable, manageable parts" perspective - with team enablement as a desirable side effect rather than the original driver.
But that makes sense.
Michael Plöd
Sebastian Kempken