More on this book
Community
Kindle Notes & Highlights
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.
The platform team’s knowledge is best made available via self-service capabilities via a web portal and/or programmable API (as opposed to lengthy instruction manuals) that the stream-aligned teams can easily consume.
“A platform team’s value can be measured by the value of the services they provide to product teams.”
As with commercial products, the platform can provide different levels of service. If all the stream-aligned teams ask for “premium level” services (e.g., zero downtime of the service, auto scaling, self-recovery in case of failure), then it will likely become impossible for the platform team to cope with demand.
A thick platform might consist of the combination of several inner platform teams providing a myriad of services. A thin platform could simply be a layer on top of a vendor-provided solution.
Platform examples at a lower level of the stack could range from provisioning a new server instance to providing tools for access management and security enforcement.
A platform team relies on fast prototyping techniques and involves stream-aligned team members for
fast feedback on what works and what does not.
A platform team leads by example: using the services they provide internally (when applicable), partnering with stream-aligned teams and enabling teams, and consuming lower level platforms (owned by other platform teams) whenever possible.
In these situations, a platform is composed of groups of other fundamental team types: stream aligned, enabling, complicated subsystem, and platform.
Yes: the platform is itself built on a platform
In a platform, the streams relate to services and products within the platform, which could be things like logging and monitoring services, APIs for creating test environments, facilities for querying resource usage, and so on.
From the viewpoint of the product owner of the platform, there are clear internal streams of value within the platform to which stream-aligned teams align to help them deliver value to the customers of the platform:
To make things worse, before 2013 new software-development projects were financed with capital expenditure (CapEx) but the IT operations activities were treated as operational expenditure (OpEx,) which produced a sharp divide between teams building things and teams running things.
So in 2013, we moved everyone to OpEx. Now everyone is simply doing the work needed to make the company money. With our OpEx-only model, everyone is closer to the customer because we are not thinking about “building new stuff for the product manager” but meeting the needs of users.
OpEx is a deliberate enabling constraint for us:
We also created a special continuous-delivery (CD) team to help other teams adopt CD practices, like automated deployment pipelines, test automation, rich monitoring, and automated environment provisioning.
As this enabling team got more of an understanding of what needed to be done, we realized that it made sense to turn this team into a kind of platform-development team
Within the platform area, we have several different squads, some focused on new product development for platform features (using standard Agile software development techniques like TDD [test-driven development], retrospectives, and product owners), and some focused on day-to-day operational activities.
Interestingly, unlike other organizations, we have never embedded Ops people in Dev squads. Instead, we have an Ops “squad buddy” for each Dev squad, a person from Ops who regularly works with specific Dev squads, attending their standups and providing the “glue” between Dev and Ops.
The sales department even does blameless post-incident reviews for missed sales opportunities!
we combine stream-aligned teams that support and operate software in production together with platform teams that provide the underlying “substrate” for stream-aligned teams.
Work is never handed off to another team for a later stage in the flow.
Solutions that require deep expertise in one area are likely to lose against simpler, easier-to-comprehend solutions that work for all members of the stream-aligned team.
ensure that the platform always serves the needs of consuming applications and services, not the other way round.
A good platform provides standards, templates, APIs, and well-proven best practices for Dev teams to use to innovate rapidly and effectively.
The simplest platform is purely a list on a wiki page of underlying components or services used by consuming software.
as the underlying substrate becomes more complicated—even if all components and services are still outsourced—a platform team can provide a valuable management abstraction over the details of the platform, dealing with the coordination of new and deprecated APIs and components.
If an organization needs to build custom solutions and integrations into the platform to meet the needs of Dev teams, then the activities of the platform team increase in scope further.
thinnest viable platf...
This highlight has been truncated due to consecutive passage length restrictions.
“software developers love building platforms and, without strong product management input, will create ...
This highlight has been truncated due to consecutive passage length restrictions.
a good platform helps Dev teams focus on the germane (differentiating) aspects of a problem, increasing personal and team-level flow, and enabling the whole team to be more effective.
“The most important part of the platform is that it is built for developers.
the platform teams have a focus on user experience (UX) and particularly developer experience (DevEx).
as the platform increases in size, expect to add UX capabilities to the platform teams.
There should be a way to give feedback to platform developers and how the platf...
This highlight has been truncated due to consecutive passage length restrictions.
A good test for DevEx is how easy it is to onboard a new Developer to the platform.
(1) treat the platform as a live/production system, with any downtime planned and managed, and (2) use software-product-management and service-management techniques.
define the hours of operation, define the response time for incidents and support, ensure we have an on-call rota to support the platform, manage incidents and unplanned downtime with suitable communication channels (such as service status pages),
The platform team will almost certainly be working with user personas for the users
A platform is not just a collection of features that Dev teams happened to ask for at specific points in the past, but a holistic, well-crafted, consistent thing that takes into account the direction of technology change in the industry as a whole and the changing needs of the organization. A good platform will also serve to reduce the need for security and audit teams to spend time with the Dev team.
Convert Common Team Types to the Fundamental Team Topologies
es importante la vision humanistica de que cada persona pueda ubicarse, dentro de los posible, en lo q le gusta: https://youtu.be/1p60fO1x5Ik?t=1321
teams. The change from infrastructure team to platform team is not simple or straightforward, because a platform is managed as a product using proven software development techniques that may be quite unfamiliar to infrastructure people.
Existing teams based on a technology component should either be dissolved, with the work going into stream-aligned teams or converted into another team type: as part of the platform (if the component is a lower-level “platform” component), to an enabling team (if the component is easy enough for stream-aligned teams to work with), or to a complicated-subsystem team (if the subsystem really is needed and really is too complicated for stream-aligned teams to work with).
the ratio of stream-aligned teams to other kinds of teams should be between about 6:1 and 9:1.
database-administrator (DBA) teams can often be converted to enabling teams if they stop doing work at the software-application level and focus on spreading awareness of database performance, monitoring, etc. to stream-aligned teams. Some organizations have had success converting a DBA team into part of the platform, providing a specialized service around database performance, configuration, availability, and so forth, but the DBA team is no longer responsible for schema changes or application-level database concerns.
Tooling teams are typically better run either as enabling teams—with a short-lived and highly focused remit—or as part of the platform (with a clear, well-informed roadmap).
(1) support teams aligned to the stream of changes, and (2) dynamic cross-team activity to resolve live service incidents.
adding end-to-end synthetic transaction monitoring,
“service-experience teams”
