When complexity becomes structural in the laboratory environment

In laboratory environments, friction rarely appears overnight. It builds gradually, an extra validation step here, a local workaround there, a configuration change introduced to solve an urgent issue.

Each individual decision makes sense at the time. Over months and years, however, these small adjustments begin to shape daily work more than the original system design ever did, a pattern also described in research on architectural and structural complexity in IT systems (van den Hooff et al., 2026).

The laboratory continues to function, results are delivered, and systems remain stable. Yet maintaining that stability requires increasing effort, and over time complexity can shift from being situational to becoming structural.

What structural complexity looks like in practice

Structural complexity rarely presents itself as system failure. Instead, it shows up in everyday operational situations such as:

• A newly hired biomedical scientist needing significantly longer time to feel confident navigating workflows because processes rely on undocumented knowledge rather than transparent structure.
• A laboratory information system upgrade taking much longer than planned because accumulated local adaptations require extensive testing.
• A new instrument integration requiring unexpected customization because configurations differ between sites.
• A national reporting requirement that should require a straightforward configuration change instead demands extensive testing and multiple approvals because the system has evolved differently across sites.
• Cross-regional harmonization initiatives slowing down because systems have evolved in different directions over time.

One illustration of how this develops over time can be seen in the following scenario.

Consider a laboratory that has gradually introduced local configuration changes to accommodate specific reporting needs, temporary workarounds and audit findings. Years later, when a national regulatory update requires a simple reporting adjustment, the change affects multiple interdependent configurations. What should have been a straightforward update now requires extensive testing across sites, multiple approval steps and careful coordination between laboratory and IT. The complexity is not caused by the new requirement itself, but by the accumulated structure surrounding it.

A common example can be found in validation workflows. Additional approval steps are often introduced in response to audits, incidents or specific local risks. Individually, these adjustments are reasonable. Over time, however, approval chains may no longer reflect current risk levels or operational reality. What began as quality reinforcement gradually becomes operational friction.

The system still works, but it has become harder to change.

When stability turns into fragility

Laboratory systems rarely collapse under growing complexity. Instead, they lose elasticity.

Minor configuration adjustments begin to carry disproportionate risk. Upgrades require broader validation scopes. Modernization initiatives become dependent on key individuals who “know how things work.” What appears stable in daily operations may, in reality, represent a system that has gradually drifted from its original structure.

When complexity consumes change capacity, laboratories become slower to adopt new diagnostic methods, slower to respond to regulatory shifts, and less able to benefit fully from digital transformation and automation initiatives. Resources that could have been invested in innovation are instead spent preserving historical adjustments. Stability, in this context, can mask structural fragility.

What good looks like

Addressing structural complexity does not require replacing everything. It requires deliberate alignment.

In well-aligned laboratory environments, workflows are transparent rather than person-dependent. Configuration changes follow structured governance. Integrations are standardized wherever possible, and local adaptations are conscious, documented decisions rather than historical residues. Ownership of processes and system configuration is clearly defined, and modernization follows a roadmap instead of reacting to accumulated friction.

In such environments, upgrades become more predictable. Validation scopes become manageable. Cross-regional alignment becomes realistic. Modernization becomes evolutionary rather than disruptive. Most importantly, the laboratory regains elasticity: the ability to adapt without disproportionate effort.

Designing for coordinated evolution

Reducing structural complexity is not about eliminating variation for its own sake. It is about ensuring that laboratory systems can evolve without slowly drifting away from operational reality.

Modern laboratory information systems must therefore be designed with long-term adaptability as a core principle, not as an afterthought. Structured configurability, transparent integration models and clearly defined governance mechanisms are not optional enhancements, but architectural necessities in environments where change is constant.

This requires continuous coordination between laboratory, IT and vendor, as well as periodically revisiting assumptions: Which parts of the system reflect today’s practice, and which reflect historical adjustments that have never been reconsidered?

When coordination is treated as an ongoing responsibility rather than something addressed only during major initiatives, adjustments remain manageable and change becomes sustainable.

Challenging the status quo

When complexity becomes structural, daily operations may appear stable, yet the laboratory becomes less capable of handling change.

Challenging this does not begin with dramatic transformation. It begins with awareness. With asking whether current system configurations truly support today’s workflows. With examining where reliance on individuals has replaced structural clarity. With considering whether modernization efforts address root causes or simply layer new adjustments onto existing complexity.

For laboratories, this often means creating space to step back and evaluate whether existing system structures truly support long-term evolution. Reviewing structural complexity regularly should be part of normal laboratory governance, not just a reaction to crisis. For vendors, this means taking clear responsibility for how the system is designed and developed over time. Sustainable progress cannot depend only on customer requests. It requires a clear roadmap, consistent configuration practices and close collaboration between the laboratory, IT and vendor.

Structural complexity rarely happens because of a single decision. But preventing it from becoming part of the system is a shared responsibility, and vendors must take an active role in leading that work.

References

van den Hooff, B., Jochemsen, E., Rezazade Mehrizi, M., Plomp, M., & Mol, K. (2026). Modularisation and the management of IT architecture complexity. European Journal of Information Systems, 35(1), 90–108. https://doi.org/10.1080/0960085X.2025.2546388