Back in the 2000s, we wrote applications in layers.
Presentation layer, client, data transfer, API, business logic, data access, database. We maintained strict separation bet ween these layers, even though every new feature changed all of them. Teams organized around these layers. Front end, back end, DBAs.
Layers crisscrossed the flow of data.
Responsibility for any one thing to work fell across many teams.
Interfaces between teams updated with every application change.
Development was slow and painful.
In 2019, we write applications in layers.
A business unit is supported by a feature team. Feature teams are supported by platforms, tooling, UI components. All teams are supported by software as a service from outside the company.
Back in the day, front end, back end, operations, and DBAs separated because they needed different skills. Now we accept that a software team needs all the skills. We group by responsibility instead — responsibility for business value, not for activities.
Supporting teams provide pieces in which consistency is essential: UI components and some internal libraries.
Interfaces between teams change less frequently than the software changes.
Layers crisscross the flow of value.
Feature teams need to do everything, from the old perspective. But that’s too hard for one team — so we make it easier.
This is where Developer Experience (DevEx) teams come in. (a.k.a. Developer Productivity, Platform and Tools, or inaccurately DevOps Teams.) These undergird the feature teams, making their work smoother. Self-service infrastructure, smooth setup of visibility and control for production software. Tools and expertise to help developers learn and do everything necessary to fulfill each team’s purpose.
Internal services are supported by external services. Managed services like Kubernetes, databases, queueing, observability, logging: we have outsourced the deep expertise of operating these components. Meanwhile, internal service teams like DevEx have enough understanding of the details, plus enough company-specific context, to mediate between what the outside world provides and what feature teams need.
This makes development smoother, and therefore faster and safer.
We once layered by serving data to software. Now we layer by serving value to people.