Designing Autonomous Teams and Services

Chapter 4. Discovering Contexts

Finding service boundaries is really damn hard…there is no flowchart.

Udi Dahan, Service-Oriented Architecture Expert

In the previous chapter you learned abstract patterns for modeling autonomy in the problem space. In this chapter, you’ll learn collaborative techniques for discovering your problem domain. Critically, you’ll also learn to develop a modeler’s most important characteristic: never being satisfied with the model.

Multiple perspectives of the problem space are needed to create the best solution. In this chapter, you’ll see outside-in approaches, starting with the goal and working in toward the domain. And you’ll also see inside-out approaches, starting with the domain and working toward the goal. Expert modelers combine both approaches with knowledge of the business context (presented in Chapter 2).

Crucially, representatives from all sides should be involved in both perspectives. Typically, you’ll find organizations will split the responsibilities; managers and coaches will take the systems approach and focus more on teams, while software engineers focus on the architecture of the software. But creating high autonomy requires high alignment between the organization design and the software architecture. You cannot achieve autonomy if managers exclusively design teams and engineers exclusively architect software systems.

If high performance is your goal, you need to accept that the design of teams and the design of software systems are ...