Workflow
Last updated
Last updated
Keep all departments aligned to the overall vision of the organization.
Update GitBook documentation and infrastructure where necessary. See this Miro board for reference on goals, hazards, constraints and requirements:
Establish, approve, or update requirements
Gather and understand who you are building for and understand their main needs and expectations.
Discuss with representatives and relevant parties if updates are required. It's important to consider that each function owner or team are autonomous units that can be excluded from the organization at any time.
Identify tradeoffs, and explore various concepts, their feasibility, and their impact on the stakeholder needs.
Keep exploring resources about organizational design and familiarise yourself with new tools.
Decompose larger concepts into smaller components.
Components have inputs, execute a function and outputs.
System architecture captures the relationship between elements:
Assign the functions identified in the functional architecture to the corresponding logical components. This includes both functions related to human operations and those that are purely software or hardware-based.
Remember to maintain the safety of the system by evaluating the safety of its components.
Reliable but unsafe
Components do their job but together an error might occur → the problem is in the system design.
Unreliable but safe
A task or function might be well documented, but an individual might no execute it → specify requirements. Deviating from instructions can also be unreliable but safe, if it secures the overall system
Component categories
Goal condition - have a goal for controllers/operators
Action condition - be able to act on the system (actuators)
Model condition - design a model of the system
Observability condition - be able to obtain the state of the system
Define the objectives/goals of the system, which should be guided by the stakeholder's needs.
Define constraints: safe and acceptable ways to achieve system goals.
Define functional requirements and performance requirements. Create a hierarchy of requirements to understand how they are related.
Don't specify the exact implementation. It depends on the technical constraints, considering the overall system design.
Link widgets/components to requirements and visualize them. Continuously ensure validity - do the requirements make sense? Review, iterate, and refine.
Assume that the system is unsafe. Safety is a system property and errors are an integral part of maintenance.
Hazard = a state the system should never be in.
Understand the larger sociotechnical system it belongs to. It can impose constraints on the system you are designing and reduce risks. Safety is equally a top-down system property, not a component property.
Risks and hazards can be technical, financial, social, and managerial. A top-down review can identify risks, safety concerns, and combinatorial structure of possible accidents.
Pure bottom-up decentralized decision-making can cause a lack of safety in the system.
The accident causality model is not ideal:
condition(s) → event → condition(s) → event → condition(s) → event
Causality is often complex and non-linear. Subjectivity in describing causality creates additional vulnerabilities: Subjectivity in granularity can be influenced by politics, and subjectivity in changing conditions limits the overall understanding of interconnected events.
Root-causes are multi-factorial.
Blame is the enemy of safety.
Identify potential for inadequate control
Control not provided
Unsafe control action provided
Safe control action too early or too late
Control action stopped too soon or applied for too long
Define how could inadequate control occur
Build in protection against degradation
Design constraints, ensure review cycles
When identifying risks and faults, bring the system back to a safe state and no further - “proper paranoia”.
Create a visual map that clearly represents the current state of the system, focusing and zooming in on the relevant parts. Some parts need to be generalized for simplicity, others not shown at all, and others altered slightly to make sure the system design helps others make well-informed decisions.
Create an entity-relationship diagram to visualize how components are connected. You can find more details on how to create an ERD here:
Make sure you specify the goals of the ERD and regularly review whether it represents different fractal dimensions of the same ontology.
Based on the ERD, create a database model for a relational database.
Provide written documentation based on the visual map.
Create models and adapt models over the course of the project.
Find a way to simulate the design. Either through interviews or low-stakes real life scenarios with a similar system design. Ensure integrity and analyze the impact on cost, performance, and risk.
When creating a model, write down how it currently is, not hypothetical ideas. Write out all outputs, i.e. proposal, product, etc. What are the artifacts/types of data we're creating?
There is no perfect design.
Aim to reduce cost, while increasing value output.
Process control and evaluation of change/adaptation over time can help model and predict accidents.
Keep track of stakeholder requirements - they might shift and extend over actual capabilities of the system.
Remember that external information sources impact the control algorithm. New information can improve it but needs to be considered carefully.
Model/simulate process based on control algorithm. Consider time delays, a change in the system may produce effects only much later.
If you are changing two processes simultaneously, one might change faster than another.
Make sure that different controllers don’t have an overlap in process, set clear boundaries to what is being controlled by which controller.
Remember: Organizations need to be closed-loop systems to adapt to the environment.
