Software development is full of models, frameworks, and methodologies. Many of them are abstract, heavyweight, or so generic that they offer little practical guidance.
The Tools & Materials approach (T&M), originally known as WAM – Werkzeug‑ und Materialansatz, is different. It is concrete, intuitive, and surprisingly modern. And it aligns far better with agile practices than one might expect.
Concrete metaphors instead of abstract models
T&M uses concepts that everyone intuitively understands:
- Materials are domain objects that are worked on.
- Tools are user-facing interfaces used to manipulate materials.
- Automata perform background processes autonomously.
- Domain Values define precise, immutable domain quantities.
- Services encapsulate logic that belongs neither in tools nor in automata.
These metaphors are not decorative — they are structural.
They create clarity because they mirror real work situations: people use tools to work on materials. Software should reflect that.
Mini-example:
A Purchase Order is a material.
The Order Form is a tool.
The Inventory Sync is an automaton.
The Unit Price is a domain value.
The Shipping Cost Calculation is a service.
Even this simple example shows how T&M provides orientation.
Clean separation of responsibilities
T&M defines a clear hierarchy:
- Domain Values know only themselves.
- Materials know domain values and other materials.
- Services know materials and domain values.
- Tools contain no domain logic.
- Automata run autonomously in the background.
This structure prevents coupling, reduces complexity, and keeps systems understandable even years later.
T&M is not just a model — it is a cognitive ordering system.
Natural compatibility with Agile
Agile describes how teams work: iterative, incremental, feedback-driven.
T&M describes how software is structured: clear, stable, modular.
They complement each other perfectly:
- Agile creates change.
- T&M absorbs change.
When requirements shift, T&M ensures that only the affected tool or material changes — not the entire system.
The architecture remains stable even as the product evolves.
This reduces decision fatigue and prevents the “we’ll fix the architecture later” trap.
Support for iterative development
T&M is modular by design:
- Materials can be developed independently.
- Tools can be built before all automata exist.
- Domain values are stable from day one.
- Services can be extended incrementally.
This modularity fits perfectly with short sprints and incremental delivery.
Teams can work independently without the architecture falling apart.
Avoiding technical debt
Many agile teams fall into the trap of delivering quickly and “fixing the architecture later.”
T&M prevents this because its structure is clear from the start:
- Tools contain no domain logic.
- Materials do not mutate into mini-services.
- Automata remain pure background processes.
- Domain values are explicit and immutable.
These rules are lightweight but powerful.
They protect the architecture without slowing down agility — and they make emerging technical debt visible early.
Human-centered and cognitively ergonomic
T&M originates from work psychology and sociology.
It is grounded in real work situations rather than theoretical abstractions.
This gives it a decisive advantage:
Its concepts are cognitively ergonomic.
They reduce mental load because they map to familiar activities.
Agile follows the same principle: people first, clarity over bureaucracy.
T&M and Agile align culturally and methodologically.
Surprisingly modern
Although T&M was developed in the 1990s, its ideas appear throughout modern architecture:
- Domain values correspond to Value Objects.
- Materials correspond to Entities.
- Services correspond to Domain Services.
- Tools correspond to UI layers.
- Automata correspond to Background Jobs.
The fact that T&M and Domain‑Driven Design evolved independently yet share similar structures shows how robust these underlying ideas are.
Final thought
Agile needs an architecture that does not fear change.
T&M provides exactly that: a clear, human-centered structure that reduces cognitive load, keeps systems stable, and enables continuous evolution.
It is not a replacement for modern architectural approaches —
it is one of their shared foundations.
Further English-language literature on the Tools & Materials Approach can be found in the book Object-Oriented Construction Handbook – Developing Application-Oriented Software with the Tools and Materials Approach by Heinz Züllighoven.