Before a lab buys a single instrument, it makes a set of decisions that will shape everything built afterward: how tightly the pieces are coupled, who is in charge of coordinating them, and where the methods that drive them live. These are architectural decisions, and like the architecture of a building they are cheap to change on paper and expensive to change once the structure stands. The strengths and weaknesses of an automated lab are largely decided here, often implicitly, before anyone writes a protocol.
This is a tour of the main architectural choices behind an automated lab, and an argument that the method layer, where your liquid classes live, deserves to be treated as an architectural decision in its own right rather than an afterthought bolted on once the hardware is chosen.
Monolithic versus modular
At one extreme, a workcell can be a single vendor's turnkey system: every device, the scheduler, and the software from one supplier, designed to work together out of the box. It is the fastest path to a running system and the least flexible one, because adding a device the vendor does not support, or swapping one for a competitor, ranges from awkward to impossible. At the other extreme, a modular architecture assembles best-of-breed devices behind a common integration layer. It costs more up front in integration effort and rewards you with the freedom to change one part without rebuilding the whole. Most real labs sit somewhere between, and knowing where you sit tells you what your next expansion will cost.
Centralized versus distributed control
A second axis is who coordinates the work. A centralized architecture puts one scheduler in charge of every device, which makes the whole workflow visible and easy to reason about but creates a single point of failure and a bottleneck as the cell grows. A distributed architecture lets devices or subsystems coordinate more loosely, which scales better and degrades more gracefully but is harder to observe and debug as a whole. Neither is right in the abstract; the choice follows from how large the system will get and how much unattended reliability you need.
The method layer is an architectural decision too
It is easy to treat architecture as a question of hardware and scheduling and stop there, but where your methods and liquid classes live is just as structural. There are two broad options, and they mirror the choices above. Methods can be scattered, a copy of each class held on the instrument that uses it, which is the path of least resistance and the source of the most pain later. Or methods can be a shared service, one catalog that every protocol and every device reads from, so there is exactly one definition of how a given liquid is handled. Scattered methods drift; a shared method layer stays coherent as the system grows, for the same reason a centralized scheduler makes a workflow legible.
Designing for change
Whatever the specifics, the architectures that age well share a few properties, and they are worth designing toward deliberately.
- Loose coupling: devices and software communicate through defined interfaces, so one can be replaced without disturbing the others.
- A shared method store: liquid classes and protocols live in one place the whole system reads, rather than in per-instrument copies that drift apart.
- Vendor-neutral definitions: methods expressed against a common vocabulary survive a change of hardware, where vendor-specific ones do not.
- Versioning throughout: every method and configuration change is recorded, so you can say what the system was doing on any given day and roll back when a change makes things worse.
- Standards where they exist: preferring devices and interfaces that speak an open standard keeps the architecture open rather than accreting private bridges.
Architecture is the set of decisions that are expensive to reverse. Where your liquid classes live is one of them, so decide it on purpose: one shared, versioned, vendor-neutral method layer rather than a copy on every machine.