Architectural and Component Innovation

Distinguishes changes to individual parts of a system from changes to relationships among those parts.

Understanding this reference

Architectural innovation changes how a system’s components relate, while component innovation changes a part of the system. The distinction helps explain why a modest-looking change in connections can create organizational difficulty. Teams may know each part well but lack a shared view of dependencies.

How to use the idea in practice

Map the components and the interactions required for the system to work. Identify which interfaces change, which teams control them, and where assumptions may be embedded in older procedures. Prototype integration points early. A change can be technologically simple but operationally demanding if it alters many interfaces.

Applied learning example

Imagine a service combining appointment, payment, and notifications that were previously separate. No single feature may be unprecedented; the innovation lies in the new coordination. A prototype must evaluate failure recovery, data flow, privacy, and the experience of staff who operate the service.

Questions to bring to a workshop

• What specific decision or problem gives this method a useful purpose?
• What do we know from direct observation, and what remains an assumption?
• Who experiences the change, including people who might otherwise be left out?
• What is the smallest credible pilot or comparison we could run?
• Which evidence would persuade us to change direction rather than defend the plan?

Evidence, limitations and responsible interpretation

Avoid classifying innovations solely by marketing labels. The relevant architecture depends on the unit of analysis: a part might be a component in one context and a whole system in another. This is a modern explanation, not the recovered original learning handout.

The original destination is retained as a historical reference point. The writing above is a contemporary educational explanation; it must not be cited as a recovered source or used to attribute a statement to the former portal. For related research, consult ASQ: Plan–Do–Check–Act and follow its primary references where appropriate.

Documenting a meaningful result

Write a method note that distinguishes a research question, participant or data selection, procedure, observations and interpretation. For Architectural and Component Innovation, describe limitations openly: sample size, missing perspectives, ambiguous measures and the influence of the setting. Keep consent, confidentiality and possible unintended consequences visible rather than treating them as paperwork. If another team cannot tell what was observed and which assumptions remain, the activity is not documented well enough to support a design decision.

Before calling an exercise complete, ask who could challenge the conclusion, which trade-off remains unresolved, and what would count as persuasive counterevidence. Make the reasoning legible to someone who was not in the original meeting. When appropriate, ask users or affected stakeholders to review the interpretation before a proposal becomes policy. Evidence-based work is less about producing perfect certainty than about making choices open to correction.

Continue with the innovation toolkits, or browse the research and case-study collection to compare approaches across settings.