Risks

Preamble

Taking a cue from Donald Rumsfeld’s famous quote, risks can stem from known circumstances, identified but unknown circumstances, or unidentified circumstances.

Along that reasoning risk management is to be first and second about time: planning for expected as well as unexpected events, and assessing its bearing on available information.

Source & Time-frames

Time is structured by events and decisions. With regard to systems engineering, both are to affect external (business and technical contexts) and internal (projects) expectations and commitments.

Since there is no reason to assume that these different contexts are governed by a single time-frame, engineering projects will have to arbitrage between risks beaten by different rhythms:

• Business events can be grouped along two frequency waves: short, for market opportunities, and long, for an organization’s continuity.
• System architectures are meant to evolve in synch with organization continuity; unfortunately they also have to adapt to unexpected changes in corporate structures subject or technological environment.
• Component implementations should heed market opportunities and fit system architectures. Within that envelope project management has some latitude to set its own schedules depending on resources and development constraints.

No divine intervention could guarantee that those time-frames would coincide. More to the point, the true purpose of engineering processes is the explicit management of independent time-frames, for business objectives, technological capacities, and development capabilities, each with their own scales, rationale and constraints. The name of the game is risk management, and that can only be achieved if risks are properly identified within their respective contexts and time-frames.

Risks & Development Processes

Those principles can be applied by combining iterative development with architecture driven modelling: iterations are used  as sieves, taking away easy pieces and fencing off hard choices. Easy pieces are no-risk options, which can be developed and modified at will; forced choices are set in stone across layers;  in between are managed risks for which decisions once taken must be implemented as soon as possible lest new circumstances make them obsolete.

As a consequence, development processes should be designed along risks fault lines, i.e work units should never be exposed to different kinds of risks. Assuming transparency and traceability across model layers, projects could then manage objectives, expectations and commitments across business, technology, and engineering perspectives.

It must be stressed that model based engineering processes organized along risks fault lines are not necessarily phased: if developments are set at artifact level (as opposed to model level), they can be carried out iteratively.

Risks Management

Whether fate or fortune, business affairs are driven by external forces and enterprises have to take into account the changing panorama of business opportunities and technological options. At first, the capacity to deal promptly and efficiently with these events will depend respectively on business agility and systems’ versatility and plasticity. If that’s not enough, adjustments will depend on the agility of engineering processes. Risk management is to cover the remaining scenarii.

Since theses scenarii have to reckon with the different perspectives, they will involve a mix of heterogeneous risks set across different time-frames. Three categories of scenarii are to be distinguished depending on the nature of decisions:

• No risk: changes in requirements (business, functional, or non functional) should be supported as they come assuming proper system architecture and software designs.
• No risk taken: business organization and systems technologies are not sure bets but neither are they open to compromise. Hence, the risks are not meant to be priced: once taken, decisions must be scheduled and carried out regardless of what happens.
• Managed risks: even if market developments and their project’s counterpart belong to different time frames, respective objectives and schedules can be priced and weighted by risks. Decisions are therefore meant to arbitrate between costs and benefits.

That understanding put the onus on the dual aspect of risk mentioned above, which is operational information: whenever risks are to be managed, decisions will eventually have to be made at the “last responsible moment”, i.e until not taking side could change the possible options. Applied to project management that means:

• Maximize the time between requirements and commitments, i.e never decide today if it can be done tomorrow.
• Minimize the time between commitment and delivering, i.e don’t think twice once a decision has been taken.

Assuming that decisions are to be taken at the “last responsible moment”, that interval can be used to define the scope of risks:

• Operational risks: decisions can be put to effect immediately. Since external changes can also be taken into account immediately, risks can be confined within production life-cycles.
• Tactical risks: decisions can only be enacted at the start of production cycles using inputs consolidated at completion. Assuming instant analysis and decisions enacting (otherwise some lag will have to be introduced), commitments can be taken from on cycle to the next, and risks curbed accordingly.
• Strategic risks: decisions are meant to be enacted according to predefined plans. The timing of commitments, and the corresponding risk footprint, has to combine planning (when a decision is meant to be taken) and events (when relevant and reliable information is at hand).

Not surprisingly, that classification of risks may coincide with architecture layers: strategic for enterprise assets, tactical for systems functionalities, and operational for platforms and resources.

Risks Management & AI

Taking from a previous post, intelligence is generally understood as the ability to figure out situations and solve problems. With regard to the evolution of the human species, that could have been especially beneficial for risks avoidance and social cooperation. Translated to enterprise, operational decision-making is being thoroughly transformed by advances in artificial intelligence, in particular the combination of big data and deep-learning.

Whereas chance plays its part, the success of an enterprise depends on its ability to anticipate changes in its environment, figure out the impact on its competitive situation, and plan for suitable moves. Like humans, enterprises achieve that purpose through changes in symbolic representation, e.g for the description of risks with regard to:

1. Known circumstances: risks associated to the value of known features of objects, activities or events.
2. Unknown circumstances: risks associated to new features to be associated with known categories of objects, activities or events.
3. Unidentified circumstances: risks associated to new categories of objects, activities or events.

As demonstrated by AlphaGo, applying deep-learning to big data represents a qualitative leap for AI capabilities as it bridges the gap between implicit (i.e latent) and explicit (i.e symbolic) knowledge. Such capability could be decisive for the exploration of risks associated to unknown or unidentified circumstances.

Further Reading

• Regulations & Risks
• EA: Entropy Antidote
• Business Agility & System Entropy
• Models as Parachutes
• Events & Decision Making
• Models Transformation & Agile Development
• AlphaGo: From Intuitive Learning to Holistic Knowledge