When to separate

• Separate when the performance of a highly integrated product is not needed
• Create manageable problems by separating system elements
• Use more separation when product performance is already good enough
• Use more separation when transactions cost are low
• Use more separation to reduce risk. . . and reward
• Use more separation when the cost of failure is high
• Some separation is always required to create a manageable situation

Separate using modules

• Manage system elements using abstraction and modularity
• Manage abstraction and modularity with interfaces
• Maintain a system-level model that guides the development of individual modules
• Isolate variability, risk, and uncertainty
• Isolate areas likely to change
• Group related elements and separate unrelated
• Group elements with high rates of information or energy exchange
• Group elements that are frequently used together
• Separate to send finished products to other modules
• Separate to reduce complexity differences between system elements
• Separate so modules exchange inputs and outputs at similar levels of abstraction
• Separate so modules each do specific and different things
• Separate to create checks and balances
• Separate using physical barriers or space
• Separate with time delays between action and response
• Separate based on knowledge needed to perform tasks, not the order in which tasks occur
• Separate frequently used functionality

Interface modules

• Design interfaces to manage module interconnections
• Make the interfaces clear and visible
• Simplify interfaces to limit complexity imposed on the overall system
• Design interfaces to be significantly simpler than the modules
• Simplifying the interface usually requires more complex modules
• Design interfaces to increase the probability a module can be changed without affecting the interface
• Design interfaces between the system and the environment
• Design external module functionality before internal functionality
• Minimize physical points of contact
• Standardize physical interface types
• Enforce the interface requirements
• Test the interfaces before testing the complete system
• Create better, rather than more, interfaces
• Use interfaces to minimize dependencies between modules (loose coupling)
• Only send data to modules with “a need to know”
• Use activity sequencing to minimize interdependencies
• Postpone fixed connections until the last possible moment
• Use control limits to identify issues and intervene before reaching hard limits
• Create collections of reusable modules
• Use configuration options to adjust and reuse modules
• Set default configuration to cover all but exceptional situations