Master
Techniques

Layered platform teams

Published: Apr 13, 2021
Apr 2021
Hold?

The explosion of interest around software platforms has created a lot of value for organizations, but the path to building a platform-based delivery model is fraught with potential dead ends. It's common in the excitement of new paradigms to see a resurgence of older techniques rebranded with the new vernacular, making it easy to lose sight of the reasons we moved past those techniques in the first place. For an example of this rebranding, see our blip on traditional ESBs make a comeback as API gateways in the previous Radar. Another example we're seeing is rehashing the approach of dividing teams by technology layer but calling them platforms. In the context of building an application, it used to be common to have a front-end team separate from the business logic team separate from the data team, and we see analogs to that model when organizations segregate platform capabilities among teams dedicated to a business or data layer. Thanks to Conway's Law, we know that organizing platform capability teams around business capabilities is a more effective model, giving the team end-to-end ownership of the capability, including data ownership. This helps to avoid the dependency management headaches of layered platform teams, with the front-end team waiting on the business logic team waiting on the data team to get anything done.