ryanwold.net

A civic-minded citizen seeking the singularity

Back to Entries

I'm on a new project for a large system

draft
Date: 2026-04-26

i'm on a new project that is a large system, and as an Engineer, my inclination is to understand the broader system, as well as the sub-components. the software stack. the data. the environment. the clients. the users. the policies. the laws. this quickly takes me into domains that other staff may consider "theirs". i am drawn to the constructivist thinking of papert and piaget and contemporaries. is there a modern rebranding? i stubbornly called service blueprints and journey maps "business process models" because those are the abstraction that i think fits both - yet remains non-popular.

⏺ Your instinct has a name — several, actually, depending on which community claimed it first.

Searched for 1 pattern (ctrl+o to expand)

⏺ The rebranding you're looking for

Systems thinking is the umbrella — but that's been around since Senge's Fifth Discipline (1990) and feels dated to some. The fresher framings:

Sociotechnical systems design (STS) — explicitly includes people, policies, environment, and tech as co-equal parts of one system. Resurged hard in the 2010s through platform thinking and DevOps (Team Topologies is essentially applied STS).

Domain-Driven Design (DDD) — from Evans (2003), but the strategic patterns (bounded contexts, context maps, ubiquitous language) are exactly what you're describing: mapping the whole territory before diving into sub-components. Eric Evans would say you're doing context mapping.

Wardley Mapping — Simon Wardley's framework explicitly asks you to understand users → needs → components → environment, with evolutionary stage as a dimension. Very popular in the last 5-10 years with engineers who want to reason about the whole field.

Enterprise Architecture — the formal discipline for exactly this, but it's bureaucratically captured in most orgs (TOGAF, Zachman). You're doing EA without the theater.

Whole-system thinking — occasional rebrand used in sustainability and civic tech circles.


On constructivism's modern face

Papert's constructionism (build things to learn) maps pretty well onto:

  • Cynefin (Snowden) — sense-making framework that privileges probe-sense-respond over analysis paralysis
  • Learning organizations (Senge) — still alive in org design
  • Experiential learning design — corporate rebrand of Dewey/Piaget

The honest answer is constructivism never got a sexy rebrand because its practitioners tend to be in education or org theory, not product. The engineers who think this way often end up calling themselves staff/principal engineers or architects — the job title is the rebrand.


On "business process model" vs service blueprints / journey maps

You're right that BPM is the more rigorous abstraction. The reason it lost:

  • Journey maps were colonized by UX and consultants — they sell empathy, not rigor
  • Service blueprints come from service design — they add the frontstage/backstage cut but still lack execution semantics
  • BPM / BPMN has execution semantics (swimlanes, events, gateways) that journey maps lack — but practitioners found BPMN intimidating and "too IT"

The term that almost unified them: value stream map (Lean manufacturing origin) — which is also in your codebase (/value_stream). It has the timeline, actors, and flow that all three share, plus explicit waste/delay markers.

The gap you're naming: there's no widely-accepted term for "a model that is simultaneously a process model, a data model, an actor model, and a policy model." That's what you actually want. BPMN + DMN + CMMN (the OMG trilogy) tries to cover it, but it's a standards committee, not a movement.


The closest living community to your instinct is probably the Domain Storytelling crowd — which literally sits between constructivism, DDD, and business process modeling, and explicitly fights for shared language across roles. Worth a look if you haven't hit it yet.

By Ryan Wold · © 2026 Ryan Wold

Licensed CC BY-NC 4.0. AI training requires a license — machine-readable terms.

Tip: $afomi on HandCash · afomi@handcash.io