C. Design Standard
The ideas in this book are simple and consistent both internally and with every other engineering discipline. However, it can be overwhelming at first to come to terms with this new way of thinking about system and project design. Over time and with practice, applying these ideas becomes second nature. To facilitate absorbing them all, this appendix offers a concise design standard. The design standard captures all the design rules from this book in one place as a checklist. The list on its own will not mean much, because you still have to know the context for each item. Nevertheless, referring to the standard can ensure that you do not omit an important attribute or consideration. This makes the standard essential for successful system and project design by helping you enforce the best practices and avoid the pitfalls.
The standard contains two types of items: directives and guidelines. A directive is a rule that you should never violate, since doing so is certain to cause the project to fail. A guideline is a piece of advice that you should follow unless you have a strong and unusual justification for going against it. Violating a guideline alone is not certain to cause the project to fail, but too many violations will tip the project into failure. It is also unlikely that if you abide by the directives that you will have any reason to go against the guidelines.
The Prime Directive
Never design against the requirements.
Directives
Avoid functional decomposition.
Decompose based on volatility.
Provide a composable design.
Offer features as aspects of integration, not implementation.
Design iteratively, build incrementally.
Design the project to build the system.
Drive educated decisions with viable options that differ by schedule, cost, and risk.
Build the project along its critical path.
Be on time throughout the project.
System Design Guidelines
Requirements
Capture required behavior, not required functionality.
Describe required behavior with use cases.
Document all use cases that contain nested conditions with activity diagrams.
Eliminate solutions masquerading as requirements.
Validate the system design by ensuring it supports all core use cases.
Cardinality
Avoid more than five Managers in a system without subsystems.
Avoid more than a handful of subsystems.
Avoid more than three Managers per subsystem.
Strive for a golden ratio of Engines to Managers.
Allow ResourceAccess components to access more than one Resource if necessary.
Attributes
Volatility should decrease top-down.
Reuse should increase top-down.
Do not encapsulate changes to the nature of the business.
Managers should be almost expendable.
Design should be symmetric.
Never use a public communication channels for internal system interactions.
Layers
Avoid open architecture.
Avoid semi-closed/semi-open architecture.
Prefer a closed architecture.
Do not call up.
Do not call sideways (except queued calls between Managers).
Do not call more than one layer down.
Resolve attempts at opening the architecture by using queued calls or asynchronous event publishing.
Extend the system by implementing subsystems.
Interaction rules
All components can call Utilities.
Managers and Engines can call ResourceAccess.
Managers can call Engines.
Managers can queue calls to another Manager.
Interaction don’ts
Clients do not call multiple Managers in the same use case.
Managers do not queue calls to more than one Manager in the same use case.
Engines do not receive queued calls.
ResourceAccess components do not receive queued calls.
Clients do not publish events.
Engines do not publish events.
ResourceAccess components do not publish events.
Resources do not publish events.
Engines, ResourceAccess, and Resources do not subscribe to events.
Project Design Guidelines
General
Do not design a clock.
Never design a project without an architecture that encapsulates the volatilities.
Capture and verify planning assumptions.
Follow the design of project design.
Design several options for the project; at a minimum, design normal, compressed, and subcritical solutions.
Communicate with management in Optionality.
Always go through SDP review before the main work starts.
Staffing
Avoid multiple architects.
Have a core team in place at the beginning.
Ask for only the lowest level of staffing required to progress unimpeded along the critical path.
Always assign resources based on float.
Ensure correct staffing distribution.
Ensure a shallow S curve for the planned earned value.
Always assign components to developers in a 1:1 ratio.
Strive for task continuity.
Integration
Avoid mass integration points.
Avoid integration at the end of the project.
Estimations
Do not overestimate.
Do not underestimate.
Strive for accuracy, not precision.
Always use a quantum of five days in any activity estimation.
Estimate the project as a whole to validate or even initiate your project design.
Reduce estimation uncertainty.
When required, maintain correct estimation dialog.
Project network
Treat resource dependencies as dependencies.
Verify all activities reside on a chain that starts and ends on a critical path.
Verify all activities have a resource assigned to them.
Avoid node diagrams.
Prefer arrow diagrams.
Avoid god activities.
Break large projects into a network of networks.
Treat near-critical chains as critical chains.
Strive for cyclomatic complexity as low as 10 to 12.
Design by layers to reduce complexity.
Time and cost
Accelerate the project first by quick and clean practices rather than compression.
Never commit to a project in the death zone.
Compress with parallel work rather than top resources.
Compress with top resources carefully and judiciously.
Avoid compression higher than 30%.
Avoid projects with efficiency higher than 25%.
Compress the project even if the likelihood of pursuing any of the compressed options is low.
Risk
Customize the ranges of criticality risk to your project.
Adjust floats outliers with activity risk.
Decompress the normal solution past the tipping point on the risk curve.
Target decompression to 0.5 risk.
Value the risk tipping point more than a specific risk number.
Do not over-decompress.
Decompress design-by-layers solutions, perhaps aggressively so.
Keep normal solutions at less than 0.7 risk.
Avoid risk lower than 0.3.
Avoid risk higher than 0.75.
Avoid project options risker or safer than the risk crossover points.
Project Tracking Guidelines
Adopt binary exit criteria for internal phases of an activity.
Assign consistent phase weights across all activities.
Track progress and effort on a weekly basis.
Never base your progress reports on features.
Always base your progress reports on integration points.
Track the float of near-critical chains.
Service Contract Design Guidelines
Design reusable service contracts.
Comply with service contract design metrics
Avoid contracts with a single operation.
Strive to have 3 to 5 operations per service contract.
Avoid service contracts with more than 12 operations.
Reject service contracts with 20 or more operations.
Avoid property-like operations.
Limit the number of contracts per service to 1 or 2.
Avoid junior hand-offs.
Have only the architect or competent senior developers design the contracts.