The backend is architected around implicitly creating a whole bunch of singletons and passing them around through import machinery. This makes it hard to develop any feature that touches multiple sub parts of the api because they all are intertwined, and as a user makes it very hard to use the api for offline testing or inspection to figure out what to do in a protocol.

• Control of hardware, such as serial connections with Smoothie and other peripherals, keeping track of which pipettes are currently mounted, and issuing move commands should be consolidated into a hardware abstraction layer in opentrons.hardware_control. This module will house the portions of the labware, instrument, and robot components that are concerned with serial connections (including commands, the "grantry/deck-calibration" half of the pose tree, and firmware update).

• The user-facing API (methods like Pipette.aspirate, labware.load, etc), the portion of the pose tree that tracks static objects (labware, modules, slots), and movement planning (such as arc path planning) should move into protocol_api. The server will use this module to simulate and run protocols. In both cases, protocol_api will compile the protocol into commands suitable to hardware_control (e.g.: "move right pipette to 100, 50, 25"), and then either simulate or run them.