Preventing architectural decisions from slowing us down

If product development is too slow, we almost reflexively look for the cause in the processes. So we optimize them, introduce new tools or increase the pressure on the teams. But in many cases, the actual cause is much older: we slowed ourselves down when we made architectural decisions that determined how changes would propagate through the system.

Architecture does not automatically make product development fast or slow. But it does determine how expensive change will be. As soon as we define system boundaries, interfaces and dependencies, we decide whether future changes will flow or get stuck. This article reveals an uncomfortable realization: Architecture is always also an economic decision about delay. If we get it wrong, no amount of subsequent process tuning will bring us back to product velocity.

Architecture as an enabler for flow

In the context of Product Velocity, architecture is the structural foundation that Flow enables or prevents. By defining components, responsibilities and interfaces, we determine which work can be carried out independently, which decisions remain local and where coordination is unavoidable.

Flow breaks down where changes spread too far. A small adjustment results in rework across several teams, reviews pile up at interfaces, integration becomes a permanent problem. Good architecture counteracts this by localizing change. Stable boundaries allow parallel work. Synchronization is replaced by explicit structure. Processes can only optimize flow within these architectural boundaries. Structural bottlenecks cannot be „processed away“ later.

Product classification as an architectural reality check

Architecture is never created in a vacuum. Products come with structural constraints that determine which architectures are viable at all. If we treat fundamentally different products in the same way, we systematically create mismatches: Architectures that cannot evolve, cycles that cannot be sustained and governance that collapses under load.

A pragmatic way of making these constraints visible at an early stage is the Product classification. It does not prescribe methods, but calibrates architectural decisions to the reality of the product. Before we design the architecture, we should understand it, What a product we are actually building.

The ones in my Product classification The dimensions described above reveal which architectural decisions need to support change and where we are deluding ourselves about speed. If we ignore these constraints, we only postpone the costs. They reappear later as coordination costs, verification burdens and delays.

Architectural decomposition: where are the boundaries?

Architectural decomposition answers a central question: Where do we draw the line? These boundaries determine which changes remain local and which propagate through the system. Good decomposition groups responsibilities that change together and separates those that do not. High cohesion keeps changes local. Low coupling prevents cascades.

To the outside world, components must be Black Boxes function. Interfaces clearly define what is provided and required. Everything behind this remains deliberately hidden. This allows teams to rely on stable contracts without having to constantly synchronize. Internally, boundaries must not be black boxes. Teams need transparency to be able to assess quality, risks and trade-offs. Non-transparent internal information leads to fragile implementations and local entropy.

A simple test is the question of change impact: if most of the expected changes require coordination across multiple boundaries, the decomposition is wrong. Product classification provides strong evidence for this. High integration complexity, long lifecycles or regulatory requirements call for more deliberate boundaries and more robust interfaces. If we ignore this, architecture creates invisible queues.

Architectural aspects: Making systemic properties explicit

Decomposition alone is not enough. Architectural aspects address properties that must apply across borders. Safety, security, performance, reliability or compliance are not properties of individual components. They are systemic commitments.

These aspects become expensive if we postpone them. If we treat them as downstream, we shift their costs to integration and verification, exactly where trade-offs are most difficult to manage. Good boundaries localize the impact of aspects. Bad boundaries amplify them. A small security change suddenly results in global adjustments. A reliability goal requires comprehensive coordination because responsibilities are unclear.

Aspects need explicit responsibility at system level. This does not mean central implementation, but clear ownership for the target image, boundary conditions and evidence. Without this stewardship, local optimizations accumulate and the system gradually loses the ability to make reliable statements about its behaviour.

Representing architecture means replacing coordination

Architecture only unfolds its value when it is explicit and shared. Representation is a coordination mechanism. It replaces repeated coordination with stable references that allow independent thinking without losing alignment.

It all starts with a common metamodel. We have to agree on which architectural elements exist and how they are connected. Based on this, views and viewpoints are created for different issues, such as those in ISO 42010 are described. Developers need structural and interface views, management needs dependencies and responsibilities, assurance roles need clarity about evidence and scopes. A single view is never enough.

Model-based systems engineering is a natural fit here. For simple products, simple representations are sufficient. For complex cyber-physical systems, executable artifacts alone are no longer sufficient. Explicit models prior to integration help to understand structure, behavior and interfaces across disciplines. MBSE is not an end in itself and not a process ideology. It is justified when complexity and verification requirements make informal representations unreliable.

Architectural antipatterns that destroy velocity

Certain architectural „smells“ reliably announce a loss of speed. They are rarely intentional and often go unnoticed for a long time.

A classic is „accidental architecture“. The structure reflects organizational boundaries (Conway's Law) or implementation history, not conscious design decisions. Boundaries follow technologies instead of change dynamics. Abstractions are leaky, internal assumptions seep through interfaces and force coordination.

Another pattern is the dominance of the slowest component. If fast-moving software is closely linked to slow hardware or certification cycles, the overall system moves at a snail's pace. Organizations react with additional releases. The actual cause is structural.

Implicit architecture is particularly damaging. Central decisions only exist in heads or scattered documents. Coordination is relegated to meetings and reviews. The system still works, but every change costs more than expected.

Conclusion

Architecture decisions determine product velocity quietly but sustainably. They determine how changes spread, where queues arise and how expensive learning becomes. Once development has begun, these decisions are difficult to correct. Processes can improve execution, but they cannot compensate for structural errors.

The quickest lever is diagnostic. Look at your system and ask yourself: Where does a small change end up? If the honest answer is „almost everywhere“, Velocity has already been destroyed at the architectural level.

Product Velocity understands architecture as an economic lever, not as a technical artifact. Classify the product, consciously decompose, make aspects explicit and use architecture as a common reference. Then change remains favorable. If we ignore this, speed disappears silently long before we miss it.