That was not a chapter but a section in the existing chapter.

Author: mcasperson

_includes/choosing_responsibility.html

@@ -215,6 +215,136 @@ <h2>The Responsibility Triad</h2>
     centrally maintain them over time. An IDP is only as valuable as its ability to affect change at scale, and keeping
     the responsibility triad in mind as you develop your IDP ensures its scalability over the long term.</p>
 
+<h2>Choosing a responsibility model</h2>
+
+<p>Those looking to introduce platform engineering into existing DevOps teams face three common realities:</p>
+
+<ul>
+    <li>Your IDP is a greenfield project</li>
+    <li>Your platform team must reduce the mental burden of an existing, complex environment</li>
+    <li>Your customers are technically adept</li>
+</ul>
+
+<p>
+    The purpose of an IDP is to generate opinionated artifacts embedding the accumulated business knowledge and best
+    practices learned by your customers over the years. By design, these artifacts abstract away much of the tribal
+    knowledge required to build high quality solutions, allowing DevOps team to focus on solving novel problems rather
+    than duplicating the effort required to solve already solved problems.
+</p>
+
+<p>
+    The challenge when developing such abstractions is to strike the right balance between hiding complexity and
+    enabling flexibility.
+</p>
+
+<p>
+    Platform teams have the added challenge of being compared to the established platforms their IDP seeks to
+    abstract away. The reality is that these existing platforms were adopted because of the many years, countless hours,
+    and eye-watering sums of money that were spent refining the balance between complexity and flexibility. For example,
+    popular operating systems, hypervisors, cloud platforms, and container orchestration platforms all have billions
+    of dollars worth of development behind them.
+</p>
+
+<p>
+    Meanwhile, enough of your customers will be comfortable with these underlying platforms, meaning they will quickly
+    spot, and likely be frustrated by, the limitations of your abstractions. This risks making your IDP the kind of
+    blocker that it was supposed to remove.
+</p>
+
+<p>
+    It is not a question of whether abstractions are valuable or possible to build correctly, as every successful piece
+    of
+    technology is an example of building a useful abstraction: a car abstracts the complexity of an engine and
+    transmission behind a steering wheel, accelerator, and brake; an electrical powerpoint abstracts the continent sized
+    infrastructure of a power grid; and a phone abstracts a worldwide communication network. The better question,
+    especially for new platform teams, is whether you have the knowledge to create the correct level of abstraction?
+</p>
+
+<p>
+    The only safe initial answer to this question is "No", with an aim to reach the point where the answer is "Yes,
+    but...".
+    While you will never have perfect knowledge of your customer's needs, a successful platform team can refine their
+    abstractions over time. But you do need to have some level of early success to earn the time required to refine
+    the artifacts provided by your IDP.
+</p>
+
+<p>
+    Anyone aiming to provide an opinionated solution faces this same dilemma, but the survivorship bias of every
+    successful abstraction you see in daily life can make it seem like building abstractions is easy. However, new
+    platform teams must assume building abstractions is, in fact, quite difficult, and therefor have a plan to support
+    customers with unique needs or opinions of their own. This is the crux of the responsibilities presented in
+    the chapter "Platform Engineering Responsibility Models":
+</p>
+
+<ul>
+    <li>
+        Centralized responsibility (or "enforced consistency") artifacts provide highly opinionated solutions exposing a
+        relatively small number of
+        options to customize the end result. The
+        success of the centralized responsibility model is highly dependent on how closely aligned your abstractions are
+        to the needs of your customers.
+    </li>
+    <li>
+        Shared responsibility (or "eventual consistency") artifacts can be modified by customers, providing them with
+        the ability to customize their
+        solution while still allowing the platform team to centrally distribute updates. These artifacts are the most
+        flexible and provide a sliding scale between enforcing opinions and exposing flexibility (with the caveat that
+        increased
+        customization will typically decrease the ability to centrally distribute updates). The shared responsibility
+        model assumes abstractions will be imperfect and emphasises a workflow that allows platform teams and their
+        customers to jointly refine the solution over time.
+    </li>
+    <li>
+        Customer responsibility (or "eventual inconsistency") artifacts provide customers with a base template that they
+        are expected to own and
+        modify to suit their needs. While the templates can provide an initial set of opinions, they are
+        expected to be heavily modified. The customer responsibility model assumes customers will keep what is useful
+        and discard what is not.
+    </li>
+</ul>
+
+<p>
+    An anti-pattern to avoid when starting a new platform team is focusing too heavily on the centralized responsibility
+    model. This
+    model requires that you build the most accurate abstractions, and starting a new platform team is the time when you
+    have the least amount of information to do so.
+</p>
+
+<p>
+    Instead, new platform teams should aim to initially offer artifacts under the shared responsibility or customer
+    responsibility models.
+</p>
+<p>
+    In the unlikely event that you managed to get your abstractions just right first time, there is little practical
+    difference between the three responsibility models, as the resulting solutions will all remain mostly unchanged
+    from the initial artifact generated by your IDP. However, in the more likely event that your abstractions require
+    refinement, the shared responsibility model allows you to work with your customers to evolve your abstractions, and
+    the customer responsibility model allows customers to make whatever changes they need.
+</p>
+
+<div><img class="icon" alt="Anecdotes Icon" src="images/anecdote.png"/></div>
+
+<p><i>
+    I was part of a team that designed new steps in Octopus to deploy applications to Kubernetes and AWS ECS. One of the
+    challenges in designing these steps was deciding how to support use cases we hadn't anticipated or might be
+    introduced
+    by the underlying platforms after our steps were released. After spending some time thinking about all the hooks or
+    custom scripting we could expose in these steps, we decided that the best course of action was to offer both
+    highly opinionated steps that supported most common use cases and generic steps that allowed the deployment of
+    raw YAML for either Kubernetes resources or CloudFormation templates. Importantly, the opinionated steps offered a
+    way
+    to export the equivalent YAML that they would generate, giving customers a way to jump from the opinionated step
+    (which aligns with the central responsibility model) to the generic step (which aligns with the customer
+    responsibility model).
+</i></p>
+
+<p><i>
+    This kind of "break glass in emergency" process to move from one responsibility model to another meant we could
+    offer a path for any customers blocked by a lack of functionality in the opinionated steps, with the understanding
+    that customers had to take more responsibility for what was now considered bespoke YAML. This is a practical, and
+    now battle tested, example of the responsibility models in action.
+</i></p>
+
 <h2>Example Checklist</h2>
 
 <p>This example checklist lists artifacts produced by the IDP and defines the responsibility model associated with each.

_includes/responsibility.html

@@ -15,7 +15,6 @@
     {% include pe_value.html %}
     {% include planning.html %}
     {% include responsibility.html %}
-    {% include choosing_responsibility.html %}
     {% include tenpillars.html %}
     {% include epilouge.html %}
 </body>