2. Why Business Design Engineering Is Needed

18th March 2026

Below is the 2nd part in our series on Business Design Engineering

BDE: Diffusion to Coherence

Introduction

The case for Business Design Engineering (BDE) begins with a problem that is widespread, costly, and often misdiagnosed.

In many organisations, business change is broken into adjacent but weakly integrated functions. One group shapes the value proposition. Another defines structure. Another translates the work into delivery artefacts. Another implements. On paper, this looks like sensible specialisation. In practice, it often produces something else: drift between what the organisation intended to achieve, what it is structurally capable of supporting, and what is ultimately delivered.

This is not merely a workflow inefficiency. It is a coherence problem.

As work moves from strategy to design, from design to architecture, from architecture to analysis, and from analysis to implementation, every hand-off introduces interpretive risk. The original logic of the intervention can weaken. A compelling concept may lose its force as it passes through siloed roles. Delivery may remain faithful to documented requirements while becoming increasingly detached from the value intent that justified the initiative in the first place. In that sense, fragmentation does not just slow change; it can actively distort it.

This concern is not new. Socio-technical systems thinking has long argued that organisational effectiveness declines when social and technical design are treated as separate concerns rather than mutually conditioning elements of the same system (Mumford, 2000). Broader design and management scholarship reaches a similar conclusion: organisations, management systems, and transformation interventions are all legitimate objects of design, and their cultural, structural, and operational dimensions cannot be cleanly separated without consequence (Buchanan, 2015; Faust & Junginger, 2016).

A second problem is feedback failure. In fragmented environments, delivery generates signals—progress, friction, maturity, constraint, unintended consequence—but those signals rarely travel back in a way that strengthens the original intervention logic or updates enterprise understanding meaningfully. Lessons may be captured, but they often remain localised, diluted, or administratively noted rather than structurally absorbed. The result is predictable: the same coherence failures are repeated across successive initiatives.

This is where BDE becomes significant. Its value is not limited to reducing handoff loss between functions. It also improves continuity of learning across the lifecycle, ensuring that delivery reality informs both intervention refinement and upstream business understanding.

A third issue lies in the false division between conceptualisation and realisation. In many models, Business Design is positioned as the activity of imagining future possibility, while Business Engineering is treated as the downstream task of making that possibility operationally viable. Conceptually, the distinction has merit. Business Design is concerned with desirability, proposition, and opportunity framing. Business Engineering is concerned with structural feasibility, operating logic, capability realisation, and governed implementation (Faust & Junginger, 2016; Österle & Winter, 2003; Winter, 2001).

The problem is not that these functions differ. The problem is that organisations often harden that difference into separate operating silos. When that happens, accountability for 'buildability', organisational fit, governance implications, and delivery consequence is pushed too far downstream. The designer may shape an attractive concept without remaining close enough to its practical landing. The engineer then inherits something already abstracted from implementation reality. What should be an interlocking relationship becomes an interpretive gap.

BDE is proposed as a response to that gap.

It does not replace Business Architecture, nor does it replace Business Analysis. Business Architecture remains the upstream anchor role that renders the enterprise legible through capability maps, value streams, operating concepts, and business blueprints (Business Architecture Guild, 2024). Business Analysis remains the downstream anchor role that elaborates needs, clarifies requirements, supports solution recommendation, and enables change through traceable implementation detail (Brennan, 2015).

What BDE provides is the missing continuity layer between those poles.

Its purpose is to remain close enough to both design intent and engineered realisation that the intervention does not become distorted by silo boundaries. It consolidates the practical concerns of Business Design and Business Engineering into one interlocking role or practice situated between architecture and analysis. The point is not to diminish specialist depth. The point is to reduce unnecessary interpretive hops between idea, structure, and landing.

This is why BDE matters most in high-ambiguity, high-interdependence environments: enterprise transformation, operating model redesign, platform initiatives, regulated change, and distressed or drifting programmes. In these settings, the challenge is rarely just to generate a better concept or produce a more detailed requirements pack. The challenge is to preserve intervention integrity across the whole chain, from enterprise framing and proposition logic through to structural feasibility, governance fit, delivery coordination, and realised value.

That is the role of Business Design Engineering. Not another fashionable title. Not role inflation, rather, a contraction of capability diffusion. It is a disciplined, lean, high-accountability practice designed to preserve coherence between business imagination and business realisation.

References

Brennan, K. (2015). A guide to the business analysis body of knowledge (3rd ed.). International Institute of Business Analysis.

Buchanan, R. (2015). Worlds in the making: Design, management, and the reform of organizational culture. She Ji: The Journal of Design, Economics, and Innovation, 1(1), 5–21.

Business Architecture Guild. (2024). A guide to the business architecture body of knowledge (3rd ed.). Business Architecture Guild.

Faust, J., & Junginger, S. (2016). Designing business and management. In R. Curedale (Ed.), Design thinking: Process and methods manual (contextual treatment of management and organisational design perspectives).

Mumford, E. (2000). A socio-technical approach to systems design. Requirements Engineering, 5(2), 125–133.

Österle, H., & Winter, R. (2003). Business engineering. In A.-W. Scheer, F. Abolhassan, W. Jost, & M. Kirchmer (Eds.), Business process change management (pp. 61–80). Springer.

Winter, R. (2001). Business engineering navigator: Gestaltung und analyse von geschäftsmodellen und geschäftsprozessen [Business engineering navigator: Design and analysis of business models and business processes]. Springer.