I'm on a new project for a large system
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