Engagement Types

Overview

Almost everything written about architecture assumes one setting: a company building its own product, intending to own it indefinitely. Much architectural work happens elsewhere, and advice carried across unchanged produces confident mistakes.

The four settings differ in one variable that drives everything else: who lives with the consequences, and for how long.

The four

Product development. You build a system your own company will own for years. The consequence lands on you, so long-term maintainability is genuinely in your interest, and the artifacts that matter are the ones that compound — decision records, a description that stays current, boundaries that will hold. This is the setting the rest of this guide assumes.

Outsourcing. You build a system someone else will own. The consequence lands on them, after you have left — which changes the artifact set fundamentally. Handover documentation stops being hygiene and becomes the deliverable, and the strongest design is often the least clever one, because it will be maintained by a team you will never meet, with skills you do not control. The characteristic failure is building something excellent that the receiving team cannot operate.

Systems integration. You connect systems you do not own and cannot change. Your leverage is almost entirely at the boundaries: contracts, translation, failure handling, and the question of what happens when one side changes without telling you. Internal elegance is nearly irrelevant; defensive design is the whole job.

Digital transformation. You change how an organisation works, with technology as the instrument. The technical difficulty is usually the smaller half. Module 8’s organisational reading is not a supporting skill here but the primary one, and the characteristic failure is a technically sound programme that the organisation routes around.

graph TD
  A["<b>Product</b><br/>you own the consequence<br/><i>artifacts that compound</i>"] --> E["Who lives with it,<br/>and for how long?"]
  B["<b>Outsourcing</b><br/>they own it after you leave<br/><i>handover is the deliverable</i>"] --> E
  C["<b>Integration</b><br/>nobody owns both sides<br/><i>boundaries are the job</i>"] --> E
  D["<b>Transformation</b><br/>the organisation is the system<br/><i>influence is the job</i>"] --> E

  classDef t fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef q fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  class A,B,C,D t
  class E q

Four settings, one question underneath them. The answer determines which artifacts are worth producing and which are theatre.

What transfers, and what does not

Transfers unchanged: the ability to find architecturally significant requirements, reason about trade-offs under constraints, and read an organisation. These are the durable skills, which is why Modules 2, 8 and 9 were worth their time regardless of setting.

Does not transfer: the artifact set, the time horizon, and what counts as good. A strangler migration sequenced over four years is a sound product strategy and nonsense on a nine-month integration contract. Handover documentation is the deliverable in one setting and overhead in another. Decision records compound over years in product work and may never be read in a short engagement.

The failure to watch for is an architect carrying one setting’s instincts into another — long-horizon product thinking applied to an integration where you will not be present to see the second year, or outsourcing’s defensive minimalism applied to a product the company will own for a decade.

Mixed settings

Most real work is a blend, and the blend is worth naming explicitly because the parts need different treatment.

A product company integrating a third-party capability is doing product development and systems integration, and the integration boundary deserves defensive design that the rest of the system does not need. A product initiative that changes how a department works carries a transformation component, and that part is governed by Module 8’s rules rather than by technical ones.

Naming which part of your work sits in which setting is the practical use of this topic — it tells you where to spend documentation effort and where defensive design earns its cost.

Product work, with two borrowed settings

Primarily product development. The company owns the system, intends to for years, and bears every consequence — so the compounding artifacts are the right investment, which is what Module 9’s practice assumed.

But two components of this initiative are not product work, and treating them as such would be a mistake.

The model provider is systems integration. An external dependency that cannot be changed, whose behaviour shifts without coordination, and whose interface is owned by someone else. Everything from Module 6 about degradation and Module 7 about version drift is integration discipline rather than product discipline. The practical consequence: defensive design at that boundary is worth real engineering effort, including the fallback ladder, strict output validation, and a measured answer to what happens when a model version is deprecated with a quarter’s notice.

The monolith is now an integration boundary too, which is the previous topic’s finding arriving with consequences. At four more years of dependency, the API the action service depends on is a long-lived contract with a system owned by another team and a de facto owner with an informal veto. The defensive posture integration calls for — explicit versioning, monitored assumptions, graceful behaviour when the other side changes — applies to an internal dependency, which is unusual and correct here.

And the support team’s change is a transformation component. Forty-five support agents across three time zones have their work reshaped, which is an organisational change using technology as the instrument. The technical part is the smaller half. Module 8’s reading of a quiet aversion to publicly recorded failure and Module 8’s sponsorship work are the load-bearing skills for that component, not the architecture.

What this changes in practice. Documentation effort concentrates on the two integration boundaries, because those are where the system meets things it does not control. The transformation component gets Grace Adeyemi’s involvement and a rollout sequence rather than a design document. And the product core — the retrieval and action services — gets the compounding artifact set, because that is the part the company will own and maintain for a decade.

Feeds the workbook

This lens shapes your legacy strategy: which boundaries get defensive integration treatment and which get product-grade internal design, and where documentation effort is concentrated.

Check your understanding

1. Which setting is your current work in? Name the parts that are actually in a different one.
2. Take a practice you believe in. In which of the four settings would it be waste?
3. An internal dependency behaves like an external one. What changes about how you design against it?

---

→ Three lenses on the situation. Now the thing everyone names and few define. — Technical debt, precisely