In anticipation of Jeff Sussna's keynote, What Comes After Team Topologies?, iSAQB member Eberhard Wolff had a number of questions for Jeff about applying Team Topologies to real-world projects, the responsibilities of architects, and where microservices and cloud approaches fit into all this.
You are doing a keynote at the Software Architecture Gathering about what comes after Team Topologies. What do you think is missing in team topologies?
It's not so much what's missing from Team Topologies itself, but rather what's missing from how people typically think about and use it. They tend to think in terms of things: teams, applications, servers, platforms, etc. They focus inwardly: this is the platform or the application or the microservice that we're building. Too often they underemphasize the flow between the things they're building. It's like a class without any methods, or compute without I/O. Part of an architect's job is to design for organizational I/O, if you will. Imagine a database group that can't make progress on automation because they're always being interrupted by questions from developers. Investing in documentation and training reduces the "real-time" I/O demand on the database team, and effectively makes some of it asynchronous. Just as architecture needs to address characteristics such transaction rates, latency, data volume, sources and destinations for digital data, sociotechnical architecture needs to address similar characteristics for the flow of communication between teams and people.
Usually project managers and other managers set up the teams. Should architects take over that responsibility? Do they have the competence to do that?
Conway's Law tells us we can't think about software and team structure in isolation from each other. As we decompose a system into components, we also have to decompose the organization that builds that system into the teams that build the components. Just as product managers and developers and testers need to collaborate in building applications, so too do architects and managers need to collaborate in building organizations. It's a joint human/system problem. Managers need architects' help understanding the system implications of the organizational structure they're trying to create. Conversely, architects need managers' help understanding the organizational implications of the software structure they're trying to create.
Theoretical knowledge e.g. about Team Topologies is one thing — but putting them into practice is a different thing. What is some practical advice for architects to actually apply these concepts in real-world projects successfully?
Refactoring an organization is similar to refactoring a complex piece of software. It doesn't happen overnight, and it doesn't happen without pain. The Team Topologies patterns run counter to how much of us learned to work in software organizations. Part of why architects and managers need to work together is that you're asking humans to behave differently. That takes time and support and experimentation.
You say that there should be a balance of autonomy and alignment. However, it seems usually teams are aiming at more autonomy. How much autonomy is too much autonomy?
Autonomy that doesn't serve a larger purpose is too much autonomy. "Build it and they will come" platforms are a prime example. Just as with customer-facing applications, teams within an organization need to use their autonomy to deliver value that's relevant to and usable by other parts of the organization. This is part of the rationale for product-centric IT. Product-centricity means continuously understanding what your users need, and delivering it in a way that they can understand and adopt. If you spin up a Kubernetes platform, but none of the application teams in your company know how to develop for Kubernetes, that platform won't do anyone any good. Helping application teams effectively use the platform is part of the platform team's job. Much of the difference between public clouds and internal IT comes from the fact that public clouds understand that they have to enable their customers to get value from their platform. One of the implications of Team Topologies is that documentation and support targeted at other internal teams becomes part of your workload.
Are microservices and cloud needed for approaches like Team Topologies? Or is that the other way around? Or is there no relation?
It's funny because the DevOps mandate to dissolve silos between dev and ops silently assumes a cloud. It isn't feasible for every application team to include a network engineer and a database engineer and hardware engineer and so on. "You build it you run it" depends on some sort of platform abstraction. The notion of a platform team (whether private or public) is at the heart of Team Topologies. Without it, value stream aligned teams don't really work, regardless of how macro or micro the size of the value they're delivering.
What is the most surprising fact you learned about the interaction between architecture and organization?
While Conway talks a lot about teams, he doesn't actually talk about an "org chart". The key concept in his paper is "communication paths". Cross-functional collaboration is a mechanism for enabling intimate, non-siloed communication across organizational boundaries. By contrast, I've seen teams whose members created artificial silos between themselves through their communication style. As further proof of Conway's Law, these internal silos were reflected in the software design. Optimizing the flow of communication (not just communication paths but how interaction actually flows along those paths) is a key part of what Team Topologies-influenced architecture needs to concern itself with.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
