Separate the parts to decide where a change belongs.
An availability rule changes. Another tool needs a connection. A portal needs to show an additional piece of information. Each request sounds focused, yet it may affect several parts of a platform.
To keep that work understandable, we organize Boutik into distinct layers. Think of building blocks: identify the role of each piece, how it connects to the others and where an adaptation belongs.
Three layers with distinct responsibilities.
The first layer contains common mechanisms, including change detection and the data model. It provides a shared structure for information used by the other parts of the solution.
The second adapts that structure to the language of the ERP, or enterprise resource planning system. Field names, documents and their organization vary between environments. This layer translates exchanges according to what the system makes available and what the project requires.
The third is the website or application people use. It presents information and actions according to their role and task. A customer portal and an internal tool can have different interfaces while relying on common mechanisms underneath.
Boutik’s three design layers
01Common mechanismsChange detection and a shared data model.
02System adaptationTranslation of data and exchanges for the ERP involved.
03Website or applicationInformation and functions presented to users.
Each layer can be configured, extended or replaced as needed. Connections between layers still require design, validation and maintenance; this diagram does not show the direction of every exchange.
Configure, extend and replace are different decisions.
Configuration uses a capability already provided by the relevant layer. Before adding code, we check whether its settings can meet the requirement. The configuration also needs to remain understandable to the people who will be responsible for it.
Extension adds a focused behaviour while preserving the layer’s role. A module can hold a business-specific rule, together with the data and validation it needs. The scope of that addition and its interactions with other parts should be explicit.
Replacement becomes relevant when a component no longer suits its context. That might involve an interface or an adaptation to a changing system. Clear responsibilities help identify what needs to be rebuilt and what may be retained. We still need to verify the effects on the other parts of the platform before deciding how to proceed.
A specialized inventory rule needs an identifiable place.
For a rope distributor, we incorporated a distinction between prepared lengths and lengths that could be made from shared material into a module. From an architectural perspective, the challenge was to give that logic a clear, identifiable home.
That kind of adaptation requires us to define the data the rule receives and the information it must provide to the ordering workflow. The interface then needs to present the result clearly. Keeping those roles visible lets us examine a calculation change and a display change in their respective places.
The example shows why it helps to focus an intervention. The module addresses a particular business need within a foundation whose other parts retain their responsibilities. The same principle can guide business applications and automation beyond commerce.
Check the boundaries between layers.
Whenever data moves between components, its meaning needs to be agreed on. Is a quantity ready to ship, or does it represent material available for production? Does a status mean a document was received or processed? The same terms need to describe the same situation at each handoff.
Before a change, we identify the workflows that depend on the component being modified and the cases that should be checked again. For a specialized rule, the usual case may not be enough: a stock limit, missing data or a combination of choices can reveal an important effect. These cases help define the actual scope of validation.
Plan maintenance during design.
A recent or older ERP, an application and an external service each have their own constraints and changes over time. We assess the available interfaces and access before defining a connection. Modular architecture provides a method for organizing the work; each environment still needs its own assessment.
Design decisions also need documentation: which part holds the rule, why it was adapted and which behaviours must remain valid. That knowledge helps the customer and developers continue the project with a shared understanding, rather than reconstructing the reasoning behind every choice.
Our goal is to discuss future development with a clear view of its scope. The questions become practical: which part changes, which other parts are affected and what work will make the resulting solution coherent? Those answers help frame an evolution that the team can understand and maintain.
Before changing a component
✓ Identify the rule or experience that needs to change.
✓ Locate the relevant data, system adaptation and interface.
✓ Check whether existing configuration can meet the need.
✓ Identify the workflows and exceptions to validate again.
✓ Document responsibility for the change and its maintenance.
