Throughput is defined to be the average rate of delivery of an acceptable products through a production system. Architectures are often driven by throughput considerations, and the constraints which must be confronted are often the focus of the design of the system's components. This throughput (and the reliability of assessments made of it) can be impacted by many factors, including the regularity of its inputs, the size and nature of queues which arise in processing throughout the system, the usable bandwidth and availability of channels for inputs, processing, and outputs, production losses due to coordination or quality issues, and impacts due to congestion.
A depiction of system throughput which involves people, and the challenges in implementing changes to it within an organization are shown in the graphic on the right. For a larger representation of this depiction, just click on the image.
In Systems Thinking: Managing Chaos and Complexity, Jamshid Gharajedaghi describes the key requirements for improving the throughput of a system:
... even a simple throughput consists of a chain of events and activities need to be integrated. Since these activities are usually carried out by different groups in different departments of an organization, strong interfaces and effective coupling among them are a must... To design a throughput system, we need to:
- Know the state of the art, as well as the availability and feasibility of alternative technologies and their relevance to the emerging competitive game.
- Understand the flow, the interfaces between active elements, and how the coupling function works
- Appreciate the dynamics of the system - the time cycle, buffers, delays, queues, bottlenecks, and feedback loops
- Handle the interdependencies among critical variables, plus deal with open and closed loops, structural imperatives, and system constraints.
- Have an operational knowledge of throughput accounting, target costing, and variable budgeting.
Given the constraints of technical risks and cultural adoption, and the inevitable uncertainties of implementation, I'd add four things to Gharajedaghi's requirements:
- Perform a reliable assessment of the dynamic interactions of existing system components to identify known bottlenecks
- Determine what changes will provide the greatest performance returns for those roadblocks, considering investments in process capabilities, organizational maturity, and associated changes to subsystem components.
- Define the target reference architecture that will be employed to incorporate these changes over time
- Establish a roadmap for those changes
- Allocate the target performance objectives to components within this roadmap to realize optimal sustainable performance improvements over time
- Determine how much of this change can be successfully accomplished within the next iteration
- Manages the change process for these components
- In parallel, lean out the system, with particular focus on the system's administrative functions, so that desired efficiencies are achieved over time.
While a theoretical peak throughput may be achievable for short bursts in a system, projections of change to sustainable throughput should be conservative, as such changes will only have impact as higher-rate throughput accumulates over time. Realizing such improvements will thus be a function of the sizing and resources available for servicing internal queues between and within components, and the ability of the system to adapt and reconfigure in response to changing demands.