diff --git a/dictionary.txt b/dictionary.txt index b5e174bec..ead2f13ab 100644 --- a/dictionary.txt +++ b/dictionary.txt @@ -376,3 +376,8 @@ externalities takedown microsystems skepticism +scrappy +tarnish +goveranance +subpostmasters +exonerate diff --git a/docs/bets/Coding-Bets.md b/docs/bets/Coding-Bets.md index f2078a70a..9b41707e1 100644 --- a/docs/bets/Coding-Bets.md +++ b/docs/bets/Coding-Bets.md @@ -53,7 +53,7 @@ It looks like this: > "Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a 'spike,' which is some work whose purpose is to provide the answer or solution. " - [Spike Solution, _Agile Dictionary_](https://agiledictionary.com/209/spike/) -You might want to use a Spike Solution to test out replacing a badly-fitting technology for a more appropriate one. That is, addressing [Software Dependency](/tags/Software-Dependency-Risk) problems. For example: +You might want to use a Spike Solution to test out replacing a badly-fitting technology for a more appropriate one. That is, addressing [Software Dependency](/risks/On-Software-Dependencies) problems. For example: > "Let's explore using [ElasticSearch](https://en.wikipedia.org/wiki/Elasticsearch) for searching instead of SQL Statements." diff --git a/docs/bets/Purpose-Development-Team.md b/docs/bets/Purpose-Development-Team.md index 579a1161c..3733e2e98 100644 --- a/docs/bets/Purpose-Development-Team.md +++ b/docs/bets/Purpose-Development-Team.md @@ -133,7 +133,7 @@ Let's go back to our original cases: - If I decide to **suspend the current sprint** to fix an outage, then that’s because I’ve decided that the risk of lost business, or the damage to reputation is much greater than the risk of customers walking because we didn’t complete the planned features. - When the Agile Manifesto stresses **Individuals and Interactions over Processes and Tools**, it’s because it believes focusing on processes and tools leads to much greater risk. This is based on the experience that while focusing on individuals and interactions may appear to be a less efficient way to build software, following strict formal processes massively increases the much worse risk of [building the wrong product](/tags/Feature-Fit-Risk). -- When we argue for **fixing technical debt against shipping a new feature**, what we are really doing is expressing differences in our models of the [balance of risk](/tags/Balance-Of-Risk) from taking these actions. My boss and I might both be trying to minimise the risk of customers defecting to another product but he might believe this is best achieved by [adding new features](/tags/Feature-Risk) in the short term, whilst I might believe that [clearing technical debt](/risks/Complexity-Risk#technical-debt) allows us to get features delivered faster in the long term. +- When we argue for **fixing technical debt against shipping a new feature**, what we are really doing is expressing differences in our models of the [balance of risk](/tags/Balance-Of-Risk) from taking these actions. My boss and I might both be trying to minimise the risk of customers defecting to another product but he might believe this is best achieved by [adding new features](/tags/Feature-Fit-Risk) in the short term, whilst I might believe that [clearing technical debt](/risks/Complexity-Risk#technical-debt) allows us to get features delivered faster in the long term. - In the example of **Sustainably vs Quickly**, it's clear that what we should be doing is trying to avoid altering the balance of risks in a way that sacrifices too much Sustainability or Speed. To do this requires judgement in the form of an accurate [Internal Model](/tags/Internal-Model) of the [balance of risks](/tags/Balance-Of-Risk). ### Other Scenarios @@ -141,7 +141,7 @@ Let's go back to our original cases: In a way, this is not just about development teams. Any time a person is added to an organisation, the hope is that it will improve the [balance of risk](/tags/Balance-Of-Risk) for that organisation. The development team are experts in improving the balance of [technical risks](/risks/Risk-Landscape) but other teams have other specialities: - The Finance team are there to avoid the risk of [running out of money](/tags/Funding-Risk) and ensuring that the bills get paid (avoiding [Legal Risks](/tags/Operational-Risk)). - - The Human Resources team are there to make sure staff are hired, managed and leave properly. Doing this avoids [inefficiency](/tags/Schedule-Risk), [Reputation Damage](/tags/Trust-And-Belief-Risk), [Morale Issues](/risks/Agency-Risk#morale-failure) and [Legal Risks](/tags/Operational-Risk). + - The Human Resources team are there to make sure staff are hired, managed and leave properly. Doing this avoids [inefficiency](/tags/Schedule-Risk), [Reputation Damage](/tags/Reputational-Risk), [Morale Issues](/risks/Agency-Risk#morale-failure) and [Legal Risks](/tags/Operational-Risk). - The best doctors have accurate [Internal Models](/tags/Internal-Model). They can best diagnose the illnesses and figure out treatments that improve the patient's [balance of risk](/tags/Balance-Of-Risk). Medical Students are all taught to 'first, do no harm': > "given an existing problem, it may be better not to do something, or even to do nothing, than to risk causing more harm than good." - [Primum non nocere, _Wikipedia_](https://en.wikipedia.org/wiki/Primum_non_nocere). diff --git a/docs/estimating/Analogies.md b/docs/estimating/Analogies.md index 4f09af40f..a522f0859 100644 --- a/docs/estimating/Analogies.md +++ b/docs/estimating/Analogies.md @@ -44,7 +44,7 @@ As we discussed in [Journeys](Journeys), there are plenty of problems in getting ![Journeys Meets Cabinets](/img/estimates/dimensions-2.png) -What happens when you relax those constraints? If there is _no map_ and the _closeness_ heuristic isn't available, you're in a maze. You can't tell how "done" you are in a maze by judging your distance to the exit point - you may be heading to a [Dead End](/tags/Dead-End-Risk) anyway! +What happens when you relax those constraints? If there is _no map_ and the _closeness_ heuristic isn't available, you're in a maze. You can't tell how "done" you are in a maze by judging your distance to the exit point - you may be heading to a [Dead End](/risks/Complexity-Risk/Complexity-Analogies#avolding-dead-ends) anyway! ![Maze Estimating](/img/estimates/mazes.png) diff --git a/docs/estimating/Kitchen-Cabinet.md b/docs/estimating/Kitchen-Cabinet.md index d33137a38..7e37bffa6 100644 --- a/docs/estimating/Kitchen-Cabinet.md +++ b/docs/estimating/Kitchen-Cabinet.md @@ -144,9 +144,9 @@ This means that clients often keep projects running for far longer than they sho There is an alternative to too-early or too-late risk. You can always choose to be _on time_. This is definitely a choice: Just like a student can always hand _something_ in on assignment day (even if it's just a title scrawled on a piece of paper), you can always hand in whatever work you have. -Then, instead of worrying about [Deadline Risk](/risks/(/tags/Deadline-Risk), you are letting [Feature Fit Risk](/tags/Feature-Risk) vary to take up the slack. +Then, instead of worrying about [Deadline Risk](/risks/(/tags/Deadline-Risk), you are letting [Feature Fit Risk](/tags/Feature-Fit-Risk) vary to take up the slack. -So far, we've seen two kinds of estimate: [Fill-The-Bucket](Fill-The-Bucket) and [Kitchen-Cabinet](Kitchen-Cabinet). Now, it's time to review a third - estimating [Journey Style](Journeys), and looking at how we can minimise [Feature Fit Risk](/tags/Feature-Risk) within an available budget. +So far, we've seen two kinds of estimate: [Fill-The-Bucket](Fill-The-Bucket) and [Kitchen-Cabinet](Kitchen-Cabinet). Now, it's time to review a third - estimating [Journey Style](Journeys), and looking at how we can minimise [Feature Fit Risk](/tags/Feature-Fit-Risk) within an available budget. \ No newline at end of file diff --git a/docs/estimating/On-Story-Points.md b/docs/estimating/On-Story-Points.md index 8c5cf4979..4e48d565e 100644 --- a/docs/estimating/On-Story-Points.md +++ b/docs/estimating/On-Story-Points.md @@ -63,7 +63,7 @@ After some back-and-forth, the team agrees on a number. But what does this numb - **Complexity**: An alternate view is that [a story point is about _complexity_](https://www.clearvision-cm.com/blog/why-Story Points-are-a-measure-of-complexity-not-effort/). This means a Sprint is all about budgeting complexity, rather than effort. This makes some sense but given that the sprint is measured in person-days, and the scrum leader is going to produce a report showing how many story points were completed in a sprint, it's clear that complexity really is just a weak proxy for person-days anyway. In fact, there are lots of tasks that might be low-complexity, but take a lot of time anyway, such as designing 500 icons. This will clearly take a lot of time, but be low-complexity, so you better give it enough story points to represent the time you'll spend on it. -- **Relative Sizing**: A third way of looking at it is that really, story points are just about _relative_ sizing: it doesn't matter what they refer to or how big they are, it's all about trying to budget the right amount of work into the sprint. For example, you can either have two one-point stories, or a two-point story, and the effect on the sprint is the same. Because there is no fixed definition of the size of a story point, you do run the risk of story-point "inflation" or "deflation". But unless you are trying to use them to plot team productivity over time, this shouldn't really matter so much. And we'd never make the mistake of doing that, [right](/tags/Map-And-Territory-Risk)? +- **Relative Sizing**: A third way of looking at it is that really, story points are just about _relative_ sizing: it doesn't matter what they refer to or how big they are, it's all about trying to budget the right amount of work into the sprint. For example, you can either have two one-point stories, or a two-point story, and the effect on the sprint is the same. Because there is no fixed definition of the size of a story point, you do run the risk of story-point "inflation" or "deflation". But unless you are trying to use them to plot team productivity over time, this shouldn't really matter so much. And we'd never make the mistake of doing that, [right](/risks/Internal-Model-Risk/Metrics)? ## Observations diff --git a/docs/estimating/Risk-First-Analysis.md b/docs/estimating/Risk-First-Analysis.md index 23fa8301a..45eafbb4d 100644 --- a/docs/estimating/Risk-First-Analysis.md +++ b/docs/estimating/Risk-First-Analysis.md @@ -95,7 +95,7 @@ On a Risk-First diagram, tasks - or actions as we call them - are shown in "sign By fixing the rendering bug, we are trying to deal the problem that the software _demos badly_ and the resulting risk that the potential customers don't trust the quality of our product. Risk-First diagrams show chronology from left-to-right. That is, on the left of the action is the world as it is now, whereas on the right is the world as it will be _after_ taking some action. To show that our action will eliminate some existing risk, we can strike it out by drawing a line through it. -So, this diagram encapsulates the reason why we might fix the rendering bug: it's about addressing potential [Trust Risk](/tags/Trust-And-Belief-Risk) in our product. +So, this diagram encapsulates the reason why we might fix the rendering bug: it's about addressing potential [Reputational Risk](/tags/Reputational-Risk) in our product. ## Question 2: What Do We Gain? diff --git a/docs/overview/Quick-Summary.md b/docs/overview/Quick-Summary.md index f3fcdaf5f..3bf18c387 100644 --- a/docs/overview/Quick-Summary.md +++ b/docs/overview/Quick-Summary.md @@ -63,7 +63,7 @@ If we accept the assertion that _all_ the actions we take on a project are about For example: - - If we do a [Code Review](/tags/Review), we are partly trying to minimise the risks of bugs slipping through into production and also manage the [Key Person Risk](/tags/Staff-Risk) of knowledge not being widely-enough shared. + - If we do a [Code Review](/tags/Review), we are partly trying to minimise the risks of bugs slipping through into production and also manage the key person risk of knowledge not being widely-enough shared. - If we write [Unit Tests](/tags/Automated-Testing), we’re addressing the risk of bugs going to production. We’re also mitigating against the risk of _regression_ and future changes breaking our existing functionality. - If we enter into a contract with a supplier then we are mitigating the risk of the supplier vanishing and leaving us exposed. With the contract in place we have legal recourse against this risk. diff --git a/docs/practices/Development-And-Coding/Tool-Adoption.md b/docs/practices/Development-And-Coding/Tool-Adoption.md index 2a141b399..e85730cba 100644 --- a/docs/practices/Development-And-Coding/Tool-Adoption.md +++ b/docs/practices/Development-And-Coding/Tool-Adoption.md @@ -62,7 +62,7 @@ But, this is a low bar - some tools offer _amazing_ returns on investment: A _really good tool_ offers such advantages that not using it becomes _unthinkable_: Linux is heading towards this point. For Java developers, the JVM is there already. -Picking new tools and libraries should be done **very carefully**: you may be stuck with your choices for some time. Here is a [short guide that might help](/tags/Dependency-Risk). +Picking new tools and libraries should be done **very carefully**: you may be stuck with your choices for some time. Here is a [short guide that might help](/risks/On-Software-Dependencies). ## See Also diff --git a/docs/risks/Communication-Risks/On-Channels.md b/docs/risks/Communication-Risks/On-Channels.md index cfc0a8966..741654dbf 100644 --- a/docs/risks/Communication-Risks/On-Channels.md +++ b/docs/risks/Communication-Risks/On-Channels.md @@ -24,7 +24,7 @@ Shannon discusses that no channel is perfect: there is always the **risk of noi There are practical implications to this: messages might be delayed or delivered in the wrong order, or not be acknowledged when they do arrive. Sometimes, a channel is just an inappropriate way of communicating. When you work in a different time-zone to someone else on your team, there is _automatic_ [Communication Risk](/tags/Communication-Risk), because instantaneous communication is only available for a few hours a day. -When channels are **poor-quality**, less communication occurs. People will try to communicate just the most important information. But, it's often impossible to know a-priori what constitutes "important". This is why [Extreme Programming](https://en.wikipedia.org/wiki/Extreme_programming) recommends the practices of [Pair Programming](https://en.wikipedia.org/wiki/Pair_programming) and grouping all the developers together: although you don't know whether useful communication will happen, you are mitigating [Channel Risk](/tags/Channel-Risk) by ensuring high-quality communication channels are in place. +When channels are **poor-quality**, less communication occurs. People will try to communicate just the most important information. But, it's often impossible to know a-priori what constitutes "important". This is why [Extreme Programming](https://en.wikipedia.org/wiki/Extreme_programming) recommends the practices of [Pair Programming](https://en.wikipedia.org/wiki/Pair_programming) and grouping all the developers together: although you don't know whether useful communication will happen, you are mitigating [Communication Risk](/tags/Communication-Risk) by ensuring high-quality communication channels are in place. At other times channels are crowded and can contain so much information that we can't hope to receive all the messages. In these cases we don't even observe the whole channel, just parts of it. @@ -43,4 +43,4 @@ This works both ways. Let's looks at some of the **Communication Risks** from t ![Marketing Communication](/img/generated/risks/communication/communication_marketing.svg) -[Internal Models](/tags/Internal-Model) don't magically get populated with the information they need: they fill up gradually, as shown in the diagram above. Popular products and ideas _spread_, by word-of-mouth or other means. Part of the job of being a good technologist is to keep track of new **Ideas**, **Concepts** and **Options**, so as to use them as [Dependencies](/tags/Dependency-Risk) when needed. +[Internal Models](/tags/Internal-Model) don't magically get populated with the information they need: they fill up gradually, as shown in the diagram above. Popular products and ideas _spread_, by word-of-mouth or other means. Part of the job of being a good technologist is to keep track of new **Ideas**, **Concepts** and **Options**, so as to use them as [Dependencies](/tags/Dependency-Risks) when needed. diff --git a/docs/risks/Communication-Risks/On-Protocols.md b/docs/risks/Communication-Risks/On-Protocols.md index ad0af16fe..c3a59dc56 100644 --- a/docs/risks/Communication-Risks/On-Protocols.md +++ b/docs/risks/Communication-Risks/On-Protocols.md @@ -198,6 +198,6 @@ Do human languages support forward compatibility? To some extent! New words ar ### 5. Protocol Implementation -A further [Communication Risk](/tags/Communuication-Risk) threat exists in heterogeneous computing environments where protocols have been independently implemented based on standards. For example, there are now so many different browsers, all supporting variations of `HTTP`, `HTML` and `JavaScript` that it becomes impossible to test a website comprehensively over all the different permutations. +A further [Communication Risk](/tags/Communication-Risk) threat exists in heterogeneous computing environments where protocols have been independently implemented based on standards. For example, there are now so many different browsers, all supporting variations of `HTTP`, `HTML` and `JavaScript` that it becomes impossible to test a website comprehensively over all the different permutations. To mitigate as much risk as possible, generally we test web sites in a subset of browsers, and use a lowest-common-denominator approach to choosing protocol and language features. diff --git a/docs/risks/Complexity-Risk/Complexity-Analogies.md b/docs/risks/Complexity-Risk/Complexity-Analogies.md index 9bb91244e..9051c4ca0 100644 --- a/docs/risks/Complexity-Risk/Complexity-Analogies.md +++ b/docs/risks/Complexity-Risk/Complexity-Analogies.md @@ -53,7 +53,7 @@ It's not long before someone comes down with food poisoning. ![Complexity Risk and its implications](/img/generated/risks/complexity/complexity-risk-impact.svg) -We wouldn't tolerate this behaviour in a restaurant kitchen, so why put up with it in a software project? This state-of-affairs is illustrated in the above diagram. Not only does [Complexity Risk](/tags/Complexity-Risk) slow down future development, it can be a cause of [Operational Risks](/tags/Operational-Risk) and [Security Risks](Agency-Risk#security). +We wouldn't tolerate this behaviour in a restaurant kitchen, so why put up with it in a software project? This state-of-affairs is illustrated in the above diagram. Not only does [Complexity Risk](/tags/Complexity-Risk) slow down future development, it can be a cause of [Operational Risks](/tags/Operational-Risk) and [Security Risks](/tags/Security-Risk). ## Feature Creep @@ -72,7 +72,7 @@ Therefore, [Feature Creep](https://en.wikipedia.org/wiki/Feature_creep) (or [Gol Sometimes, feature-creep happens because either managers feel they need to keep their staff busy, or the staff decide on their own that they need to [keep themselves busy](/tags/Agency-Risk). This is something we'll return to in [Agency Risk](/tags/Agency-Risk). -## Complexity Dead-Ends: An Example +## Complexity -Ends: An Example Imagine a complex software system composed of many sub-systems. Let's say that the Accounting sub-system needed password protection (so you built this). Then the team realised that you needed a way to _change the password_ (so you built that). Then, you needed to have more than one user of the Accounting system so they would all need passwords (OK, fine). @@ -94,4 +94,4 @@ Working in a complex environment makes it harder to see developmental dead-ends. Sometimes, the path across the [Risk Landscape](/risks/Risk-Landscape) will take you to dead ends, and the only benefit to be gained is experience. No one deliberately chooses a dead end - often you can take an action that doesn't pay off, but frequently the dead end appears from nowhere: it's a [Hidden Risk](/tags/Hidden-Risk). The source of a lot of this hidden risk is the complexity of the [risk landscape](/tags/Risk-Landscape). -[Version Control Systems](https://en.wikipedia.org/wiki/Version_control) like [Git](https://en.wikipedia.org/wiki/Git) are a useful mitigation of [Dead-End Risk](/tags/Dead-End-Risk), because using them means that at least you can _go back_ to the point where you made the bad decision and go a different way. Additionally, they provide you with backups against the often inadvertent [Dead-End Risk](/tags/Dead-End-Risk) of someone wiping the hard-disk. +[Version Control Systems](https://en.wikipedia.org/wiki/Version_control) like [Git](https://en.wikipedia.org/wiki/Git) are a useful mitigation of dead ends, because using them means that at least you can _go back_ to the point where you made the bad decision and go a different way. Additionally, they provide you with mitigations against the [Reliability Risk](/tags/Reliability-Risk) of using hard-disk. diff --git a/docs/risks/Complexity-Risk/Complexity-Risk.md b/docs/risks/Complexity-Risk/Complexity-Risk.md index c47fffc86..875f951b7 100644 --- a/docs/risks/Complexity-Risk/Complexity-Risk.md +++ b/docs/risks/Complexity-Risk/Complexity-Risk.md @@ -11,7 +11,6 @@ tags: - Risks - Refactoring - Complexity Risk - - Dead End Risk - Abstraction definitions: - name: Abstraction @@ -34,7 +33,7 @@ It's the early 2000s: your Pokémon website is becoming really popular and profi ![Increasing the Cost To Reduce Operational Risks](/img/generated/risks/posters/complexity-risk2.svg) -It's the early 2020s: your Pokémon website is becoming really popular and profitable but you're worried that you're carrying too much [Operational Risk](tags/Operational-Risk). You're able to turn on some backup features, load balancing and increase the instances via the console provided by your Cloud Service Provider, handing off the [Complexity Risk](/tags/Complexity-Risk) to them at some expense. As well as helping with [Demand Management](/tags/Demand-Management), CSPs have allowed software developers to shift a lot of [Complexity Risk](/tags/Complexity-Risk) to them, the downsides being [cost](/tags/Funding-Risk) and [lock-in](/tags/Lock-In-Risk). +It's the early 2020s: your Pokémon website is becoming really popular and profitable but you're worried that you're carrying too much [Operational Risk](/tags/Operational-Risk). You're able to turn on some backup features, load balancing and increase the instances via the console provided by your Cloud Service Provider, handing off the [Complexity Risk](/tags/Complexity-Risk) to them at some expense. As well as helping with [Demand Management](/tags/Demand-Management), CSPs have allowed software developers to shift a lot of [Complexity Risk](/tags/Complexity-Risk) to them, the downsides being [cost](/tags/Funding-Risk) and [lock-in](/tags/Lock-In-Risk). ## Example Threats @@ -76,7 +75,7 @@ An important lesson here is that choice of language can reduce complexity: and w ### 5. Networking / Security -There are plenty of [Complexity Risk](/tags/Complexity-Risk) perils in _anything_ to do with networked code, chief amongst them being error handling and (again) [protocol evolution](/tags/Protocol-Risk). +There are plenty of [Complexity Risk](/tags/Complexity-Risk) perils in _anything_ to do with networked code, chief amongst them being error handling and (again) [protocol evolution](/risks/On-Protocols). **Threat**: In the case of security considerations, exploits _thrive_ on the complexity of your code, and the weaknesses that occur because of it. In particular, Schneier's Law says, never implement your own cryptographic scheme: diff --git a/docs/risks/Complexity-Risk/Kolmogorov-Complexity.md b/docs/risks/Complexity-Risk/Kolmogorov-Complexity.md index 24dc16b38..248ae0ecc 100644 --- a/docs/risks/Complexity-Risk/Kolmogorov-Complexity.md +++ b/docs/risks/Complexity-Risk/Kolmogorov-Complexity.md @@ -58,7 +58,7 @@ What's happening here is that we're _exploiting a pattern_: we noticed that `abc By applying abstraction, we can improve in the direction of the Kolmogorov lower bound. By allowing ourselves to say that _symbols_ (like `out` and `ABCD`) are worth one complexity point, we've allowed that we can be descriptive in naming `function` and `const`. Naming things is an important part of abstraction, because to use something, you have to be able to refer to it. -Generally, the more complex a piece of software is, the more difficulty users will have [understanding it](/tags/Conceptual-Integrity-Risk), and the more work developers will have changing it. +Generally, the more complex a piece of software is, the more difficulty users will have [understanding it](/tags/Internal-Model-Risk), and the more work developers will have changing it. Although we should prefer the third version of our code over either the first or second (because of its brevity) we could go further down into [Code Golf](https://en.wikipedia.org/wiki/Code_golf) territory. The following javascript program plays [FizzBuzz](https://en.wikipedia.org/wiki/Fizz_buzz) up to 100, but is less readable than you might hope. @@ -92,4 +92,4 @@ In the third version of the program, we used the method `.repeat()`, which allow ![Using Libraries and Languages to reduce Complexity Risk](/img/generated/risks/complexity/libraries.svg) -So as the above diagram shows, we can also reduce [Complexity Risk](/tags/Complexity-Risk) via [languages and libraries](/tags/Dependency-Adoption). This doesn't come without a cost, though. We are trading-off our own [Codebase Risk](/tags/Codebase-Risk) but increasing [Dependency Risk](/tags/Dependency-Risk) and [Lock-In Risk](/tags/Lock-In-Risk) instead. +So as the above diagram shows, we can also reduce [Complexity Risk](/tags/Complexity-Risk) via [languages and libraries](/tags/Dependency-Adoption). This doesn't come without a cost, though. We are trading-off our own code's [Complexity Risk](/tags/Complexity-Risk) but adding [Dependency Risks](/tags/Dependency-Risks) instead. diff --git a/docs/risks/Coordination-Risk/A-Model-Of-Coordination-Risk.md b/docs/risks/Coordination-Risk/A-Model-Of-Coordination-Risk.md index 201d74494..a954df238 100644 --- a/docs/risks/Coordination-Risk/A-Model-Of-Coordination-Risk.md +++ b/docs/risks/Coordination-Risk/A-Model-Of-Coordination-Risk.md @@ -1,6 +1,8 @@ --- title: A Model Of Coordination Risk sidebar_position: 1 +slug: /risks/A-Model-Of-Coordination-Risk + tags: - Coordination Risk --- @@ -22,13 +24,13 @@ As you can see, by _sharing_, it's possible that the _total benefit_ is greater Just two things are needed for competition to occur: - Multiple, Individual agents, trying to achieve [Goals](/tags/Goal). - - Scarce Resources, which the agents want to use as [Dependencies](/tags/Dependency-Risk). + - Scarce Resources, which the agents want to use as [Dependencies](/tags/Dependency-Risks). ### Coordination via Communication The only way that the agents can move away from competition towards coordination is via [Communication](/tags/Communication-Risk), and this is where their coordination problems begin. -[Coordination Risk](/tags/Coordination-Risk) commonly occurs where people have different ideas about how to achieve a [goal](/tags/Goal), and they have different ideas because they have different [Internal Models](/tags/Internal-Model). As we saw in the section on [Communication Risk](/tags/Communication-Risk), we can only hope to synchronise [Internal Models](/tags/Internal-Model) if there are high-bandwidth [Channels](/tags/Channel-Risk) available for communication. +[Coordination Risk](/tags/Coordination-Risk) commonly occurs where people have different ideas about how to achieve a [goal](/tags/Goal), and they have different ideas because they have different [Internal Models](/tags/Internal-Model). As we saw in the section on [Communication Risk](/tags/Communication-Risk), we can only hope to synchronise [Internal Models](/tags/Internal-Model) if there are high-bandwidth [Channels](/risks/On-Channels) available for communication. You might think, therefore, that this is just another type of [Communication Risk](/tags/Communication-Risk) problem, and that's often a part of it, but even with synchronized [Internal Models](/tags/Internal-Model), coordination risk can occur. Imagine the example of people all trying to madly leave a burning building. They all have the same information (the building is on fire). If they coordinate, and leave in an orderly fashion, they might all get out. If they don't, and there's a scramble for the door, more people might die. diff --git a/docs/risks/Coordination-Risk/CAP-Theorem.md b/docs/risks/Coordination-Risk/CAP-Theorem.md index 78b2362a5..0567d4e1a 100644 --- a/docs/risks/Coordination-Risk/CAP-Theorem.md +++ b/docs/risks/Coordination-Risk/CAP-Theorem.md @@ -1,6 +1,7 @@ --- title: CAP Theorem sidebar_position: 3 +slug: /risks/CAP-Theorem tags: - Coordination Risk --- diff --git a/docs/risks/Coordination-Risk/Coordination-Risk.md b/docs/risks/Coordination-Risk/Coordination-Risk.md index 3b7a643f1..62aa750fe 100644 --- a/docs/risks/Coordination-Risk/Coordination-Risk.md +++ b/docs/risks/Coordination-Risk/Coordination-Risk.md @@ -2,6 +2,7 @@ title: Coordination Risk description: Risks due to the fact that systems contain multiple agents, which need to work together. +slug: /risks/Coordination-Risk featured: class: c @@ -36,7 +37,7 @@ On an open source software project, the maintainers are often required to make a ![Coordination Risk after introducing voting](/img/generated/risks/posters/coordination-risk1.svg) -As shown in the above diagram, they tried to remedy this by instituting [a governance process](/tags/Approval) wherein the maintainers voted on key architectural issues together. However, the debates took up a lot of time and often ended in further argument and misunderstanding. +As shown in the above diagram, they tried to remedy this by instituting [a governance process](/tags/Approvals) wherein the maintainers voted on key architectural issues together. However, the debates took up a lot of time and often ended in further argument and misunderstanding. One alternative suggested to them was to decide on a "[Benevolent Dictator for Life (BDFL)](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life)". This was a title originally conferred on Guido van Rossum, creator of the Python Language, but other famous examples exist such as Rich Hickey (Clojure Language) and Linus Torvalds (the Linux Kernel). diff --git a/docs/risks/Coordination-Risk/Decision-Making.md b/docs/risks/Coordination-Risk/Decision-Making.md index 5bb59641b..e62d3bc7c 100644 --- a/docs/risks/Coordination-Risk/Decision-Making.md +++ b/docs/risks/Coordination-Risk/Decision-Making.md @@ -1,6 +1,8 @@ --- title: Decision Making sidebar_position: 2 +slug: /risks/Decision-Making + tags: - Coordination Risk --- @@ -68,7 +70,7 @@ Clearly, this is just a _model_, it's not set in stone and decision making style ## Staff As Agents -Staff in a team have a dual nature: they are **Agents** and **Resources** at the same time. The team [depends](/tags/Dependency-Risk) on staff for their resource of _labour_, but they're also part of the decision making process of the team, because they have [_agency_](/tags/Agency-Risk) over their own actions. +Staff in a team have a dual nature: they are **Agents** and **Resources** at the same time. The team [depends](/tags/Dependency-Risks) on staff for their resource of _labour_, but they're also part of the decision making process of the team, because they have [_agency_](/tags/Agency-Risk) over their own actions. Part of [Coordination Risk](/tags/Coordination-Risk) is about trying to mitigate differences in [Internal Models](/tags/Internal-Model). So it's worth considering how varied people's models can be: @@ -86,7 +88,7 @@ Specifically this describes a process whereby a new group will form and then be Since [Coordination](/tags/Coordination-Risk) is about [Resource Allocation](Coordination-Risk#problems-of-coordination) the skills of staff can potentially be looked at as resources to allocate. This means handling [Coordination Risk](/tags/Coordination-Risk) issues like: - - People leaving, taking their [Internal Models](/tags/Internal-Model) and expertise with them ([Key Person Risk](/tags/Staff-Risk)). + - People leaving, taking their [Internal Models](/tags/Internal-Model) and expertise with them ([Key Person Risk](/tags/Reliability-Risk)). - People requiring external training, to understand new tools and techniques ([Internal Model](/tags/Internal-Model-Risk)). - People being protective about their knowledge in order to protect their jobs ([Agency Risk](/tags/Agency-Risk)). diff --git a/docs/risks/Dependency-Risks/Agency-Risk/Human-Agency-Risk.md b/docs/risks/Dependency-Risks/Agency-Risk/Human-Agency-Risk.md index 32fbe386d..6e06228dd 100644 --- a/docs/risks/Dependency-Risks/Agency-Risk/Human-Agency-Risk.md +++ b/docs/risks/Dependency-Risks/Agency-Risk/Human-Agency-Risk.md @@ -3,6 +3,7 @@ title: Agency Risk in People sidebar_position: 2 tags: - Agency Risk +slug: /risks/Human-Agency-Risk --- ![Goal Hierarchy](/img/generated/risks/agency/hierarchy.svg) @@ -85,7 +86,7 @@ Sometimes the morale of the team or individuals within it dips, leading to lack [Agency Risk](/tags/Agency-Risk) applies to _whole teams_ too. It's perfectly possible that a team within an organisation develops [Goals](/tags/Goal) that don't align with those of the overall organisation. For example: - - A team introduces excessive [Bureaucracy](Process-Risk#bureaucracy) in order to avoid work it doesn't like. + - A team introduces excessive [Bureaucracy](/risks/Process-Risk#bureaucracy) in order to avoid work it doesn't like. - A team gets obsessed with a particular technology, or their own internal process improvement, at the expense of delivering business value. - A marginalised team forces their services on other teams in the name of "consistency". (This can happen a lot with "Architecture", "Branding" and "Testing" teams, sometimes for the better, sometimes for the worse.) diff --git a/docs/risks/Dependency-Risks/Agency-Risk/Reducing-Agency-Risk.md b/docs/risks/Dependency-Risks/Agency-Risk/Reducing-Agency-Risk.md index 1d1333759..fbb0d0c77 100644 --- a/docs/risks/Dependency-Risks/Agency-Risk/Reducing-Agency-Risk.md +++ b/docs/risks/Dependency-Risks/Agency-Risk/Reducing-Agency-Risk.md @@ -3,6 +3,7 @@ title: Reducing Agency Risk sidebar_position: 2 tags: - Agency Risk +slug: /risks/Reducing-Agency-Risk --- As noted in the [main article](/risks/Agency-Risk), there are various ways to reduce [Agency Risk](/tags/Agency-Risk), such as [Monitoring](/tags/Review), [Security Hardening](/tags/Security-Testing), [Contracts](/tags/Contracts) and so on., However here are a couple of other approaches to consider to reduce Agency Risk. diff --git a/docs/risks/Dependency-Risks/Dependency-Risks.md b/docs/risks/Dependency-Risks/Dependency-Risks.md index 0d34704ea..7838282ed 100644 --- a/docs/risks/Dependency-Risks/Dependency-Risks.md +++ b/docs/risks/Dependency-Risks/Dependency-Risks.md @@ -15,7 +15,7 @@ part_of: Operational Risk # Dependency Risks -[Dependency Risks](/tags/Dependency-Risk) are risks you take on whenever you have a dependency on something (or someone) else. +[Dependency Risks](/tags/Dependency-Risks) are risks you take on whenever you have a dependency on something (or someone) else. One simple example could be that the software service you write might depend on hardware to run on: if the server goes down, the service goes down too. In turn, the server depends on electricity from a supplier, as well as a network connection from a provider. If either of these dependencies aren't met, the service is out of commission. @@ -29,7 +29,7 @@ This isn't even lucky though: life has adapted to build dependencies on things t Although life exists at the bottom of the ocean around [hydrothermal vents](https://en.wikipedia.org/wiki/Hydrothermal_vent), it is a very different kind of life to ours and has a different set of dependencies given its circumstances. -This tells us a lot about [Dependency Risk](/tags/Dependency-Risk) right here: +This tells us a lot about [Dependency Risk](/tags/Dependency-Risks) right here: - On the one hand, _depending on something_ is very often helpful, and quite often essential. (For example, all life seem to depend on water). - Successful organisms _adapt_ to the dependencies available to them (like the thermal vent creatures). diff --git a/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md b/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md index a3b5770d2..250d7a376 100644 --- a/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md +++ b/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md @@ -30,7 +30,7 @@ This grants you some leeway as now you have two variables to play with: the _siz In startup circles, this "amount of time you can afford it" is called the ["Runway"](https://en.wiktionary.org/wiki/runway): you have to get the product to "take-off" (become profitable) before the runway ends. -In the above diagram, your startup is constrained in this way and wants to maximise its available runway. Startups often spend a lot of time courting investors in order to get funding and mitigate this type of [Funding Risk](/tags/Funding-Risk). The problem with this is that when the founders' focus changes to raising funds, they can no longer be focused on _building the right product_ (i.e. [Feature Fit Risk](tags/Feature-Fit-Risk)) building it quickly ([Schedule Risk](/tags/Schedule-Risk)) and doing so before the market for the product changes ([Market Risk](/tags/Market-Risk)). +In the above diagram, your startup is constrained in this way and wants to maximise its available runway. Startups often spend a lot of time courting investors in order to get funding and mitigate this type of [Funding Risk](/tags/Funding-Risk). The problem with this is that when the founders' focus changes to raising funds, they can no longer be focused on _building the right product_ (i.e. [Feature Fit Risk](/tags/Feature-Fit-Risk)) building it quickly ([Schedule Risk](/tags/Schedule-Risk)) and doing so before the market for the product changes ([Market Risk](/tags/Market-Risk)). ## Example Threats @@ -46,7 +46,7 @@ In the above diagram, your startup is constrained in this way and wants to maxim **Threat**: The market changes in some way (perhaps interest rates, a stock crash, exchange rates) which affect the source of funding. -**See** [Market Risk](tags/Market-Risk) +**See** [Market Risk](/tags/Market-Risk) ### 3. Threats From Demand diff --git a/docs/risks/Dependency-Risks/Lock-In-Risk/Cycles.md b/docs/risks/Dependency-Risks/Lock-In-Risk/Cycles.md new file mode 100644 index 000000000..99a501521 --- /dev/null +++ b/docs/risks/Dependency-Risks/Lock-In-Risk/Cycles.md @@ -0,0 +1,22 @@ +--- +title: How Lock-In Risk Evolves in A Cycle +description: Some examples of lock-in risk + +sidebar_position: 4 +tags: + - Lock-In Risk +slug: /risks/Lock-In-Cycles +--- + +![Lock-In Risk Decreases With Bridges and Standards](/img/generated/risks/boundary/cycle.svg) + +[Lock-In Risk](/tags/Lock-In-Risk) seems to progress in cycles. As a piece of technology becomes more mature, there are more standards and bridges, and [Lock-In Risk](/tags/Lock-In-Risk) is lower. Once [Lock-In Risk](/tags/Lock-In-Risk) is low and a particular approach is proven a technology becomes a commodity. After that, there will be innovation upon this, giving rise to new opportunities for [Lock-In Risk](/tags/Lock-In-Risk) (see the diagram above). Here are some examples: + + - **Processor Chips.** By providing features (instructions) on their processors that other vendors didn't have, manufacturers made their processors more attractive to system integrators. However, since the instructions were different on different chips, this created [Lock-In Risk](/tags/Lock-In-Risk) for the integrators. Intel and Microsoft were able to use this fact to build a big ecosystem around Windows running on Intel chips (so called, WinTel). The Intel instruction set is nowadays a _de-facto_ standard for PCs. + + - **Browsers.** In the late 1990s, faced with the emergence of the nascent World Wide Web, and the [Netscape Navigator](https://en.wikipedia.org/wiki/Netscape_Navigator) browser, [Microsoft](https://en.wikipedia.org/wiki/Microsoft) adopted a strategy known as [Embrace and Extend](https://en.wikipedia.org/wiki/Embrace_and_extend). The idea of this was to subvert the HTML standard to their own ends by _embracing_ the standard and creating their own browser Internet Explorer and then _extending_ it with as much functionality as possible, which would then _not work_ in Netscape Navigator. They then embarked on a campaign to try and get everyone to "upgrade" to Internet Explorer. In this way, they hoped to "own" the Internet, or at least, the software of the browser, which they saw as analogous to being the "operating system" of the Internet, and therefore a threat to their own operating system, [Windows](https://en.wikipedia.org/wiki/Microsoft_Windows). + + - **Mobile Operating Systems.** We currently have just two main _mobile_ ecosystems (although there used to be many more): [Apple's iOS](https://en.wikipedia.org/wiki/IOS) and [Google's Android](https://en.wikipedia.org/wiki/Android_(operating_system)), which are both _very_ different and complex ecosystems with large, complex boundaries. They are both innovating as fast as possible to keep users happy with their features. Tools like [Xamarin](https://en.wikipedia.org/wiki/Xamarin) exist which allow you to build applications sharing code over both platforms. + + - **Cloud Computing.** [Amazon Web Services (AWS)](https://en.wikipedia.org/wiki/Amazon_Web_Services) are competing with [Microsoft Azure](https://en.wikipedia.org/wiki/Microsoft_Azure) and [Google Cloud Platform](https://en.wikipedia.org/wiki/Google_Cloud_Platform) over building tools for [Platform as a Service (PaaS)](https://en.wikipedia.org/wiki/Platform_as_a_service) (running software in the cloud). They are both racing to build new functionality, but it's hard to move from one vendor to another. Standards like [Kubernetes](https://en.wikipedia.org/wiki/Kubernetes) attempt to address this. + \ No newline at end of file diff --git a/docs/risks/Dependency-Risks/Lock-In-Risk/Ecosystems.md b/docs/risks/Dependency-Risks/Lock-In-Risk/Ecosystems.md index 220169f0c..06f9930ed 100644 --- a/docs/risks/Dependency-Risks/Lock-In-Risk/Ecosystems.md +++ b/docs/risks/Dependency-Risks/Lock-In-Risk/Ecosystems.md @@ -1,10 +1,13 @@ - - - -## Ecosystems and Lock-In - -Sometimes, one choice leads to another, and you're forced to "double down" on your original choice, and head further down the path of commitment. - +--- +title: Ecosystems and Lock-In +description: How we get locked into ecosystems. + +sidebar_position: 2 +tags: + - Lock-In Risk +slug: /risks/Ecosystem-Lock-In +--- + On the face of it, [WordPress](https://en.wikipedia.org/wiki/WordPress) and [Drupal](https://en.wikipedia.org/wiki/Drupal) _should_ be very similar: - They are both [Content Management Systems](https://en.wikipedia.org/wiki/Content_management_system). @@ -16,14 +19,14 @@ But crucially, the underlying abstractions of WordPress and Drupal are different > "... a set of businesses functioning as a unit and interacting with a shared market for software and services, together with relationships among them. These relationships are frequently underpinned by a common technological platform and operate through the exchange of information, resources, and artifacts." - [Software Ecosystem, _Wikipedia_](https://en.wikipedia.org/wiki/Software_ecosystem) -You can think of the ecosystem as being like the footprint of a town or a city, consisting of the buildings, transport network and the people that live there. Within the city, and because of the transport network and the amenities available, it's easy to make rapid, useful moves on the [Risk Landscape](/risks/Risk-Landscape). In a software ecosystem it's the same: the ecosystem has gathered together to provide a way to mitigate various different [Feature Risks](/tags/Feature-Risk) in a common way. +You can think of the ecosystem as being like the footprint of a town or a city, consisting of the buildings, transport network and the people that live there. Within the city, and because of the transport network and the amenities available, it's easy to make rapid, useful moves on the [Risk Landscape](/risks/Risk-Landscape). In a software ecosystem it's the same: the ecosystem has gathered together to provide a way to mitigate various different [Feature Risks](/tags/Feature-Risks) in a common way. Ecosystem size is one key determinant of [Lock-In Risk](/tags/Lock-In-Risk): - **A large ecosystem** has a large boundary circumference. [Lock-In Risk](/tags/Lock-In-Risk) is lower in a large ecosystem because your moves on the [Risk Landscape](/tags/Risk-Landscape) are unlikely to collide with it. The boundary _got large_ because other developers before you hit the boundary and did the work building the software equivalents of bridges and roads and pushing it back so that the boundary didn't get in their way. - In **a small ecosystem**, you are much more likely to come into contact with the edges of the boundary. _You_ will have to be the developer that pushes back the frontier and builds the roads for the others. This is hard work. -### Big Ecosystems Get Bigger +## Big Ecosystems Get Bigger In the real world, there is a tendency for _big cities to get bigger_. The more people that live there, the more services they provide and need, and therefore, the more immigrants they attract. It's the same in the software world too. In both cases, this is due to the [_Network Effect_](https://en.wikipedia.org/wiki/Network_effect): @@ -31,7 +34,7 @@ In the real world, there is a tendency for _big cities to get bigger_. The more ![WordPress vs Drupal adoption over 8 years, according to [w3techs.com](https://w3techs.com/technologies/history_overview/content_management/all/y)](/img/numbers/wordpress-drupal-chart.png) -You can see the same effect in the software ecosystems with the adoption rates of WordPress and Drupal, shown in the chart above. Note: this is over _all sites on the internet_, so Drupal accounts for hundreds of thousands of sites. In 2018, WordPress is approximately 32% of all web-sites. For Drupal it's 2%. +You can see the same effect in the software ecosystems with the adoption rates of WordPress and Drupal, shown in the chart above. Note: this is over _all sites on the Internet_, so Drupal accounts for hundreds of thousands of sites. In 2018, WordPress is approximately 32% of all web-sites. For Drupal it's 2%. Did WordPress gain this march because it was always _better_ than Drupal? That's arguable. Certainly, they're not different enough that WordPress is 16x better. That it's this way round could be _entirely accidental_, and a result of [Network Effect](https://en.wikipedia.org/wiki/Network_effect). @@ -48,7 +51,7 @@ But, by now, if they _are_ to be compared side-by-side, WordPress _might be bett But is bigger always better? Perhaps not. -### Big Ecosystems Are More Complex +## Big Ecosystems Are More Complex When a tool or platform is popular, it is under pressure to increase in complexity. This is because people are attracted to something useful and want to extend it to new purposes. This is known as _The Peter Principle_: @@ -60,14 +63,14 @@ Although designed for _people_, it can just as easily be applied to any other de The above chart is an example of this: look at how the number of public classes in Java (a good proxy for the boundary) has increased with each release. -#### Backward Compatibility +## Backward Compatibility -The art of good design is to afford the greatest increase in functionality with the smallest increase in complexity possible, and this usually means [Refactoring](https://en.wikipedia.org/wiki/Refactoring). But, this is at odds with [Backward Compatibility](/risks/Protocol-Risk#backward-compatibility). +The art of good design is to afford the greatest increase in functionality with the smallest increase in complexity possible, and this usually means [Refactoring](https://en.wikipedia.org/wiki/Refactoring). But, this is at odds with [Backward Compatibility](/risks/On-Protocols#backward-compatibility). -Each new version has a greater functional scope than the one before (pushing back [Lock-In Risk](/tags/Lock-In-Risk)), making the platform more attractive to build solutions in. But this increases the [Complexity Risk](/tags/Complexity-Risk) as there is more functionality to deal with. +Each new version has a greater functional scope than the one before, making the platform more attractive. But this increases the [Complexity Risk](/tags/Complexity-Risk) as there is more functionality to deal with. ![Tradeoff between large and small ecosystems](/img/generated/risks/boundary/Boundary-Risk2.svg) You can see in the diagram above the Peter Principle at play: as more responsibility is given to a dependency, the more complex it gets and the greater the learning curve to work with it. Large ecosystems like Java react to [Internal Model Risk](/tags/Internal-Model-Risk) by having copious amounts of literature to read or buy to help, but it is still off-putting. -Because [Complexity is Mass](/risks/Complexity-Risk#complexity-is-mass), large ecosystems can't respond quickly to [Feature Drift](/tags/Feature-Drift-Risk). This means that when the world changes, new ecosystems are likely to appear to fill gaps, rather than old ones moving in. +Because [Complexity is Mass](/risks/Complexity-Risk#complexity-is-mass), large ecosystems can't respond quickly to c. This means that when the world changes, new ecosystems are likely to appear to fill gaps, rather than old ones moving in. diff --git a/docs/risks/Dependency-Risks/Lock-In-Risk/Lock-In-Risk.md b/docs/risks/Dependency-Risks/Lock-In-Risk/Lock-In-Risk.md index 28b3534a1..7c8a599ec 100644 --- a/docs/risks/Dependency-Risks/Lock-In-Risk/Lock-In-Risk.md +++ b/docs/risks/Dependency-Risks/Lock-In-Risk/Lock-In-Risk.md @@ -33,8 +33,8 @@ In software development, although we might face [Lock-In Risk](/tags/Lock-In-Ris Let's take a look at a hypothetical system structure, in the diagram above. In this design, we are transforming data from the `input` to the `output`. But how should we do it? - - We could transform via library 'a', using the [Protocols](/tags/Protocol-Risk) of 'a', and having a dependency on 'a' (the top dotted path). - - We could use library 'b', using the [Protocols](/tags/Protocol-Risk) of 'b', and having a dependency on 'b' (the bottom dotted path). + - We could transform via library 'a', using the protocols of 'a', and having a dependency on 'a' (the top dotted path). + - We could use library 'b', using the protocols of 'b', and having a dependency on 'b' (the bottom dotted path). - We could use neither, and avoid the dependency, but potentially pick up lots more [Complexity Risk](/tags/Complexity-Risk) and [Schedule Risk](/tags/Schedule-Risk) because we have to code our own alternative to 'a' and 'b' (the dotted route through the middle). The choice of approach presents us with [Lock-In Risk](/tags/Lock-In-Risk) options because we don't know that we'll necessarily be successful with any of these options until we _go down the path_ of committing to one: @@ -57,7 +57,7 @@ Although ecosystems are one very pernicious type of boundary in software develop - **Integration Testing**. Building a unit test is easy. You are generally testing some code you have written, aided with a testing framework. Your code and the framework are both written in the same language, which means low [Lock-In Risk](/tags/Lock-In-Risk). But to _integration test_ you need to step outside this boundary and so it becomes much harder. This is true whether you are integrating with other systems (providing or supplying them with data) or parts of your own system (say testing the client-side and server parts together). -- **User Interface Testing**. The interface with the user is a complex, under-specified risky [protocol](/tags/Protocol-Risk). Although tools exist to automate UI testing (such as [Selenium](https://en.wikipedia.org/wiki/Selenium_(software)), these rarely satisfactorily mitigate this: can you be sure that the screen hasn't got strange glitches, that the mouse moves correctly, that the proportions on the screen are correct on all browsers? +- **User Interface Testing**. The interface with the user is a complex, under-specified risky [protocol](/tags/Communication-Risk). Although tools exist to automate UI testing (such as [Selenium](https://en.wikipedia.org/wiki/Selenium_(software)), these rarely satisfactorily mitigate this: can you be sure that the screen hasn't got strange glitches, that the mouse moves correctly, that the proportions on the screen are correct on all browsers? - **Jobs**. When you pick a new technology to learn and add to your CV, it's worth keeping in mind how useful this will be to you in the future. It's career-limiting to be stuck in a dying ecosystem with the need to retrain. @@ -71,7 +71,7 @@ Although ecosystems are one very pernicious type of boundary in software develop ### 1. Sunk Costs -The Sunk Cost of the [Learning Curve](/tags/Learning-Curve-Risk) we've overcome to integrate the dependency, which may fail to live up to expectations (_cf._ [Feature Fit Risks](/tags/Feature-Fit-Risk)). We can avoid accreting this by choosing the _simplest_ and _fewest_ dependencies for any task, and trying to [Meet Reality](/thinking/Meeting-Reality) quickly. +The Sunk Cost of the learning curve we've overcome to integrate the dependency, which may fail to live up to expectations (_cf._ [Feature Fit Risks](/tags/Feature-Fit-Risk)). We can avoid accreting this by choosing the _simplest_ and _fewest_ dependencies for any task, and trying to [Meet Reality](/thinking/Meeting-Reality) quickly. **Threat**: Although you can anticipate the level of commitment, choosing a dependency in advance is a [bet](/tags/Bet) where you have limited information. @@ -83,7 +83,7 @@ Softare libraries and products come and go. A choice that was popular when it w ### 3. Extent Of Lock-In -[The level of Lock In](Ecosystems), where the cost of switching to a new dependency in the future is some function of the level of commitment to the current dependency. As an example, consider the level of commitment you have to your mother tongue. If you have spent your entire life committed to learning and communicating in English, there is a massive level of lock-in. Overcoming this to become fluent in Chinese may be an overwhelming task. +[The level of Lock In](/risks/Ecosystem-Lock-In), where the cost of switching to a new dependency in the future is some function of the level of commitment to the current dependency. As an example, consider the level of commitment you have to your mother tongue. If you have spent your entire life committed to learning and communicating in English, there is a massive level of lock-in. Overcoming this to become fluent in Chinese may be an overwhelming task. **Threat**: Pervasive commitments (e.g. around language choices) have much higher levels of Lock-In Risk. @@ -103,7 +103,7 @@ Will the dependency satisfy your expanding requirements going forward? It's ofte **Example:** Earlier in my career, [Oracle](https://oracle.com) bought Tangosol, a small consultancy that made [Coherence](https://en.wikipedia.org/wiki/Oracle_Coherence). Having done this, they increase the licensing costs of Coherence to huge levels, milking the [Cash Cow](https://en.wikipedia.org/wiki/Cash_cow) of the installed user-base, but ensuring no-one else is likely to commit to it in the future. -**Threat**: The owner of the dependency has the opportunity to unilaterally change the licensing conditions for your dependency. (Compare to [Open Source](../Software-Dependency-Risk)). +**Threat**: The owner of the dependency has the opportunity to unilaterally change the licensing conditions for your dependency. (Compare to [Open Source](/risks/On-Software-Dependencies)). :::tip Anecdote Corner diff --git a/docs/risks/Dependency-Risks/Lock-In-Risk/Managing.md b/docs/risks/Dependency-Risks/Lock-In-Risk/Managing.md index cde734dd8..952d8b131 100644 --- a/docs/risks/Dependency-Risks/Lock-In-Risk/Managing.md +++ b/docs/risks/Dependency-Risks/Lock-In-Risk/Managing.md @@ -1,19 +1,22 @@ +--- +title: Managing Lock-In Risks +description: How to escape ecosystem lock-in - - -## Managing Lock-In Risk +sidebar_position: 3 +tags: + - Lock-In Risk +slug: /risks/Managing-Lock-In +--- Let's look at two ways in which we can manage [Lock-In Risk](/tags/Lock-In-Risk): _bridges_ and _standards_. -### Ecosystem Bridges - -![Lock-In Risk is mitigated when a bridge is built between ecosystems](/img/generated/risks/boundary/Boundary-Risk3.svg) +## Bridges -Sometimes, technology comes along that allows us to cross boundaries, like a _bridge_ or a _road_. This has the effect of making it easy to to go from one self-contained ecosystem to another. Going back to WordPress, a simple example might be the [Analytics Dashboard](https://en-gb.wordpress.org/plugins/google-analytics-dashboard-for-wp/) which provides [Google Analytics](https://en.wikipedia.org/wiki/Google_Marketing_Platform) functionality inside WordPress. +Sometimes, technology comes along that allows us to cross boundaries, like a _bridge_ or a _road_. This has the effect of making it easy to to go from one self-contained ecosystem to another. Going back to [WordPress](/risks/Ecosystem-Lock-In), a simple example might be the [Analytics Dashboard](https://en-gb.wordpress.org/plugins/google-analytics-dashboard-for-wp/) which provides [Google Analytics](https://en.wikipedia.org/wiki/Google_Marketing_Platform) functionality inside WordPress. I find, a lot of code I write is of this nature: trying to write the _glue code_ to join together two different _ecosystems_. -As shown in the above diagram, mitigating [Lock-In Risk](/tags/Lock-In-Risk) involves taking on complexity. The more [Protocol Complexity](/tags/Protocol-Risk) there is on either side of the two ecosystems, the more [complex](/tags/Complexity-Risk) the bridge will necessarily be. The below table shows some examples of this. +As shown in the above diagram, mitigating [Lock-In Risk](/tags/Lock-In-Risk) involves taking on complexity. The more [Complexity](/tags/Complexity-Risk) there is on either side of the two ecosystems, the more [complex](/tags/Complexity-Risk) the bridge will necessarily be. The below table shows some examples of this. |Communication Risk From A |Communication Risk From B |Resulting Bridge Complexity |Example | |-----------------------------|----------------------------|-----------------------------|---------------------------------------------------------| @@ -21,14 +24,12 @@ As shown in the above diagram, mitigating [Lock-In Risk](/tags/Lock-In-Risk) inv |High |Low |Moderate |Status Dashboard. | |High |High |Complex |Object-Relational Mapping (ORM) Tools. | - - From examining the risk at each end of the bridge you are creating, you can get a rough idea of how complex the endeavour will be: - If it's low-risk at both ends, you're probably going to be able to knock it out easily. Like translating a date, or converting one file format to another. - - Where one of the protocols is _evolving_, you're definitely going to need to keep releasing new versions. The functionality of a `Calculator` app on my phone remains the same, but new versions have to be released as the phone APIs change, screens change resolution and so on. + - Where one of the protocols is _evolving_, you're definitely going to need to keep releasing new versions. -### Standards +## Standards Standards mitigate [Lock-In Risk](/tags/Lock-In-Risk) in one of two ways: @@ -42,19 +43,5 @@ Standards mitigate [Lock-In Risk](/tags/Lock-In-Risk) in one of two ways: - [ASCII](https://en.wikipedia.org/wiki/ASCII): fixed the different-character-sets [Lock-In Risk](/tags/Lock-In-Risk) by being a standard that others could adopt. Before everyone agreed on ASCII, copying data from one computer system to another was a massive pain, and would involve some kind of translation. [Unicode](https://en.wikipedia.org/wiki/Unicode) continues this work. - - [Internet Protocol](https://en.wikipedia.org/wiki/Internet_Protocol). As we saw in [Communication Risk](/tags/Protocol-Risk), the Internet Protocol (IP) is the _lingua franca_ of the modern Internet. However, at one period of time, there were many competing standards. IP was the ecosystem that "won", and was subsequently standardised by the [IETF](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force). This is actually an example of _both_ approaches: as we saw in [Communication Risk](/tags/Communication-Risk), Internet Protocol is also an abstraction over lower-level protocols. - -## Lock-In Risk Cycle - -![Lock-In Risk Decreases With Bridges and Standards](/img/generated/risks/boundary/cycle.svg) - -[Lock-In Risk](/tags/Lock-In-Risk) seems to progress in cycles. As a piece of technology becomes more mature, there are more standards and bridges, and [Lock-In Risk](/tags/Lock-In-Risk) is lower. Once [Lock-In Risk](/tags/Lock-In-Risk) is low and a particular approach is proven, there will be innovation upon this, giving rise to new opportunities for [Lock-In Risk](/tags/Lock-In-Risk) (see the diagram above). Here are some examples: - - - **Processor Chips.** By providing features (instructions) on their processors that other vendors didn't have, manufacturers made their processors more attractive to system integrators. However, since the instructions were different on different chips, this created [Lock-In Risk](/tags/Lock-In-Risk) for the integrators. Intel and Microsoft were able to use this fact to build a big ecosystem around Windows running on Intel chips (so called, WinTel). The Intel instruction set is nowadays a _de-facto_ standard for PCs. - - - **Browsers.** In the late 1990s, faced with the emergence of the nascent World Wide Web, and the [Netscape Navigator](https://en.wikipedia.org/wiki/Netscape_Navigator) browser, [Microsoft](https://en.wikipedia.org/wiki/Microsoft) adopted a strategy known as [Embrace and Extend](https://en.wikipedia.org/wiki/Embrace_and_extend). The idea of this was to subvert the HTML standard to their own ends by _embracing_ the standard and creating their own browser Internet Explorer and then _extending_ it with as much functionality as possible, which would then _not work_ in Netscape Navigator. They then embarked on a campaign to try and get everyone to "upgrade" to Internet Explorer. In this way, they hoped to "own" the Internet, or at least, the software of the browser, which they saw as analogous to being the "operating system" of the Internet, and therefore a threat to their own operating system, [Windows](https://en.wikipedia.org/wiki/Microsoft_Windows). - - - **Mobile Operating Systems.** We currently have just two main _mobile_ ecosystems (although there used to be many more): [Apple's iOS](https://en.wikipedia.org/wiki/IOS) and [Google's Android](https://en.wikipedia.org/wiki/Android_(operating_system)), which are both _very_ different and complex ecosystems with large, complex boundaries. They are both innovating as fast as possible to keep users happy with their features. Bridging tools like [Xamarin](https://en.wikipedia.org/wiki/Xamarin) exist which allow you to build applications sharing code over both platforms. - - - **Cloud Computing.** [Amazon Web Services (AWS)](https://en.wikipedia.org/wiki/Amazon_Web_Services) are competing with [Microsoft Azure](https://en.wikipedia.org/wiki/Microsoft_Azure) and [Google Cloud Platform](https://en.wikipedia.org/wiki/Google_Cloud_Platform) over building tools for [Platform as a Service (PaaS)](https://en.wikipedia.org/wiki/Platform_as_a_service) (running software in the cloud). They are both racing to build new functionality, but it's hard to move from one vendor to another as there is no standardisation on the tools. + - [Internet Protocol](https://en.wikipedia.org/wiki/Internet_Protocol). As we saw in [Communication Risk](/tags/Communication-Risk), the Internet Protocol (IP) is the _lingua franca_ of the modern Internet. However, at one period of time, there were many competing standards. IP was the ecosystem that "won", and was subsequently standardised by the [IETF](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force). This is actually an example of _both_ approaches: as we saw in [Communication Risk](/tags/Communication-Risk), Internet Protocol is also an abstraction over lower-level protocols. \ No newline at end of file diff --git a/docs/risks/Dependency-Risks/On-Software-Dependencies.md b/docs/risks/Dependency-Risks/On-Software-Dependencies.md index d2e6dadb6..992fd6a97 100644 --- a/docs/risks/Dependency-Risks/On-Software-Dependencies.md +++ b/docs/risks/Dependency-Risks/On-Software-Dependencies.md @@ -6,10 +6,10 @@ slug: /risks/On-Software-Dependencies sidebar_position: 10 tweet: yes tags: - - Dependency Risk + - Dependency Risks --- -In this section, we're going to look specifically at _Software_ dependencies, although many of the concerns we'll raise here apply equally to all the other types of dependency we outlined in [Dependency Risk](/tags/Dependency-Risk). +In this section, we're going to look specifically at _Software_ dependencies, although many of the concerns we'll raise here apply equally to all the other types of dependency we outlined in [Dependency Risks](/tags/Dependency-Risks). In this section we will look at: @@ -35,7 +35,7 @@ Let's look at some more examples: |[Process-Risk](/tags/Process-Risk) |Reporting tools, online forms, process tracking tools | |[Agency-Risk](/tags/Agency-Risk) |Auditing tools, transaction logs, Time-Sheet software, HR Software | |[Operational-Risk](/tags/Operational-Risk) |Support tools like ZenDesk, Grafana, InfluxDB, Geneos, Security Tools | -|[Feature-Risk](/tags/Feature-Risk) |Every piece of software you use! | +|[Feature-Fit-Risk](/tags/Feature-Fit-Risk) |Every piece of software you use! | With this in mind, we can see that adding a software dependency is a trade-off: we reduce some risk (as in the table above), but in return we pick up [Dependency Risk](/tags/Dependency-Risks) as a result. Whether this trade-off is worth it depends entirely on how well that software dependency resolves the original risk and how onerous the new risks are that we pick up. @@ -87,7 +87,7 @@ function out() { (7 symbols) 1. **Language Matters**: the Kolmogorov complexity is dependent on the language, and the features the language has built in. 2. **Exact Kolmogorov complexity is uncomputable anyway:** Since it's the _theoretical_ minimum program length, it's a fairly abstract idea, so we shouldn't get too hung up on this. There is no function to be able to say, "What's the Kolmogorov complexity of string X?" 3. **What is this new library function we've created?** Is `abcdRepeater` going to be part of _every_ Javascript? If so, then we've shifted [Codebase Risk](/tags/Complexity-Risk) away from ourselves, but we've pushed [Communication Risk](/tags/Communication-Risk) onto every _other_ user of Javascript, because `abcdRepeater` will be clogging up the JavaScript documentation for everyone, despite being rarely useful. -4. **Are there equivalent functions for every single other string?** If so, then compilation is no longer a tractable problem because now we have a massive library of different `XXXRepeater` functions to compile against. So, what we _lose_ in [Codebase Risk](/tags/Codebase-Risk) we gain in [Complexity Risk](/risks/Complexity-Risk#space-and-time-complexity). +4. **Are there equivalent functions for every single other string?** If so, then compilation is no longer a tractable problem because now we have a massive library of different `XXXRepeater` functions to compile against. So, what we _lose_ in [Complexity Risk](/tags/Complexity-Risk) in our programs, we gain in [Complexity Risk](/risks/Complexity-Risk) in the language we use. 5. **Language design, then, is about _ergonomics_:** x After you have passed the relatively low bar of providing [Turing Completeness](https://en.wikipedia.org/wiki/Turing_completeness), the key is to provide _useful_ features that enable problems to be solved, without over-burdening the user with features they _don't_ need. And in fact, all software is about this. 6. **Language Ecosystems _really_ matter**: all modern languages allow extensions via libraries, modules or plugins. If your particular `abcdRepeater` isn't in the main library, @@ -109,12 +109,12 @@ The interface of a dependency expands when you ask it to do a wider variety of t ![Software Dependency Ergonomics: adopting complex dependencies](/img/generated/risks/software-dependency/ergonomics2.svg) -Adopting complex software dependencies (as shown in the diagram above) might allow you to avoid complexity in your own codebase. However, this likely gives you a longer learning curve before you understand the tool, and you _might_ run into issues later where the tool fails to do something critical that you wanted (a [Dead End Risk](/tags/Dead-End-Risk)). +Adopting complex software dependencies (as shown in the diagram above) might allow you to avoid complexity in your own codebase. However, this likely gives you a longer learning curve before you understand the tool, and you _might_ run into issues later where the tool fails to do something critical that you wanted (a [Lock-In Risk](/tags/Lock-In-Risk)). Using a software dependency allows us to split a project's complexity into two: - The inner complexity of the dependency (how it works internally, its own [internal complexity](/risks/Complexity-Risk#kolmogorov-complexity)). - - The complexity of the instructions that we need to write to make the tool work, [the protocol complexity](/tags/Protocol-Risk), which will be a function of the complexity of the tool itself. + - The complexity of the instructions that we need to write to make the tool work, [the protocol complexity](/tags/Communication-Risk), which will be a function of the complexity of the tool itself. ![Types of Complexity For a Software Dependency](/img/generated/risks/software-dependency/protocol-complexity.svg) @@ -144,7 +144,7 @@ All 3 approaches involve a different risk-profile. Let's look at each in turn, Way before the Internet, this was the only game in town. Tool support was very thin-on-the-ground. Algorithms could be distributed as code snippets _in books and magazines_ which could be transcribed and run, and added to your program. This spirit lives on somewhat in StackOverflow and JSFiddle, where you are expected to "adopt" others' code into your own project. Code-your-own is still the best option if you have highly bespoke requirements, or are dealing with unusual environmental contexts. -One of the hidden risks of embarking on a code-your-own approach is that the features you need are _not_ apparent from the outset. What might appear to be a trivial implementation of some piece of functionality can often turn into its own industry as more and more hidden [Feature Fit Risk](/tags/Feature-Fit-Risk) is uncovered. For example, as we discussed in our earlier treatment of [Dead-End Risk](/tags/Dead-End-Risk), building log-in screens _seemed like a good idea_. However, this gets out-of-hand fast when you need: +One of the hidden risks of embarking on a code-your-own approach is that the features you need are _not_ apparent from the outset. What might appear to be a trivial implementation of some piece of functionality can often turn into its own industry as more and more hidden [Feature Fit Risk](/tags/Feature-Fit-Risk) is uncovered. For example, as we discussed in our earlier treatment of [Dead-Ends](/risks/Complexity-Risk/Complexity-Analogies#Avoiding-Dead-Ends), building log-in screens _seemed like a good idea_. However, this gets out-of-hand fast when you need: - A password reset screen - To email the reset links to the user @@ -157,7 +157,7 @@ One of the hidden risks of embarking on a code-your-own approach is that the fea ### Unwritten Software -Sometimes you will pick up [Dependency Risk](/tags/Dependency-Risk) from _unwritten software_. This commonly happens when work is divided amongst team members, or teams. +Sometimes you will pick up [Dependency Risks](/tags/Dependency-Risks) from _unwritten software_. This commonly happens when work is divided amongst team members, or teams. ![Sometimes, a module you're writing will depend on unwritten code](/img/generated/risks/software-dependency/unwritten.svg) diff --git a/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md b/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md index 9c75dae76..224098d8d 100644 --- a/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md +++ b/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md @@ -23,7 +23,7 @@ part_of: Dependency Risks Process Risk intersects with several other types of risk we've covered so far: - [Agency Risk](/tags/Agency-Risk): Processes have their own agency - they often involve decision making (a loan application or passport renewal). -- [Reliability Risk](tags/Reliability-Risk): Processes can fail for various reasons (a payment process for example) or unavailable when they lack resources (think of CPU bottlenecks or queues at the post-office counter).. +- [Reliability Risk](/tags/Reliability-Risk): Processes can fail for various reasons (a payment process for example) or unavailable when they lack resources (think of CPU bottlenecks or queues at the post-office counter).. - [Communication Risk](/tags/Communication-Risk): You need to communicate intent to the process, and have it report back its status (think of buying something on the Internet, and the delivery company communicating where the parcel is in transit). - [Feature Fit Risk](/tags/Feature-Fit-Risk): A Process should be supplying some useful _features_ to you in order for you to use it. Is it fit for purpose? (An example might be starting to fill out a form but then realising you're filling out the wrong form). @@ -83,11 +83,11 @@ For the customers of the team, the introduction of the issue management system c ### 3. Lost Accountability -- **Threat**: Processes can reduce accountability. _Following a process_ instead of making decisions as you go gives people (and systems) allows for scapegoating the process when things go wrong. +- **Threat**: Processes can reduce accountability. _Following a process_ instead of making decisions as you go gives people (and systems) allows for scape-goating the process when things go wrong. ### 4. Bureaucratic Creep -- **Threat**: Its easier for processes to accrete rather than be decommissioned. This is [Parkinson's Law](On-Bureaucracy) and slowly ratchets up inefficiency. +- **Threat**: Its easier for processes to accrete rather than be decommissioned. This is an implication of Parkinson's Law and slowly ratchets up inefficiency. :::tip Anecdote Corner @@ -95,7 +95,7 @@ Over the years I have worked in the Finance Industry it's given me time to obser 1. Initially, I could release software by logging onto the production accounts with a shared password that everyone knew, and deploy software or change data in the database. 2. The first issue with this is [Agency Risk from bad actors](/tags/Agency-Risk): how could you know that the numbers weren't being altered in the databases? _Production Auditing_ was introduced so that at least you could tell what was being changed and when, in order to point the blame later. -3. But there was still plenty of scope for deliberate or accidental [Dead-End Risk](/tags/Dead-End-Risk) damage. Next, passwords were taken out of the hands of developers and you needed approval to "break glass" to get onto production. +3. But there was still plenty of scope for deliberate or accidental damage. Next, passwords were taken out of the hands of developers and you needed approval to "break glass" to get onto production. 4. The increasing complexity (and therefore [Complexity Risk](/tags/Complexity-Risk)) in production environments meant that sometimes changes collided with each other, or were performed at inopportune times. Change Requests were introduced. This is an approval process which asks you to describe what you want to change in production, and why you want to change it. 5. The change request software is generally awful, making the job of raising change requests tedious and time-consuming. Therefore, in one workplace, developers _automated_ the processes for release, including the process to write the change request. This allowed them to improve release cadence at the expense of owning more code. 6. Auditors didn't like the fact that this automation existed: effectively, that meant that developers could get access to production with the press of a button, taking you back to step 1... diff --git a/docs/risks/Dependency-Risks/Reliability-Risk/Reliability-Risk.md b/docs/risks/Dependency-Risks/Reliability-Risk/Reliability-Risk.md index ec5a07d32..6f4c6907d 100644 --- a/docs/risks/Dependency-Risks/Reliability-Risk/Reliability-Risk.md +++ b/docs/risks/Dependency-Risks/Reliability-Risk/Reliability-Risk.md @@ -41,6 +41,8 @@ Availability is a measure of reliability often used for services, often expresse **Threat:** An online service that you want to use doesn't publish [Service Level Agreements (SLAs)](https://en.wikipedia.org/wiki/Service-level_agreement) and therefore it's hard to build software reliably on top of it. +**Threat:** People also suffer reliability issues! Staff can be sick or leave. This is a threat to the reliability of services you build. + ### 2. Quality of Service (QoS) Often a service dependency can be responding quickly (i.e. have good availability) but still perform inadequately, perhaps with wrong or sloppy results. diff --git a/docs/risks/Dependency-Risks/Schedule-Risk/Schedule-Risk.md b/docs/risks/Dependency-Risks/Schedule-Risk/Schedule-Risk.md index e60dea56a..ba3f93f49 100644 --- a/docs/risks/Dependency-Risks/Schedule-Risk/Schedule-Risk.md +++ b/docs/risks/Dependency-Risks/Schedule-Risk/Schedule-Risk.md @@ -22,7 +22,7 @@ part_of: Dependency Risks So [Schedule Risk](/tags/Schedule-Risk) is the risk around schedules we try to impose on our work, usually because we cannot know _a priori_ how long a piece of work will take. Unrealistically low estimates are therefore the source of [Schedule Risk](/tags/Schedule-Risk): the more aggressive the estimate, the more risk you are running, even though every now and again you might win the estimation lottery and find _just the right piece_ of open source code to take a short-cut through time and hit the estimate. -Some developers take the view that [estimates aren't necessary](https://ronjeffries.com/xprog/articles/the-noestimates-movement/) and sometimes perhaps they aren't. However at a basic level this doesn't stand up to scrutiny: you do need to know whether a piece of work is worth embarking on. Will it take a day? A week? A month? A year? The answer to this question fundamentally affects the value of the work that is being undertaken. In the case where multiple alternative solutions are possible, using your [internal model](tags/Internal-Model) to estimate the cost of each may be a key way to decide which path to follow. +Some developers take the view that [estimates aren't necessary](https://ronjeffries.com/xprog/articles/the-noestimates-movement/) and sometimes perhaps they aren't. However at a basic level this doesn't stand up to scrutiny: you do need to know whether a piece of work is worth embarking on. Will it take a day? A week? A month? A year? The answer to this question fundamentally affects the value of the work that is being undertaken. In the case where multiple alternative solutions are possible, using your [internal model](/tags/Internal-Model) to estimate the cost of each may be a key way to decide which path to follow. **See:** This is a topic that is covered in depth in the section on [Estimating](/estimating/Start) in Risk-First. diff --git a/docs/risks/Environmental-Risks/Environmental-Risks.md b/docs/risks/Environmental-Risks/Environmental-Risks.md index 2cda0e6a4..2d2a0ce83 100644 --- a/docs/risks/Environmental-Risks/Environmental-Risks.md +++ b/docs/risks/Environmental-Risks/Environmental-Risks.md @@ -9,7 +9,7 @@ featured: tweet: yes slug: /risks/Environmental-Risks tags: - - Environmental Risk + - Environmental Risks --- # Environmental Risks @@ -22,10 +22,10 @@ It's important to understand that software is always operating within a context. One useful technique for environmental analysis is [PEST or PESTLE](https://en.wikipedia.org/wiki/PEST_analysis), which breaks down the environment into specific components: Political, Economic, Social, Technological, Legal and Ecological. Other frameworks suggest looking at Demographic, Geographic or Military elements too. -There is a lot to this subject, so this section is just a taster: we're going to consider just two specific types of environmental risk, [Security Risk](/tags/Security-Risk) and [Legal Risk](/tags/Legal-Risk). And then cap off the taxonomy of risks by looking at [Operational Risk](/tags/Operational-Risk), which really encompasses the others. - ## Types Of Environmental Risk +There is a lot to this subject, so this section is just a taster: we're going to consider just two specific types of environmental risk, [Security Risk](/tags/Security-Risk), [Legal Risk](/tags/Legal-Risk) and [Reputational Risk](/tags/Reputational-Risk). And then cap off the taxonomy of risks by looking at [Operational Risk](/tags/Operational-Risk), which really encompasses the others. + diff --git a/docs/risks/Environmental-Risks/Legal-Risk/Legal-Risk.md b/docs/risks/Environmental-Risks/Legal-Risk/Legal-Risk.md index 4a16d6888..29937b4cd 100644 --- a/docs/risks/Environmental-Risks/Legal-Risk/Legal-Risk.md +++ b/docs/risks/Environmental-Risks/Legal-Risk/Legal-Risk.md @@ -13,8 +13,7 @@ tweet: yes tags: - Risks - Legal Risk - - Environmental Risk -part_of: Operational Risk +part_of: Environmental Risks --- diff --git a/docs/risks/Environmental-Risks/Operational-Risk/Operational-Risk.md b/docs/risks/Environmental-Risks/Operational-Risk/Operational-Risk.md index f5c6de388..56bf6f212 100644 --- a/docs/risks/Environmental-Risks/Operational-Risk/Operational-Risk.md +++ b/docs/risks/Environmental-Risks/Operational-Risk/Operational-Risk.md @@ -12,9 +12,8 @@ sidebar_position: 4 tweet: yes tags: - Risks - - Legal Risk - Operational Risk - - Environmental Risk + - Environmental Risks --- @@ -33,7 +32,7 @@ They decide to [out-source](/tags/Outsourcing) their support function to a low-c Any of the risks we've covered so far can knock-on to be an [Operational Risk](/tags/Operational-Risk) - that's one of the main reasons we've left this until the end. Below is a non-exhaustive look at some of the ways these intersect. -In reality, there is a long laundry-list of everything that can go wrong due to operating in "The Real World". Effective [Operational Risk Management](/tags/Operational-Risk) means we have to consider that these dependencies will fail in any number of unusual ways, and we can't be ready for all of them. Preparing for this comes under the umbrella of [Operations Management](Operations-Mmanagement). +In reality, there is a long laundry-list of everything that can go wrong due to operating in "The Real World". Effective [Operational Risk Management](/tags/Operational-Risk) means we have to consider that these dependencies will fail in any number of unusual ways, and we can't be ready for all of them. Preparing for this comes under the umbrella of [Operations Management](Operations-Management). ### 1. Process Risk diff --git a/docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md b/docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md index 7f83568e1..445f13c19 100644 --- a/docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md +++ b/docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md @@ -1,5 +1,11 @@ +--- +title: Operations Management +description: How Operations Managers handle Operational Risk -## Operations Management +slug: /risks/Operations-Management +tags: + - Operational Risk +--- If we are designing a software system to "live" in the real world we have to be mindful of the **Operational Context** we're working in and craft our software and processes accordingly. This view of the "wider" system is the discipline of Operations Management. @@ -17,7 +23,7 @@ The diagram above is a Risk-First interpretation of [Slack _et al_'s model of Op ![Risk-First Operations Management: Taking Action, inspired by the work of Slack _et al._](/img/generated/risks/operational/operational-risk.svg) -The healthy functioning of the **Transform Process** is the domain of [Operations Management](#operations-management). As the above diagram shows (again, modified from Slack _et al._) this involves the following types of actions. +The healthy functioning of the **Transform Process** is the domain of Operations Management. As the above diagram shows (again, modified from Slack _et al._) this involves the following types of actions. - **Control**: ensuring that the Transform Process is working according to its targets. This includes day-to-day quality control and monitoring . - **Planning**: this covers aspects such as capacity planning, forecasting and project planning. This is about making sure the transform process has targets to meet and the resources to meet them. @@ -46,11 +52,11 @@ As we saw in [Internal Model Risk](/tags/Internal-Model-Risk), it's very easy to ### Scanning The Operational Context -There are plenty of [Hidden Risks](/tags/Hidden-Risk) within the operation's environment. These change all the time in response to economic, legal or political change. In order to manage a risk, you have to uncover it, so part of [Operations Management](#operations-management) is to look for trouble. +There are plenty of [Hidden Risks](/tags/Hidden-Risk) within the operation's environment. These change all the time in response to economic, legal or political change. In order to manage a risk, you have to uncover it, so part of Operations Management is to look for trouble. - **Environmental Scanning** is all about trying to determine which changes in the environment are going to impact your operation. Here we are trying to determine the level of [Dependency Risk](/tags/Dependency-Risks) we face for external dependencies, such as suppliers, customers, markets and regulation. Tools like [PEST](https://en.wikipedia.org/wiki/PEST_analysis) are relevant, as is - **[Penetration Testing](https://en.wikipedia.org/wiki/Penetration_test)**: looking for security weaknesses within the operation. See [OWASP](https://en.wikipedia.org/wiki/OWASP) for examples. -- **[Vulnerability Management](https://en.wikipedia.org/wiki/Vulnerability_management)** is about keeping up-to-date with vulnerabilities in [Software Dependencies](/tags/Software-Dependency-Risk). +- **[Vulnerability Management](https://en.wikipedia.org/wiki/Vulnerability_management)** is about keeping up-to-date with vulnerabilities in [Software Dependencies](/risks/On-Software-Dependencies). ## Planning @@ -64,7 +70,7 @@ As the diagram above shows, we can bring [Planning](#planning) to bear on depend ![Design and Change Activities](/img/generated/risks/operational/design-change.svg) -Since our operation exists in a world of risks like [Red Queen Risk](/tags/Red-Queen-Risk) and [Market Risk](/tags/Market-Risk), we would expect that the output of our [Planning](#planning) actions would result in changes to our operation. +Since our operation exists in a world of [Environmental Risks](/tags/Environmental-Risks) we would expect that the output of our [Planning](#planning) actions would result in changes to our operation. While _planning_ is a day-to-day operational feedback loop, _design_ is a longer feedback loop changing not just the parameters of the operation, but the operation itself. @@ -74,33 +80,4 @@ In recent years the [DevOps](https://en.wikipedia.org/wiki/DevOps) movement has - Using code to automate previously manual Operations functions, like monitoring and releasing. - Involving Operations in the planning and design, so that the delivered software is optimised for the environment it runs in. - -## Improvement - -No system can be perfect, and after it meets the real world, we will want to improve it over time. But [Operational Risk](/tags/Operational-Risk) includes an element of [Reputational Risk](/tags/Reputational-Risk): we have a _reputation_ and the good will of our customers to consider when we make improvements. Because this is very hard to rebuild, we should consider this before releasing software that might not live up to expectations. - -So there is a tension between "you only get one chance to make a first impression" and "gilding the lily" (perfectionism). In the past I've seen this stated as _pressure to ship vs pressure to improve_. - -![Balance of Risks from Delivering Software](/img/generated/risks/operational/ship-it.svg) - -A Risk-First re-framing of this (as shown in the diagram above) might be the balance between: - -- The perceived scarcity (such as funding, time available, etc) of staying in development (pressure to ship). -- The perceived [Reputational Risk](/tags/Reputational-Risk), [Feature Fit Risk](/tags/Feature-Fit-Risk) and [Operational Risk](/tags/Operational-Risk) of going to production (pressure to improve). - -The "should we ship?" decision is therefore a complex one. In [Meeting Reality](/thinking/Meeting-Reality), we discussed that it's better to do this "sooner, more frequently, in smaller chunks and with feedback". We can meet [Operational Risk](/tags/Operational-Risk) _on our own terms_ by doing so: - -|Meet Reality... |Techniques | -|----------------------------|----------------------------------------------------------------------| -|**Sooner** |Beta Testing, Soft Launches, Business Continuity Testing | -|**More Frequently** |Continuous Delivery, Sprints | -|**In Smaller Chunks** |Modular Releases, Microservices, Feature Toggles, Trial Populations | -|**With Feedback** |User Communities, Support Groups, Monitoring, Logging, Analytics | - - - -## The End Of The Road - -In a way, [actions](/tags/Take-Action) like [Design](/tags/Design) and [Development](/tags/Coding) bring us right back to where we started from: identifying [Dependency Risks](/tags/Dependency-Risks), [Feature Risks](/tags/Feature-Risks) and [Complexity Risks](/tags/Complexity-Risk) that hinder our operation, and mitigating them through actions like _software development_. - -Our safari of risk is finally complete: it's time to reflect on what we've seen in the next section, [Staging and Classifying](Staging-And-Classifying). \ No newline at end of file + \ No newline at end of file diff --git a/docs/risks/Environmental-Risks/Reputational-Risk/Reputational-Risk.md b/docs/risks/Environmental-Risks/Reputational-Risk/Reputational-Risk.md new file mode 100644 index 000000000..2c52b8ab0 --- /dev/null +++ b/docs/risks/Environmental-Risks/Reputational-Risk/Reputational-Risk.md @@ -0,0 +1,77 @@ +--- +title: Reputational Risk +description: Reputational risk is the potential harm to reputation. + +slug: /risks/Reputational-Risk + + +featured: + class: c + element: '' +sidebar_position: 3 +tweet: yes +tags: + - Risks + - Reputational Risk +part_of: Environmental Risks +--- + + + +Although [protocols](/risks/On-Protocols) can sometimes handle security features of communication (such as [Authentication](https://en.wikipedia.org/wiki/Authentication) and preventing [man-in-the-middle attacks](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)), we cannot guarantee that when a message is sent to us we can trust its source. + + trust goes further than this, it is the flip-side of [Agency Risk](/tags/Agency-Risk), which we will look at later: can you be sure that the other party in the communication is acting in your best interests? + + +## Worked Example + + +No software system can be perfect, and after it meets the real world, we will likely want to improve it over time. But delivering a scrappy, early version of a piece of software is a [Reputational Risk](/tags/Reputational-Risk) threat: because reputation is very hard to rebuild, we need to be careful about releasing software that might not live up to expectations. + +So there is a tension between "you only get one chance to make a first impression" and "gilding the lily" (perfectionism). In the past I've seen this stated as _pressure to ship vs pressure to improve_. + +![Balance of Risks from Delivering Software](/img/generated/risks/operational/ship-it.svg) + +A Risk-First re-framing of this (as shown in the diagram above) might be the balance between: + +- The perceived scarcity (such as [funding](/tags/Funding-Risk), [time available](/tags/Deadline-Risk), etc) of staying in development (pressure to ship). +- The perceived [Reputational Risk](/tags/Reputational-Risk), [Feature Fit Risk](/tags/Feature-Fit-Risk) and [Operational Risk](/tags/Operational-Risk) of going to production (pressure to improve). + +The "should we ship?" decision is therefore a complex one. In [Meeting Reality](/thinking/Meeting-Reality), we discussed that it's better to do this "sooner, more frequently, in smaller chunks and with feedback". We can manage [Reputational Risk](/tags/Reputational-Risk) _on our own terms_ by doing so: + +|Meet Reality... |Techniques | +|----------------------------|----------------------------------------------------------------------| +|**Sooner** |Beta Testing, Soft Launches, Business Continuity Testing | +|**More Frequently** |Continuous Delivery, Sprints | +|**In Smaller Chunks** |Modular Releases, Microservices, Feature Toggles, Trial Populations | +|**With Feedback** |User Communities, Support Groups, Monitoring, Logging, Analytics | + +## Example Threats + +### 1. Negative Publicity, Misinformation, Lies and Gossip + +**Threat**: Your reputation is not entirely under your own control: external sources could present risks to reputation. + +### 2. Misconduct, Behaviour, Legal Issues + +**Threat**: When your organisation, or employees within it, break laws or social norms this possibly will have a wider reputational impact. + +### 3. Product Failures / Data Breaches + +**Threat**: [Operational Problems](/tags/Operational-Risk) of all kinds can tarnish your reputation with both potential and existing customers. + +### 4. Other Environmental Factors + +**Threat**: All of the [Environmental Risks](/tags/Environmental-Risks) could potentially form reputational threats too: e.g political associations, Environmental, Social and Goveranance (ESG) mis-steps or associations with the wrong parties. + +:::tip Anecdote Corner + +Software systems can easily lead to reputational damage, as in the [British Post Office scandal](https://en.wikipedia.org/wiki/British_Post_Office_scandal), also called the Horizon IT scandal (the name of the IT system involved). Between 2009 and 2015, hundreds of British subpostmasters (people running branches of the Post Office) were convicted of theft, fraud and false accounting based on records from an IT system called Horizon, built by Fujitsu. + +In 2017, the subpostmasters, lead by Allen Bates, brought a claim against the Post Office in the British High Court which started a process of quashing the convictions. In 2022, [a full public inquiry](https://www.postofficehorizoninquiry.org.uk) was set up by the government and postmasters began suing for damages, expected to reach £1bn. + +In January 2024, a British TV channel broadcast an award-winning drama called [Mr Bates vs The Post Office](https://en.wikipedia.org/wiki/Mr_Bates_vs_The_Post_Office) which led to a withdrawal of a CBE for Paula Vennels, the ex-CEO of the Post Office and new laws to exonerate and compensate subpostmasters was drawn up by the UK parliament. + +Although this might have started as a simple programming error, it's hard to treat this as the only source of Reputational, Operational and Legal Risk. Clearly there is something more going on: an over-reliance on technology, institutional failure and short-term efforts to minimise reputational damage and financial losses are also likely to be big contributing factors in this tragedy. + +::: \ No newline at end of file diff --git a/docs/risks/Environmental-Risks/Security-Risk/Security-Risk.md b/docs/risks/Environmental-Risks/Security-Risk/Security-Risk.md index 57ad7b287..bc25bba98 100644 --- a/docs/risks/Environmental-Risks/Security-Risk/Security-Risk.md +++ b/docs/risks/Environmental-Risks/Security-Risk/Security-Risk.md @@ -13,8 +13,7 @@ tweet: yes tags: - Risks - Security Risk - - Environmental Risk -part_of: Operational Risk +part_of: Environmental Risks --- @@ -80,7 +79,7 @@ Some examples include malware, phishing, Zero-Day Exploits and Distributed Denia ### 3. Personnel-Based Threats -**Threat**: Insider attacks (see [Agency Risk](tag/Agency-Risk) for more examples. +**Threat**: Insider attacks (see [Agency Risk](/tags/Agency-Risk) for more examples. **Threat**: Social engineering - persuading employees to reveal sensitive information or grant elevated access. diff --git a/docs/risks/Feature-Risks/Application.md.unused b/docs/risks/Feature-Risks/Application.md.unused deleted file mode 100644 index 92b6198d4..000000000 --- a/docs/risks/Feature-Risks/Application.md.unused +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Feature Risks: Application" -description: Some notes on applying feature risks -featured: - class: ff - element: 'Application' -sidebar_position: 10 -sidebar_label: Application ---- - -Next time you are grooming the backlog, why not apply this: - - - Can you judge which tasks mitigate the most [Feature Risk](/tags/Feature-Risk)? - - Are you delivering features that are valuable across a large audience? Or of less value across a wider audience? - - How does writing a specification mitigate [Fit Risk](/tags/Feature-Fit-Risk)? For what other reasons are you writing specifications? - - Does the audience _know_ that the features exist? How do you communicate feature availability to them? - -In the next section, we are going to unpack this last point further. Somewhere between "what the customer wants" and "what you give them" is a _dialogue_. In using a software product, users are engaging in a _dialogue_ with its features. If the features don't exist, hopefully they will engage in a dialogue with the development team to get them added. - -These dialogues are prone to risk and this is the subject of the next section, [Communication Risk](/tags/Communication-Risk). \ No newline at end of file diff --git a/docs/risks/Feature-Risks/Feature-Drift-Risk.md-unused b/docs/risks/Feature-Risks/Feature-Drift-Risk.md-unused deleted file mode 100644 index 934ee96f1..000000000 --- a/docs/risks/Feature-Risks/Feature-Drift-Risk.md-unused +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Feature Drift Risk -description: Risk that the features required by clients will change and evolve over time. - -featured: - class: ff - element: '' -sidebar_position: 7 -tags: - - Risks - - Feature Drift Risk -part_of: Feature Risk ---- - - - -![Feature Drift Risk](/img/generated/risks/feature/feature-drift-risk.svg) - -**Feature Drift** is the tendency that the features people need _change over time_. - -For example, at one point in time, supporting IE6 was right up there for website developers, but it's not really relevant anymore. The continual improvements we see in processor speeds and storage capacity of our computers is another example: the [Wii](https://en.wikipedia.org/wiki/Wii) was hugely popular in the early 2000's, but expectations have moved on now. - -The point is: what users want _today_ might not make it to _tomorrow_. This is especially true in the fast-paced world of IT. Over time, the market _evolves_ and becomes more discerning. This happens in several ways: - - - Features present in competitors' versions of the software become _the baseline_, and they're expected to be available in your version. - - Certain ways of interacting become the norm (e.g. [querty](https://en.wikipedia.org/wiki/QWERTY) keyboards, or the control layout in cars: these don't change with time). - - Features decline in usefulness: _Printing_ is less important now than it was, for example. - -As shown in the diagram, saving your project from Feature Drift Risk means **further design and development**. But trying to keep up with users' changing demands can re-introduce [Conceptual Integrity Risk](/tags/Conceptual-Integrity-Risk) back into your project. - -Sometimes, the only way to go is to start again with a clean sheet by some **distruptive innovation**. - -[Feature Drift Risk](/tags/Feature-Drift-Risk) is _not the same thing_ as **Requirements Drift**, which is the tendency projects have to expand in scope as they go along. There are lots of reasons they do that, a key one being the [Hidden Risks](/tags/Hidden-Risk) uncovered on the project as it progresses. diff --git a/docs/risks/Feature-Risks/Feature-Fit-Risk.md b/docs/risks/Feature-Risks/Feature-Fit-Risk.md index a0f22d871..11f1caa08 100644 --- a/docs/risks/Feature-Risks/Feature-Fit-Risk.md +++ b/docs/risks/Feature-Risks/Feature-Fit-Risk.md @@ -10,6 +10,7 @@ tags: - Risks - Feature Fit Risk part_of: Feature Risks +slug: /risks/Feature-Fit-Risk --- @@ -50,7 +51,7 @@ In the above diagram, we can see Feature Fit Risk being addressed by [Analysis]( ### 6. Over-Complication -**Threat**: In an effort to provide as much as many features as possible, software can become over-complicated and hard to use. Trying to mitigate [Feature Fit Risk](/tags/Feature-Fit-Risk) can lead to [Complexity Risk](/tags/Complexity-RisK). +**Threat**: In an effort to provide as much as many features as possible, software can become over-complicated and hard to use. Trying to mitigate [Feature Fit Risk](/tags/Feature-Fit-Risk) can lead to [Complexity Risk](/tags/Complexity-Risk). :::tip Anecdote Corner diff --git a/docs/risks/Feature-Risks/Implementation-Risk.md b/docs/risks/Feature-Risks/Implementation-Risk.md index aacfcfc59..9b7ecb82b 100644 --- a/docs/risks/Feature-Risks/Implementation-Risk.md +++ b/docs/risks/Feature-Risks/Implementation-Risk.md @@ -9,6 +9,7 @@ tags: - Risks - Implementation Risk part_of: Feature Risks +slug: /risks/Implementation-Risk --- @@ -19,7 +20,7 @@ part_of: Feature Risks ![Reducing Implementation Risk Via Automated Testing](/img/generated/risks/posters/implementation-risk.svg) -In the above diagram, we can see [Implementation Risks](/tags/Implementation-Risk) being addressed by [Automated Testing](../../practices/Testing-And-Quality-Assurance/Automated-Testing) - building out a series of examples and running them to make sure the software behaves as expected. The downsides of this may include the extra [complexity](/tags/Complexity-Risk) in the project and the [impact to the schedule](/tags/Schedule-Risk) of building the tests. +In the above diagram, we can see [Implementation Risks](/tags/Implementation-Risk) being addressed by [Automated Testing](/tags/Automated-Testing) - building out a series of examples and running them to make sure the software behaves as expected. The downsides of this may include the extra [complexity](/tags/Complexity-Risk) in the project and the [impact to the schedule](/tags/Schedule-Risk) of building the tests. As you can see from the table at the top, many of the practices we adopt in software development have been designed for the purpose of tackling [Implementation Risks](/tags/Implementation-Risk), but incur their own overheads in terms of effort and time. diff --git a/docs/risks/Feature-Risks/Market-Risk.md b/docs/risks/Feature-Risks/Market-Risk.md index 90f16ccda..d717c8c94 100644 --- a/docs/risks/Feature-Risks/Market-Risk.md +++ b/docs/risks/Feature-Risks/Market-Risk.md @@ -9,6 +9,7 @@ tags: - Risks - Market Risk part_of: Feature Risks +slug: /risks/Market-Risk --- diff --git a/docs/risks/Feature-Risks/Service-Quality-Model.md.unused b/docs/risks/Feature-Risks/Service-Quality-Model.md.unused deleted file mode 100644 index 154df6cc0..000000000 --- a/docs/risks/Feature-Risks/Service-Quality-Model.md.unused +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Feature Risks: Analysis" -description: Analysis of what Feature Risk tells us. -featured: - class: ff - element: 'Analysis' -sidebar_position: 9 -sidebar_label: Analysis ---- - -## Analysis - -So far in this section, we've simply seen a bunch of different types of [Feature Risk](/tags/Feature-Risk). But we're going to be relying heavily on [Feature Risk](/tags/Feature-Risk) as we go on in order to build our understanding of other risks, so it's probably worth spending a bit of time up front to classify what we've found. - -The [Feature Risks](/tags/Feature-Risk) identified here basically exist in a space with at least 3 dimensions: - - - **Fit**: how well the features fit for a particular client. - - **Audience**: the range of clients (the _market_) that may be able to use this feature. - - **Change**: the way the fit and the audience changes and evolves as time goes by. - -Let's examine each in turn. - -### Fit - - > "This preservation, during the battle for life, of varieties which possess any advantage in structure, constitution, or instinct, I have called Natural Selection; and Mr. Herbert Spencer has well expressed the same idea by the Survival of the Fittest" - [Charles Darwin (Survival of the Fittest), _Wikipedia_](https://en.wikipedia.org/wiki/Survival_of_the_fittest). - -Darwin's conception of fitness was not one of athletic prowess, but how well an organism worked within the landscape, with the goal of reproducing itself. - -[Feature Fit Risk](/tags/Feature-Fit-Risk), [Conceptual Integrity Risk](/tags/Conceptual-Integrity-Risk) and [Implementation Risk](/tags/Implementation-Risk) all hint at different aspects of this "fitness". We can conceive of them as the gaps between the following entities: - - - **Perceived Need**, what the developers _think_ the users want. - - **Expectation**, what the user _expects_. - - **Reality**, what they actually _get_. - -![Feature Risks Assembled. Fit Risks, shown as _gaps_, as in the _Service Quality Model_](/img/generated/risks/feature/all-feature-risk.svg) - -For further reading, you can check out [The Service Quality Model](https://en.wikipedia.org/wiki/SERVQUAL) which the diagram above is derived from. This model analyses the types of _quality gaps_ in services and how consumer expectations and perceptions of a service arise. - -In the [Staging And Classifying](/risks/Staging-And-Classifying) section we'll come back and build on this model further. - -## Delight - -If this breakdown of [Feature Risks](/tags/Feature-Risks) seems reductive, then try not to think of it that way: the aim _of course_ should be to delight users, and turn them into fans. - -Consider [Feature Risks](/tags/Feature-Risks) from both the down-side and the up-side: - - - What are we missing? - - How can we be _even better_? diff --git a/docs/risks/Internal-Model-Risk/Internal-Model-Risk.md b/docs/risks/Internal-Model-Risk/Internal-Model-Risk.md index 90a8b9e4b..7522b0668 100644 --- a/docs/risks/Internal-Model-Risk/Internal-Model-Risk.md +++ b/docs/risks/Internal-Model-Risk/Internal-Model-Risk.md @@ -2,7 +2,7 @@ title: Internal Model Risk description: Risks due to the differences between reality and an internal model of reality, and the assumption that they are equivalent. - +slug: /risks/Internal-Model-Risk featured: class: c element: '' diff --git a/docs/risks/Risk-Landscape.md b/docs/risks/Risk-Landscape.md index 25600534c..0fa1dbca6 100644 --- a/docs/risks/Risk-Landscape.md +++ b/docs/risks/Risk-Landscape.md @@ -59,7 +59,7 @@ Below is a table outlining the different risks we'll see. There _is_ an order t |[Dependency Risks](/tags/Dependency-Risks) |Risks of depending on other people, products, software, functions, etc. This is a broken down into specific sub-risks like [Deadline Risk](/tags/Deadline-Risk), [Agency Risk](/tags/Agency-Risk), [Process Risk](/tags/Process-Risk) and [Lock-In Risk](/tags/Lock-In-Risk) . | |[Internal Model Risk](/tags/Internal-Model-Risk) |Risks due to the fact that people don't see the world as it really is. (After all, they're working off different, imperfect [Internal Models](/tags/Internal-Model).)| |[Coordination Risk](/tags/Coordination-Risk) |Risks due to the fact that systems contain multiple agents, which need to work together.| -|[Environmental Risks](/tags/Environmental-Risk) |Software is embedded in a system containing people, buildings, machines and other services. This section considers this wider picture of risk associated with running a software service or business in the real world.| +|[Environmental Risks](/tags/Environmental-Risks) |Software is embedded in a system containing people, buildings, machines and other services. This section considers this wider picture of risk associated with running a software service or business in the real world.| After the last stop on the tour, in [Staging and Classifying](Staging-And-Classifying) we'll have a recap about what we've seen and make some guesses about how things fit together. @@ -105,4 +105,4 @@ Just as naturalists are able to head out and find new species of insects and pla It's a big, crazy, evolving world of software. Help to fill in the details. Report back what you find. -So, let's get started with [Feature Risk](/tags/Feature-Risk). +So, let's get started with some [Feature Risks](/tags/Feature-Risks). diff --git a/docs/tags.yml b/docs/tags.yml index 30c792e0f..6d39b0c45 100644 --- a/docs/tags.yml +++ b/docs/tags.yml @@ -206,6 +206,10 @@ "Reliability Risk": label: "Reliability Risk" permalink: "Reliability-Risk" + +"Reputational Risk": + label: "Reputational Risk" + permalink: "Reputational-Risk" "Requirements Capture": label: "Requirements Capture" diff --git a/docs/thinking/Anti-Goals.md b/docs/thinking/Anti-Goals.md index 4d6d7e2ac..d942d72e6 100644 --- a/docs/thinking/Anti-Goals.md +++ b/docs/thinking/Anti-Goals.md @@ -91,7 +91,7 @@ We need to acknowledge that pursuing certain goals via certain courses of action ## Summing Up -The most valuable project management skill is being able to chart a course controlling your exposure to risk. Sometimes, that will mean [hitting a deadline](/tags/Deadline-Risk), but equally it could be [reducing codebase complexity](/tags/Complexity-Risk), [making a feature more accessible](/tags/Feature-Access-Risk) or [removing problematic dependencies](/tags/Software-Dependency-Risk). +The most valuable project management skill is being able to chart a course controlling your exposure to risk. Sometimes, that will mean [hitting a deadline](/tags/Deadline-Risk), but equally it could be [reducing codebase complexity](/tags/Complexity-Risk), [making a feature more accessible](/tags/Feature-Fit-Risk) or [removing problematic dependencies](/tags/Dependency-Risks). The most important skill is to be able to _weigh up the risks_, decide on a course of action that exposes you to the greatest expected return, while looking for ways of increasing the payoff of winning and minimise the impact of losing. diff --git a/docs/thinking/Consider-Payoff.md b/docs/thinking/Consider-Payoff.md index bf089787e..a8c7679ce 100644 --- a/docs/thinking/Consider-Payoff.md +++ b/docs/thinking/Consider-Payoff.md @@ -120,7 +120,7 @@ But, there is always the opposite opinion: [You _Are_ Gonna Need It](http://wik So which is right? We should conclude that we do the work _if there is a worthwhile [Payoff](/tags/Payoff)_. - - Logging statements are _good_, because otherwise, you're increasing the risk that in production, no one will be able to understand [how the software went wrong](/tags/Invisibility-Risk). + - Logging statements are _good_, because otherwise, you're increasing the risk that in production, no one will be able to understand [how the software went wrong](/tags/Communication-Risk). - However, adding them takes time, which might [risk us not hitting our schedule](/tags/Schedule-Risk). - Also, we have to manage larger log files on our production systems. _Too much logging_ is just noise, and makes it harder to figure out what went wrong. This increases the risk that our software is [less transparent in how it works](/tags/Complexity-Risk). diff --git a/docs/thinking/De-Risking.md b/docs/thinking/De-Risking.md index 44f232bf2..5be1c79c5 100644 --- a/docs/thinking/De-Risking.md +++ b/docs/thinking/De-Risking.md @@ -169,7 +169,7 @@ The table above lists a set of _generic strategies_ for derisking which we'll lo ### Specific Tactics -1. **Software as a Service**: [Software-as-a-Service (SaaS)](/tags/Software-Dependency-Risk) is an example of transferring risk, since another party is responsible for making sure the service is up-and-running, backed up, etc. +1. **Software as a Service**: [Software-as-a-Service (SaaS)](/risks/On-Software-Dependencies) is an example of transferring risk, since another party is responsible for making sure the service is up-and-running, backed up, etc. 1. **Employ Good People**: Having staff is a great way to share risk, whether you are a firm or a team. The employee takes care of some of the risk for you. In return, you're paying them a wage which helps them manage their own risks. This is the time-tested, win-win symbiosis of a good trade. @@ -241,7 +241,7 @@ There is a grey area here, because on the one hand you are [retaining](#retain) ## Specific Tactics -1. **Establish Metrics** that allow you to observe the performance of the systems you build. [Map and Territory Risk](/tags/Map-And-Territory-Risk) covers this in more detail. +1. **Establish Metrics** that allow you to observe the performance of the systems you build. [Internal Model Risk](/tags/Internal-Model-Risk) covers this in more detail. 1. **Second opinions** and **audits** correct for errors in monitoring by people who can be too close to the problem. diff --git a/docs/thinking/Evaluating-Risk.md b/docs/thinking/Evaluating-Risk.md index 666a8354f..391217d90 100644 --- a/docs/thinking/Evaluating-Risk.md +++ b/docs/thinking/Evaluating-Risk.md @@ -92,12 +92,12 @@ Enough with the numbers and the theory: we need a practical framework, rather t - First, there isn't enough scientific evidence for an approach like this. We can look at collected data about historic IT projects, but techniques and tools advance rapidly. - Second, IT projects have too many confounding factors, such as experience of the teams, technologies, used, problem domain, clients etc. That is, the risks faced by IT projects are _too diverse_ and _hard to quantify_ to allow for meaningful comparison from one to the next. -- Third, as soon as you _publish a date_ it changes the expectations of the project (see [Student Syndrome](/risks/Staff-Risk#student-syndrome)). -- Fourth, metrics get [misused](/tags/Map-And-Territory-Risk) and [gamed](/tags/Agency-Risk). +- Third, as soon as you _publish a date_ it changes the expectations of the project (see [Student Syndrome](/risks/Schedule-Risk#student-syndrome-and-procrastination)). +- Fourth, metrics get [misused](/tags/Internal-Model-Risk) and [gamed](/tags/Agency-Risk). ## Discounting In A Crisis -Reality is messy. Dressing it up with numbers doesn't change that and you risk [fooling yourself](/tags/Map-And-Territory-Risk). If this is the case, is there any hope at all in what we're doing? Yes: _forget precision_. You should, with experience, be able to hold up two separate risks and answer the question, "is this one bigger than this one?" +Reality is messy. Dressing it up with numbers doesn't change that and you risk [fooling yourself](/tags/Internal-Model-Risk). If this is the case, is there any hope at all in what we're doing? Yes: _forget precision_. You should, with experience, be able to hold up two separate risks and answer the question, "is this one bigger than this one?" Lots of projects start with good intentions. Carefully evaluating the risks of your actions or inaction is great when the going is good. But then when the project is hit with delays everything goes out of the window. diff --git a/docs/thinking/Health.md b/docs/thinking/Health.md index 313318447..40b9fbdeb 100644 --- a/docs/thinking/Health.md +++ b/docs/thinking/Health.md @@ -29,7 +29,7 @@ I am going to argue here that _risks_ affect the health of a thing, where the th - **A Living Organism**, such as the human body, which is exposed to _health risks_, such as [Cardiovascular Disease](https://en.wikipedia.org/wiki/Cardiovascular_disease). - - **A Software Product** is a thing we interact with, built out of code. The health of that software is damaged by the existence of [bugs and missing features](/tags/Feature-Risk). + - **A Software Product** is a thing we interact with, built out of code. The health of that software is damaged by the existence of [bugs and missing features](/tags/Feature-Fit-Risk). - **A Project**, like making a film or organising a [dinner party](A-Simple-Scenario). diff --git a/docs/thinking/Just-Risk.md b/docs/thinking/Just-Risk.md index 642cf4727..a97f706a4 100644 --- a/docs/thinking/Just-Risk.md +++ b/docs/thinking/Just-Risk.md @@ -58,7 +58,7 @@ This _hints_ at the fact that at some level it's all about risk: The reason you are [taking an action](/tags/Take-Action) is to manage a risk. For example: - - If you're coding up new features in the software, this is managing [Feature Risk](/tags/Feature-Risk) (which we'll explore in more detail later). + - If you're coding up new features in the software, this is managing [Feature Fit Risk](/tags/Feature-Fit-Risk) (which we'll explore in more detail later). - If you're getting a business sign-off for something, this is managing the risk of everyone not agreeing on a course of action (a [Coordination Risk](/tags/Coordination-Risk)). - If you're writing a test, then that's managing a type of [Implementation Risk](/tags/Implementation-Risk). diff --git a/docs/thinking/One-Size-Fits-No-One.md b/docs/thinking/One-Size-Fits-No-One.md index 3150ecaa8..b5762477f 100644 --- a/docs/thinking/One-Size-Fits-No-One.md +++ b/docs/thinking/One-Size-Fits-No-One.md @@ -97,7 +97,7 @@ Here are some high-level differences we see in some other popular methodologies: - **[Project Management Body Of Knowledge (PMBoK)](https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge)**. This is a formalisation of traditional project management practice. It prescribes best practices for managing scope, schedule, resources, communications, dependencies, stakeholders etc. on a project. Although "risk" is seen as a separate entity to be managed, all of the above areas are sources of risk within a project. - - **[Scrum](https://en.wikipedia.org/wiki/Scrum)** is a popular Agile methodology. Arguably, it is less "extreme" than Extreme Programming, as it promotes a limited, more achievable set of agile practices, such as frequent releases, daily meetings, a product owner and retrospectives. This simplicity arguably makes it [simpler to learn and adapt to](/tags/Learning-Curve-Risk) and probably contributes to Scrum's popularity over XP. + - **[Scrum](https://en.wikipedia.org/wiki/Scrum)** is a popular Agile methodology. Arguably, it is less "extreme" than Extreme Programming, as it promotes a limited, more achievable set of agile practices, such as frequent releases, daily meetings, a product owner and retrospectives. This simplicity arguably makes it [simpler to learn and adapt to](/tags/Communication-Risk) and probably contributes to Scrum's popularity over XP. - **[DevOps](https://en.wikipedia.org/wiki/DevOps)**. Many software systems struggle at the [boundary](/tags/Lock-In-Risk) between "in development" and "in production". DevOps is an acknowledgement of this, and is about more closely aligning the feedback loops between the developers and the production system. It champions activities such as continuous deployment, automated releases and automated monitoring. diff --git a/docs/thinking/Track-Risk.md b/docs/thinking/Track-Risk.md index 62d97ad73..402ef8855 100644 --- a/docs/thinking/Track-Risk.md +++ b/docs/thinking/Track-Risk.md @@ -111,7 +111,7 @@ _Really good design_ would be coming up with a course of action that takes care ## Criticism -One of the criticisms of the [Risk Register](Track-Risk#risk-registers) approach is that of [mistaking the map for the territory](/tags/Map-And-Territory-Risk). That is, mistakenly believing that what's on the Risk Register _is all there is_. +One of the criticisms of the [Risk Register](Track-Risk#risk-registers) approach is that of [mistaking the map for the territory](/tags/Internal-Model-Risk). That is, mistakenly believing that what's on the Risk Register _is all there is_. In the preceding discussions, I have been careful to point out the existence of [Hidden Risks](/tags/Hidden-Risk) for that very reason. Or, to put another way: diff --git a/src/images/generated/risks/boundary/boundary-risk2.adl b/src/images/generated/risks/boundary/boundary-risk2.adl new file mode 100644 index 000000000..7e7225e8f --- /dev/null +++ b/src/images/generated/risks/boundary/boundary-risk2.adl @@ -0,0 +1,35 @@ + + + + + + + + + + + Extension + (with backward compatibility) + + + + + + + + + \ No newline at end of file diff --git a/src/images/generated/risks/coordination/coordination-risk.adl b/src/images/generated/risks/coordination/coordination-risk.adl index 7aa1369d6..4a86de7f3 100644 --- a/src/images/generated/risks/coordination/coordination-risk.adl +++ b/src/images/generated/risks/coordination/coordination-risk.adl @@ -7,11 +7,9 @@ - Risks that a group of agents cannot work together in a mutually beneficial way, and their behaviour devolves into competition. - + Communication @@ -20,11 +18,11 @@ - diff --git a/src/images/generated/risks/operational/ship-it.adl b/src/images/generated/risks/operational/ship-it.adl index 053f3109c..392074a51 100644 --- a/src/images/generated/risks/operational/ship-it.adl +++ b/src/images/generated/risks/operational/ship-it.adl @@ -14,7 +14,8 @@ @@ -26,7 +27,9 @@ diff --git a/src/images/generated/risks/software-dependency/ergonomics1.adl b/src/images/generated/risks/software-dependency/ergonomics1.adl index 7c9452da9..be868907d 100644 --- a/src/images/generated/risks/software-dependency/ergonomics1.adl +++ b/src/images/generated/risks/software-dependency/ergonomics1.adl @@ -3,17 +3,25 @@ xmlns:xslt="http://www.kite9.org/schema/xslt" xmlns="http://www.kite9.org/schema/adl" xmlns:svg="http://www.w3.org/2000/svg" - xmlns:xlink="http://www.w3.org/1999/xlink" id="diagram-113" + xmlns:xlink="http://www.w3.org/1999/xlink" id="diagram-113" style="--kite9-layout: right; "> + - - - - - Adopt Simple Dependencies - - - + + + + + - \ No newline at end of file + Adopt Simple Dependencies + + + + + + + \ No newline at end of file diff --git a/src/images/generated/risks/software-dependency/ergonomics2.adl b/src/images/generated/risks/software-dependency/ergonomics2.adl index 2e772828c..f4f9c230d 100644 --- a/src/images/generated/risks/software-dependency/ergonomics2.adl +++ b/src/images/generated/risks/software-dependency/ergonomics2.adl @@ -3,17 +3,25 @@ xmlns:xslt="http://www.kite9.org/schema/xslt" xmlns="http://www.kite9.org/schema/adl" xmlns:svg="http://www.w3.org/2000/svg" - xmlns:xlink="http://www.w3.org/1999/xlink" id="diagram-113" + xmlns:xlink="http://www.w3.org/1999/xlink" id="diagram-113" style="--kite9-layout: right; "> - - - - - Adopt Complex Dependency - - - - + + + + + + - \ No newline at end of file + + Adopt Complex Dependency + + + + + + + + \ No newline at end of file diff --git a/static/img/generated/estimating/planner/refactoring.svg b/static/img/generated/estimating/planner/refactoring.svg index bcf759bd8..2c1b486c3 100644 --- a/static/img/generated/estimating/planner/refactoring.svg +++ b/static/img/generated/estimating/planner/refactoring.svg @@ -1445,7 +1445,7 @@ fill-opacity: 1; xlink:type="simple" id="adl:markup" xlink:show="other" - type="text/xml;purpose=adl;base64">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGRpYWdyYW0geG1sbnM9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS9hZGwiCiAgICAgICAgIHhtbG5zOnhzbHQ9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS94c2x0IgogICAgICAgICBpZD0iZGlhIgogICAgICAgICB4c2x0OnRlbXBsYXRlPSIvcHVibGljL3RlbXBsYXRlcy9yaXNrLWZpcnN0L3Jpc2stZmlyc3QtdGVtcGxhdGUueHNsIj4KICAgPGdyb3VwIGlkPSI0IiBzdHlsZT0iLS1raXRlOS1sYXlvdXQ6IGRvd247ICI+CiAgICAgIDxtaXRpZ2F0ZWQgaWQ9IjM3Ij4KICAgICAgICAgPHJpc2sgaHJlZj0iL3B1YmxpYy90ZW1wbGF0ZXMvcmlzay1maXJzdC9yZWRlc2lnbi9yaXNrcy9jb21tdW5pY2F0aW9uX3Jpc2tfdjIuc3ZnIgogICAgICAgICAgICAgICBpZD0iY29tbXVuaWNhdGlvbiI+CiAgICAgICAgICAgIDxjb2RlIGlkPSJjb2RlIj5DbzwvY29kZT4KICAgICAgICAgICAgPHRpdGxlIGlkPSJ0aXRsZSI+Q29tbXVuaWNhdGlvbiBSaXNrPC90aXRsZT4KICAgICAgICAgPC9yaXNrPgogICAgICA8L21pdGlnYXRlZD4KICAgICAgPGRlc2NyaXB0aW9uIGlkPSI0LTEiIHN0eWxlPSJ0ZXh0LWFsaWduOiBjZW50ZXI7ICI+NTAlIE9mIFVzZXJzIERvbid0CgkJCQlDb21wbGV0ZSBUaGUgUHJlbWl1bS1UaWVyCgkJCQlVcGdyYWRlCgkJCTwvZGVzY3JpcHRpb24+CiAgIDwvZ3JvdXA+CiAgIDxncm91cCBpZD0iOCI+CiAgICAgIDxhY3Rpb24gaWQ9IjMiPlJlZmFjdG9yCgkJCQlTdWJzY3JpcHRpb25zPC9hY3Rpb24+CiAgIDwvZ3JvdXA+CiAgIDxncm91cCBpZD0iOSI+CiAgICAgIDxyaXNrIGNsYXNzPSJnZW5lcmljIgogICAgICAgICAgICBocmVmPSIvcHVibGljL3RlbXBsYXRlcy9yaXNrLWZpcnN0L3JlZGVzaWduL3Jpc2tzL2dvYWxfdjIuc3ZnIgogICAgICAgICAgICBpZD0iMiI+CiAgICAgICAgIDxjb2RlIGlkPSJjbzIiPkdvYWw8L2NvZGU+CiAgICAgICAgIDx0aXRsZSBpZD0idGl0bGUyIj41MEsgU3Vic2NyaWJlcnMgQnkgUTQ8L3RpdGxlPgogICAgICA8L3Jpc2s+CiAgIDwvZ3JvdXA+CiAgIDxhbGlnbiBpZD0iNS0wIiBzdHlsZT0iLS1raXRlOS1kaXJlY3Rpb246IHJpZ2h0OyI+CiAgICAgIDxmcm9tIGlkPSI1LTAtMCIgcmVmZXJlbmNlPSJjb21tdW5pY2F0aW9uIi8+CiAgICAgIDx0byBpZD0iNS0wLTEiIHJlZmVyZW5jZT0iMyIvPgogICA8L2FsaWduPgogICA8YWxpZ24gaWQ9IjUtMSIgc3R5bGU9Ii0ta2l0ZTktZGlyZWN0aW9uOiByaWdodDsiPgogICAgICA8ZnJvbSBpZD0iNS0xLTAiIHJlZmVyZW5jZT0iMyIvPgogICAgICA8dG8gaWQ9IjUtMS0xIiByZWZlcmVuY2U9IjIiLz4KICAgPC9hbGlnbj4KPC9kaWFncmFtPgo= + type="text/xml;purpose=adl;base64">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGRpYWdyYW0geG1sbnM9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS9hZGwiCiAgICAgICAgIHhtbG5zOnhzbHQ9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS94c2x0IgogICAgICAgICBpZD0iZGlhIgogICAgICAgICB4c2x0OnRlbXBsYXRlPSIvcHVibGljL3RlbXBsYXRlcy9yaXNrLWZpcnN0L3Jpc2stZmlyc3QtdGVtcGxhdGUueHNsIj4KICAgPGdyb3VwIGlkPSI0IiBzdHlsZT0iLS1raXRlOS1sYXlvdXQ6IGRvd247ICI+CiAgICAgIDxtaXRpZ2F0ZWQgaWQ9IjM3Ij4KICAgICAgICAgPHJpc2sgY2xhc3M9ImNvbW11bmljYXRpb24iIGlkPSJjb21tdW5pY2F0aW9uIi8+CiAgICAgIDwvbWl0aWdhdGVkPgogICAgICA8ZGVzY3JpcHRpb24gaWQ9IjQtMSIgc3R5bGU9InRleHQtYWxpZ246IGNlbnRlcjsgIj41MCUgT2YgVXNlcnMgRG9uJ3QKCQkJCUNvbXBsZXRlIFRoZSBQcmVtaXVtLVRpZXIKCQkJCVVwZ3JhZGUKCQkJPC9kZXNjcmlwdGlvbj4KICAgPC9ncm91cD4KICAgPGdyb3VwIGlkPSI4Ij4KICAgICAgPGFjdGlvbiBpZD0iMyI+UmVmYWN0b3IKCQkJCVN1YnNjcmlwdGlvbnM8L2FjdGlvbj4KICAgPC9ncm91cD4KICAgPGdyb3VwIGlkPSI5Ij4KICAgICAgPHJpc2sgY2xhc3M9ImdvYWwiPjUwSyBTdWJzY3JpYmVycyBCeSBRNAogICAgICA8L3Jpc2s+CiAgIDwvZ3JvdXA+CjwvZGlhZ3JhbT4K - @@ -1535,14 +1535,11 @@ fill-opacity: 1; pp:width="$width"/> - + k9-info="margin: [0.0 0.0 13.333333969116211 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [166.0, 52.0]; rect-size: [35.0, 35.0]; position: none; painter: direct-svg; "> @@ -1552,16 +1549,12 @@ fill-opacity: 1; - - + transform="translate(63.7,61.7)" + k9-format="image-fixed" + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [150.0, 100.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + - @@ -1607,7 +1600,7 @@ fill-opacity: 1; + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [396.0, 178.0]; rect-size: [137.0, 51.0]; position: none; painter: direct-svg; "> @@ -1712,9 +1705,9 @@ fill-opacity: 1; - + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; min-size: [193.33334350585938 226.6666717529297]; sizing: [minimize minimize]; horiz: center; vert: center; layout: down; rectangular: connected; rect-pos: [614.0, 91.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> - + k9-info="margin: [0.0 0.0 13.333333969116211 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [681.0, 104.0]; rect-size: [60.0, 35.0]; position: none; painter: direct-svg; "> @@ -1773,17 +1759,12 @@ fill-opacity: 1; - - + transform="translate(63.7,61.7)" + k9-format="image-fixed" + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [677.0, 152.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/static/img/generated/risks/boundary/Boundary-Risk2.svg b/static/img/generated/risks/boundary/Boundary-Risk2.svg new file mode 100644 index 000000000..b4b00ee90 --- /dev/null +++ b/static/img/generated/risks/boundary/Boundary-Risk2.svg @@ -0,0 +1,2061 @@ + + + + http://robs-pro:8080/api/renderer?format=svg + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/static/img/generated/risks/coordination/coordination-risk.svg b/static/img/generated/risks/coordination/coordination-risk.svg index 4b4f77795..e58ecf61a 100644 --- a/static/img/generated/risks/coordination/coordination-risk.svg +++ b/static/img/generated/risks/coordination/coordination-risk.svg @@ -8,10 +8,10 @@ zoomAndPan="magnify" contentStyleType="text/css" version="1.0" - width="1557" + width="1569" pp:width="$width" preserveAspectRatio="xMidYMid meet" - height="504" + height="401" pp:height="$height"> http://robs-pro:8080/api/renderer?format=svg @@ -1445,13 +1445,13 @@ fill-opacity: 1; xlink:type="simple" id="adl:markup" xlink:show="other" - type="text/xml;purpose=adl;base64">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGRpYWdyYW0geG1sbnM9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS9hZGwiCiAgICAgICAgIHhtbG5zOnhzbHQ9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS94c2x0IgogICAgICAgICBpZD0iZGlhIgogICAgICAgICBzdHlsZT0iLS1raXRlOS1taW4td2lkdGg6IDgwMHB0OyIKICAgICAgICAgeHNsdDp0ZW1wbGF0ZT0iL3B1YmxpYy90ZW1wbGF0ZXMvcmlzay1maXJzdC9yaXNrLWZpcnN0LXRlbXBsYXRlLnhzbCI+CiAgIDxjb250YWluZXIgYm9yZGVyZWQ9InRydWUiIGlkPSJjIiBzdHlsZT0iLS1raXRlOS1sYXlvdXQ6IGRvd247ICI+CiAgICAgIDxtaXRpZ2F0ZWQ+CiAgICAgICAgIDxyaXNrIGNsYXNzPSJjb29yZGluYXRpb24iLz4KICAgICAgPC9taXRpZ2F0ZWQ+CiAgICAgIDxkZXNjcmlwdGlvbj5SaXNrcyB0aGF0IGEgZ3JvdXAgb2YgYWdlbnRzIGNhbm5vdCB3b3JrIHRvZ2V0aGVyIGluIGEgbXV0dWFsbHkgYmVuZWZpY2lhbCB3YXksIGFuZCB0aGVpciBiZWhhdmlvdXIgZGV2b2x2ZXMgaW50byBjb21wZXRpdGlvbi48L2Rlc2NyaXB0aW9uPgogICAgICA8bGFiZWwgaWQ9ImlkXzE2Ij4KICAgICAgICAgICAgSW50ZXJuYWwgTW9kZWwKICAgICAgICAgICAgPHN5bWJvbHMvPgogICAgICA8L2xhYmVsPgogICA8L2NvbnRhaW5lcj4KICAgPGdyb3VwIHN0eWxlPSItLWtpdGU5LWxheW91dDogZG93bjsgLS1raXRlOS1ob3Jpem9udGFsLWFsaWduOiBsZWZ0OyI+CiAgICAgIDxhY3Rpb24+Q29tbXVuaWNhdGlvbjwvYWN0aW9uPgogICAgICA8YWN0aW9uPlJ1bGVzICZhbXA7IFByb3RvY29sczwvYWN0aW9uPgogICAgICA8YWN0aW9uPk9yZ2FuaXNhdGlvbjwvYWN0aW9uPgogICA8L2dyb3VwPgogICA8Y29udGFpbmVyIGlkPSJkIj4KICAgICAgPHJpc2sgY2xhc3M9ImNvbW11bmljYXRpb24iLz4KICAgICAgPHJpc2sgY2xhc3M9ImludmlzaWJpbGl0eSIvPgogICAgICA8cmlzayBjbGFzcz0iYWdlbmN5Ii8+CiAgICAgIDxyaXNrIGNsYXNzPSJzY2hlZHVsZSIvPgogICAgICA8bGFiZWwgaWQ9ImlkXzE2LXJmIj4KICAgICAgICAgICAgQXR0ZW5kYW50IFJpc2tzCiAgICAgICAgICAgIDxzeW1ib2xzLz4KICAgICAgPC9sYWJlbD4KICAgPC9jb250YWluZXI+CjwvZGlhZ3JhbT4K + type="text/xml;purpose=adl;base64">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGRpYWdyYW0geG1sbnM9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS9hZGwiCiAgICAgICAgIHhtbG5zOnhzbHQ9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS94c2x0IgogICAgICAgICBpZD0iZGlhIgogICAgICAgICBzdHlsZT0iLS1raXRlOS1taW4td2lkdGg6IDgwMHB0OyIKICAgICAgICAgeHNsdDp0ZW1wbGF0ZT0iL3B1YmxpYy90ZW1wbGF0ZXMvcmlzay1maXJzdC9yaXNrLWZpcnN0LXRlbXBsYXRlLnhzbCI+CiAgIDxjb250YWluZXIgYm9yZGVyZWQ9InRydWUiIGlkPSJjIiBzdHlsZT0iLS1raXRlOS1sYXlvdXQ6IGRvd247ICI+CiAgICAgIDxtaXRpZ2F0ZWQ+CiAgICAgICAgIDxyaXNrIGNsYXNzPSJjb29yZGluYXRpb24iLz4KICAgICAgPC9taXRpZ2F0ZWQ+CiAgICAgIDxsYWJlbD5SaXNrcyB0aGF0IGEgZ3JvdXAgb2YgYWdlbnRzIGNhbm5vdCB3b3JrIHRvZ2V0aGVyIAogICAgICAgICBpbiBhIG11dHVhbGx5IGJlbmVmaWNpYWwgd2F5LCBhbmQgdGhlaXIgCiAgICAgICAgIGJlaGF2aW91ciBkZXZvbHZlcyBpbnRvIGNvbXBldGl0aW9uLjwvbGFiZWw+CiAgIDwvY29udGFpbmVyPgogICA8Z3JvdXAgc3R5bGU9Ii0ta2l0ZTktbGF5b3V0OiBkb3duOyAtLWtpdGU5LWhvcml6b250YWwtYWxpZ246IGxlZnQ7Ij4KICAgICAgPGFjdGlvbj5Db21tdW5pY2F0aW9uPC9hY3Rpb24+CiAgICAgIDxhY3Rpb24+UnVsZXMgJmFtcDsgUHJvdG9jb2xzPC9hY3Rpb24+CiAgICAgIDxhY3Rpb24+T3JnYW5pc2F0aW9uPC9hY3Rpb24+CiAgIDwvZ3JvdXA+CiAgIDxjb250YWluZXIgaWQ9ImQiPgogICAgICA8cmlzayBjbGFzcz0iY29tbXVuaWNhdGlvbiIvPgogICAgICA8cmlzayBjbGFzcz0iYWdlbmN5Ii8+CiAgICAgIDxyaXNrIGNsYXNzPSJzY2hlZHVsZSIvPgogICAgICA8bGFiZWwgaWQ9ImlkXzE2LXJmIj4KICAgICAgICAgICAgQ29vcmRpbmF0aW9uIGhhcyBpdCdzIG93biByaXNrcyBvbmNlIHlvdSAKICAgICAgICAgICAgYXR0ZW1wdCB0byBkbyBpdC4KICAgICAgICAgICAgPHN5bWJvbHMvPgogICAgICA8L2xhYmVsPgogICA8L2NvbnRhaW5lcj4KPC9kaWFncmFtPgo= @@ -1475,7 +1475,7 @@ fill-opacity: 1; transform="translate(20.0,20.0)" k9-texture="background" style="--kite9-layout: down; " - k9-info="margin: [20.0 20.0 20.0 20.0]; padding: [20.0 20.0 20.0 20.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; layout: down; rectangular: connected; rect-pos: [20.0, 20.0]; rect-size: [366.0, 464.0]; position: none; painter: direct-svg; " + k9-info="margin: [20.0 20.0 20.0 20.0]; padding: [20.0 20.0 20.0 20.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; layout: down; rectangular: connected; rect-pos: [20.0, 20.0]; rect-size: [584.0, 361.0]; position: none; painter: direct-svg; " bordered="true" id="c" k9-format="container" @@ -1485,21 +1485,21 @@ fill-opacity: 1; + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [0.0 0.0 0.0 0.0]; min-size: [160.0 213.33334350585938]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [216.0, 40.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; min-size: [193.33334350585938 226.6666717529297]; sizing: [minimize minimize]; horiz: center; vert: center; layout: down; rectangular: connected; rect-pos: [216.0, 40.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 13.333333969116211 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [298.0, 53.0]; rect-size: [29.0, 35.0]; position: none; painter: direct-svg; "> @@ -1549,7 +1549,7 @@ fill-opacity: 1; k9-texture="none" transform="translate(63.7,61.7)" k9-format="image-fixed" - k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [170.0, 101.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [279.0, 101.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: label; rect-pos: [40.0, 279.0]; rect-size: [544.0, 102.0]; position: none; placement: down;painter: direct-svg; "> @@ -1668,11 +1626,23 @@ fill-opacity: 1; k9-texture="foreground" transform="translate(11.4,34.3)" k9-format="text-fixed" - k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [132.0, 446.0]; rect-size: [143.0, 25.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [53.0, 292.0]; rect-size: [518.0, 76.0]; position: none; painter: direct-svg; "> - + + + + + + + + + + @@ -1685,9 +1655,9 @@ fill-opacity: 1; + k9-info="margin: [26.666667938232422 26.666667938232422 26.666667938232422 26.666667938232422]; padding: [0.0 0.0 0.0 0.0]; min-size: [53.333335876464844 53.333335876464844]; sizing: [minimize minimize]; horiz: left; vert: center; layout: down; rectangular: connected; rect-pos: [630.0, 89.0]; rect-size: [248.0, 223.0]; position: none; painter: direct-svg; "> + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [16.0 29.33333396911621 16.0 16.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [653.0, 102.0]; rect-size: [203.0, 57.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [669.0, 118.0]; rect-size: [158.0, 25.0]; position: none; painter: direct-svg; "> @@ -1736,7 +1706,7 @@ fill-opacity: 1; k9-texture="background" transform="translate(13.0,83.0)" k9-format="text-shape-inline" - k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [16.0 29.33333396911621 16.0 16.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [425.0, 224.0]; rect-size: [222.0, 57.0]; position: none; painter: direct-svg; "> + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [16.0 29.33333396911621 16.0 16.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [643.0, 172.0]; rect-size: [222.0, 57.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [659.0, 188.0]; rect-size: [177.0, 25.0]; position: none; painter: direct-svg; "> @@ -1767,7 +1737,7 @@ fill-opacity: 1; k9-texture="background" transform="translate(37.0,153.0)" k9-format="text-shape-inline" - k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [16.0 29.33333396911621 16.0 16.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [449.0, 294.0]; rect-size: [174.0, 57.0]; position: none; painter: direct-svg; "> + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [16.0 29.33333396911621 16.0 16.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [667.0, 242.0]; rect-size: [174.0, 57.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [683.0, 258.0]; rect-size: [129.0, 25.0]; position: none; painter: direct-svg; "> @@ -1797,9 +1767,9 @@ fill-opacity: 1; @@ -1823,7 +1793,7 @@ fill-opacity: 1; class="communication" transform="translate(20.0,20.0)" k9-format="container" - k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; min-size: [193.33334350585938 226.6666717529297]; sizing: [minimize minimize]; horiz: center; vert: center; layout: down; rectangular: connected; rect-pos: [706.0, 117.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; min-size: [193.33334350585938 226.6666717529297]; sizing: [minimize minimize]; horiz: center; vert: center; layout: down; rectangular: connected; rect-pos: [924.0, 53.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 13.333333969116211 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [1003.0, 66.0]; rect-size: [35.0, 35.0]; position: none; painter: direct-svg; "> @@ -1855,7 +1825,7 @@ fill-opacity: 1; k9-texture="none" transform="translate(63.7,61.7)" k9-format="image-fixed" - k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [769.0, 178.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [987.0, 114.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; min-size: [193.33334350585938 226.6666717529297]; sizing: [minimize minimize]; horiz: center; vert: center; layout: down; rectangular: connected; rect-pos: [1130.0, 53.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 13.333333969116211 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [1217.0, 66.0]; rect-size: [20.0, 35.0]; position: none; painter: direct-svg; "> @@ -2017,7 +1906,7 @@ fill-opacity: 1; k9-texture="none" transform="translate(63.7,61.7)" k9-format="image-fixed" - k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [1181.0, 178.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [1193.0, 114.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; min-size: [193.33334350585938 226.6666717529297]; sizing: [minimize minimize]; horiz: center; vert: center; layout: down; rectangular: connected; rect-pos: [1336.0, 53.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 13.333333969116211 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [1401.0, 66.0]; rect-size: [64.0, 35.0]; position: none; painter: direct-svg; "> @@ -2098,7 +1987,7 @@ fill-opacity: 1; k9-texture="none" transform="translate(63.7,61.7)" k9-format="image-fixed" - k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [1387.0, 178.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [1399.0, 114.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [1021.0, 305.0]; rect-size: [412.0, 51.0]; position: none; painter: direct-svg; "> - + + + + + diff --git a/static/img/generated/risks/operational/ship-it.svg b/static/img/generated/risks/operational/ship-it.svg index b3a463253..c0c6e6178 100644 --- a/static/img/generated/risks/operational/ship-it.svg +++ b/static/img/generated/risks/operational/ship-it.svg @@ -11,7 +11,7 @@ width="1535" pp:width="$width" preserveAspectRatio="xMidYMid meet" - height="350" + height="401" pp:height="$height"> http://robs-pro:8080/api/renderer?format=svg @@ -1445,13 +1445,13 @@ fill-opacity: 1; xlink:type="simple" id="adl:markup" xlink:show="other" - type="text/xml;purpose=adl;base64">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGRpYWdyYW0geG1sbnM9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS9hZGwiCiAgICAgICAgIHhtbG5zOnhzbHQ9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS94c2x0IgogICAgICAgICBpZD0iZGlhIgogICAgICAgICBzdHlsZT0iLS1raXRlOS1taW4td2lkdGg6IDgwMHB0OyIKICAgICAgICAgeHNsdDp0ZW1wbGF0ZT0iL3B1YmxpYy90ZW1wbGF0ZXMvcmlzay1maXJzdC9yaXNrLWZpcnN0LXRlbXBsYXRlLnhzbCI+CiAgIDxjb250YWluZXIgYm9yZGVyZWQ9InRydWUiIGlkPSJjIiBzdHlsZT0iLS1raXRlOS1sYXlvdXQ6IHJpZ2h0OyAiPgogICAgICA8bWl0aWdhdGVkPgogICAgICAgICA8cmlzayBjbGFzcz0ic2NoZWR1bGUiLz4KICAgICAgPC9taXRpZ2F0ZWQ+CiAgICAgIDxtaXRpZ2F0ZWQ+CiAgICAgICAgIDxyaXNrIGNsYXNzPSJmdW5kaW5nIi8+CiAgICAgIDwvbWl0aWdhdGVkPgogICAgICA8bWl0aWdhdGVkPgogICAgICAgICA8cmlzayBjbGFzcz0ibWFya2V0Ii8+CiAgICAgIDwvbWl0aWdhdGVkPgogICAgICA8bGFiZWwgaWQ9ImlkXzE2Ij4KICAgICAgICAgICAgSW50ZXJuYWwgTW9kZWwKICAgICAgICAgICAgPHN5bWJvbHMvPgogICAgICA8L2xhYmVsPgogICA8L2NvbnRhaW5lcj4KICAgPGdyb3VwIHN0eWxlPSItLWtpdGU5LWxheW91dDogZG93bjsgLS1raXRlOS1ob3Jpem9udGFsLWFsaWduOiBsZWZ0OyI+CiAgICAgIDxhY3Rpb24+RGVsaXZlcnk8L2FjdGlvbj4KICAgPC9ncm91cD4KICAgPGNvbnRhaW5lciBpZD0iZCI+CiAgICAgIDxyaXNrIGNsYXNzPSJ0cnVzdCIvPgogICAgICA8cmlzayBjbGFzcz0iZmVhdHVyZS1maXQiLz4KICAgICAgPHJpc2sgY2xhc3M9Im9wZXJhdGlvbmFsIi8+CiAgICAgIDxsYWJlbCBpZD0iaWRfMTYtamQiPgogICAgICAgICAgICBBdHRlbmRhbnQgUmlza3MKICAgICAgICAgICAgPHN5bWJvbHMvPgogICAgICA8L2xhYmVsPgogICA8L2NvbnRhaW5lcj4KPC9kaWFncmFtPgo= + type="text/xml;purpose=adl;base64">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGRpYWdyYW0geG1sbnM9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS9hZGwiCiAgICAgICAgIHhtbG5zOnhzbHQ9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS94c2x0IgogICAgICAgICBpZD0iZGlhIgogICAgICAgICBzdHlsZT0iLS1raXRlOS1taW4td2lkdGg6IDgwMHB0OyIKICAgICAgICAgeHNsdDp0ZW1wbGF0ZT0iL3B1YmxpYy90ZW1wbGF0ZXMvcmlzay1maXJzdC9yaXNrLWZpcnN0LXRlbXBsYXRlLnhzbCI+CiAgIDxjb250YWluZXIgYm9yZGVyZWQ9InRydWUiIGlkPSJjIiBzdHlsZT0iLS1raXRlOS1sYXlvdXQ6IHJpZ2h0OyAiPgogICAgICA8bWl0aWdhdGVkPgogICAgICAgICA8cmlzayBjbGFzcz0ic2NoZWR1bGUiLz4KICAgICAgPC9taXRpZ2F0ZWQ+CiAgICAgIDxtaXRpZ2F0ZWQ+CiAgICAgICAgIDxyaXNrIGNsYXNzPSJmdW5kaW5nIi8+CiAgICAgIDwvbWl0aWdhdGVkPgogICAgICA8bWl0aWdhdGVkPgogICAgICAgICA8cmlzayBjbGFzcz0ibWFya2V0Ii8+CiAgICAgIDwvbWl0aWdhdGVkPgogICAgICA8bGFiZWwgaWQ9ImlkXzE2Ij4KICAgICAgICAgICAgU2hpcHBpbmcgaW5jb21wbGV0ZSBzb2Z0d2FyZSBtaWdodCAKICAgICAgICAgICAgcmVkdWNlIGEgbG90IG9mIHJpc2tzLi4uCiAgICAgICAgICAgIDxzeW1ib2xzLz4KICAgICAgPC9sYWJlbD4KICAgPC9jb250YWluZXI+CiAgIDxncm91cCBzdHlsZT0iLS1raXRlOS1sYXlvdXQ6IGRvd247IC0ta2l0ZTktaG9yaXpvbnRhbC1hbGlnbjogbGVmdDsiPgogICAgICA8YWN0aW9uPkRlbGl2ZXJ5PC9hY3Rpb24+CiAgIDwvZ3JvdXA+CiAgIDxjb250YWluZXIgaWQ9ImQiPgogICAgICA8cmlzayBjbGFzcz0idHJ1c3QiLz4KICAgICAgPHJpc2sgY2xhc3M9ImZlYXR1cmUtZml0Ii8+CiAgICAgIDxyaXNrIGNsYXNzPSJvcGVyYXRpb25hbCIvPgogICAgICA8bGFiZWwgaWQ9ImlkXzE2LWpkIj4KICAgICAgICAgICBCdXQgdGhlIGRhbmdlciBpcyB5b3UgbWlnaHQgaGFybSB5b3VyIAogICAgICAgICAgIHJlcHV0YXRpb24gaW4gdGhlIHByb2Nlc3MsIGFzIHdlbGwgYXMgbmVlZCAKICAgICAgICAgICB0byBzdXBwb3J0IGEgYnJva2VuIHN5c3RlbS4KICAgICAgICAgICAgPHN5bWJvbHMvPgogICAgICA8L2xhYmVsPgogICA8L2NvbnRhaW5lcj4KPC9kaWFncmFtPgo= @@ -1499,7 +1499,7 @@ fill-opacity: 1; k9-texture="none" transform="translate(20.0,20.0)" k9-format="container" - k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [0.0 0.0 0.0 0.0]; min-size: [160.0 213.33334350585938]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [40.0, 40.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [0.0 0.0 0.0 0.0]; min-size: [160.0 213.33334350585938]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [40.0, 53.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; min-size: [193.33334350585938 226.6666717529297]; sizing: [minimize minimize]; horiz: center; vert: center; layout: down; rectangular: connected; rect-pos: [40.0, 53.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 13.333333969116211 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [105.0, 66.0]; rect-size: [64.0, 35.0]; position: none; painter: direct-svg; "> @@ -1549,7 +1549,7 @@ fill-opacity: 1; k9-texture="none" transform="translate(63.7,61.7)" k9-format="image-fixed" - k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [103.0, 101.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [103.0, 114.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [0.0 0.0 0.0 0.0]; min-size: [160.0 213.33334350585938]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [246.0, 53.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; min-size: [193.33334350585938 226.6666717529297]; sizing: [minimize minimize]; horiz: center; vert: center; layout: down; rectangular: connected; rect-pos: [246.0, 53.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 13.333333969116211 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [311.0, 66.0]; rect-size: [64.0, 35.0]; position: none; painter: direct-svg; "> @@ -1658,7 +1658,7 @@ fill-opacity: 1; k9-texture="none" transform="translate(63.7,61.7)" k9-format="image-fixed" - k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [309.0, 101.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [309.0, 114.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [0.0 0.0 0.0 0.0]; min-size: [160.0 213.33334350585938]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [452.0, 53.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; min-size: [193.33334350585938 226.6666717529297]; sizing: [minimize minimize]; horiz: center; vert: center; layout: down; rectangular: connected; rect-pos: [452.0, 53.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 13.333333969116211 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [516.0, 66.0]; rect-size: [66.0, 35.0]; position: none; painter: direct-svg; "> @@ -1767,7 +1767,7 @@ fill-opacity: 1; k9-texture="none" transform="translate(63.7,61.7)" k9-format="image-fixed" - k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [515.0, 101.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: top; rectangular: connected; rect-pos: [515.0, 114.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [157.0, 305.0]; rect-size: [371.0, 51.0]; position: none; painter: direct-svg; "> - + + + + + @@ -1865,9 +1871,9 @@ fill-opacity: 1; + k9-info="margin: [26.666667938232422 26.666667938232422 26.666667938232422 26.666667938232422]; padding: [0.0 0.0 0.0 0.0]; min-size: [53.333335876464844 53.333335876464844]; sizing: [minimize minimize]; horiz: left; vert: center; layout: down; rectangular: connected; rect-pos: [691.0, 159.0]; rect-size: [153.0, 83.0]; position: none; painter: direct-svg; "> + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [16.0 29.33333396911621 16.0 16.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [704.0, 172.0]; rect-size: [127.0, 57.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [720.0, 188.0]; rect-size: [82.0, 25.0]; position: none; painter: direct-svg; "> @@ -1917,7 +1923,7 @@ fill-opacity: 1; @@ -2165,7 +2171,7 @@ fill-opacity: 1; - @@ -2180,9 +2186,9 @@ fill-opacity: 1; + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [981.0, 292.0]; rect-size: [423.0, 76.0]; position: none; painter: direct-svg; "> - + + + + + + + + + + diff --git a/static/img/generated/risks/software-dependency/ergonomics1.svg b/static/img/generated/risks/software-dependency/ergonomics1.svg index 4cc9cc434..3ddea0a3c 100644 --- a/static/img/generated/risks/software-dependency/ergonomics1.svg +++ b/static/img/generated/risks/software-dependency/ergonomics1.svg @@ -8,10 +8,10 @@ zoomAndPan="magnify" contentStyleType="text/css" version="1.0" - width="981" + width="1209" pp:width="$width" preserveAspectRatio="xMidYMid meet" - height="252" + height="615" pp:height="$height"> http://robs-pro:8080/api/renderer?format=svg @@ -1445,13 +1445,13 @@ fill-opacity: 1; xlink:type="simple" id="adl:markup" xlink:show="other" - type="text/xml;purpose=adl;base64">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGRpYWdyYW0geG1sbnM9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS9hZGwiCiAgICAgICAgIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciCiAgICAgICAgIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIgogICAgICAgICB4bWxuczp4c2x0PSJodHRwOi8vd3d3LmtpdGU5Lm9yZy9zY2hlbWEveHNsdCIKICAgICAgICAgaWQ9ImRpYWdyYW0tMTEzIgogICAgICAgICBzdHlsZT0iLS1raXRlOS1sYXlvdXQ6IHJpZ2h0OyAiCiAgICAgICAgIHhzbHQ6dGVtcGxhdGU9Ii9wdWJsaWMvdGVtcGxhdGVzL3Jpc2stZmlyc3Qvcmlzay1maXJzdC10ZW1wbGF0ZS54c2wiPgogICA8bWl0aWdhdGVkPgogICAgICA8cmlzayBjbGFzcz0iZmVhdHVyZSIvPgogICA8L21pdGlnYXRlZD4KICAgPGFjdGlvbj5BZG9wdCBTaW1wbGUgRGVwZW5kZW5jaWVzPC9hY3Rpb24+CiAgIDxyaXNrIGNsYXNzPSJjb21wbGV4aXR5Ii8+CiAgIDxyaXNrIGNsYXNzPSJmZWF0dXJlLWZpdCIvPgo8L2RpYWdyYW0+Cg== + type="text/xml;purpose=adl;base64">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGRpYWdyYW0geG1sbnM9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS9hZGwiCiAgICAgICAgIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciCiAgICAgICAgIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIgogICAgICAgICB4bWxuczp4c2x0PSJodHRwOi8vd3d3LmtpdGU5Lm9yZy9zY2hlbWEveHNsdCIKICAgICAgICAgaWQ9ImRpYWdyYW0tMTEzIgogICAgICAgICBzdHlsZT0iLS1raXRlOS1sYXlvdXQ6IHJpZ2h0OyAiCiAgICAgICAgIHhzbHQ6dGVtcGxhdGU9Ii9wdWJsaWMvdGVtcGxhdGVzL3Jpc2stZmlyc3Qvcmlzay1maXJzdC10ZW1wbGF0ZS54c2wiPgogICA8Y29udGFpbmVyIGJvcmRlcmVkPSJ0cnVlIiBpZD0iYyIgc3R5bGU9Ii0ta2l0ZTktbGF5b3V0OiBkb3duOyAiPgogICAgICA8bWl0aWdhdGVkPgogICAgICAgICA8cmlzayBjbGFzcz0iZmVhdHVyZS1maXQiLz4KICAgICAgPC9taXRpZ2F0ZWQ+CiAgICAgIDxsYWJlbD5DbGllbnRzIG5lZWQgZmVhdHVyZXMuLi48L2xhYmVsPgogICA8L2NvbnRhaW5lcj4KICAgPGFjdGlvbj5BZG9wdCBTaW1wbGUgRGVwZW5kZW5jaWVzPC9hY3Rpb24+CiAgIDxjb250YWluZXIgYm9yZGVyZWQ9InRydWUiIGlkPSJjIiBzdHlsZT0iLS1raXRlOS1sYXlvdXQ6IGRvd247ICI+CiAgICAgIDxyaXNrIGNsYXNzPSJjb21wbGV4aXR5Ii8+CiAgICAgIDxyaXNrIGNsYXNzPSJkZXBlbmRlbmN5Ii8+CiAgICAgIDxsYWJlbD5TdXBwb3J0aW5nIHRoZXNlIHZpYSBkZXBlbmRlbmNpZXMgbWlnaHQKCQlhY2NydWUgc29tZSBuZXcgcmlza3MuPC9sYWJlbD4KICAgPC9jb250YWluZXI+CjwvZGlhZ3JhbT4K - + k9-ui="drag delete align connect insert autoconnect layout label fill stroke size align" + k9-elem="container" + k9-type="connected"> - + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [0.0 0.0 0.0 0.0]; min-size: [160.0 213.33334350585938]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [73.0, 173.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> - - - - - - - - - - - - + + + width="193" + pp:y="$y" + pp:height="$height" + pp:x="$x" + rx="5pt" + ry="5pt" + height="226" + pp:width="$width"/> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + + + + + + + + + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [53.0, 425.0]; rect-size: [232.0, 25.0]; position: none; painter: direct-svg; "> - - - - - - - + @@ -1570,21 +1639,12 @@ fill-opacity: 1; - + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [16.0 29.33333396911621 16.0 16.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [338.0, 280.0]; rect-size: [337.0, 57.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [354.0, 296.0]; rect-size: [292.0, 25.0]; position: none; painter: direct-svg; "> - @@ -1611,162 +1671,228 @@ fill-opacity: 1; - + k9-ui="drag delete align connect insert autoconnect layout label fill stroke size align" + k9-elem="container" + k9-type="connected"> - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - + + + width="193" + pp:y="$y" + pp:height="$height" + pp:x="$x" + rx="5pt" + ry="5pt" + height="226" + pp:width="$width"/> - - - - - - + + + + + + + + - - - + + + + - - - - - - - - - - - - - - + + + + + + + + + + + + - - - + transform="translate(20.0,498.0)" + k9-format="text-shape-inline" + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: label; rect-pos: [715.0, 518.0]; rect-size: [454.0, 77.0]; position: none; placement: down;painter: direct-svg; "> + + width="454" + pp:y="$y" + pp:height="$height" + pp:x="$x" + rx="5pt" + ry="5pt" + height="77" + pp:width="$width"/> - - - - - - - - - - - + + + + + + + + + + + + + diff --git a/static/img/generated/risks/software-dependency/ergonomics2.svg b/static/img/generated/risks/software-dependency/ergonomics2.svg index d59211246..74516d834 100644 --- a/static/img/generated/risks/software-dependency/ergonomics2.svg +++ b/static/img/generated/risks/software-dependency/ergonomics2.svg @@ -8,10 +8,10 @@ zoomAndPan="magnify" contentStyleType="text/css" version="1.0" - width="1193" + width="954" pp:width="$width" preserveAspectRatio="xMidYMid meet" - height="252" + height="784" pp:height="$height"> http://robs-pro:8080/api/renderer?format=svg @@ -1445,13 +1445,13 @@ fill-opacity: 1; xlink:type="simple" id="adl:markup" xlink:show="other" - type="text/xml;purpose=adl;base64">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGRpYWdyYW0geG1sbnM9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS9hZGwiCiAgICAgICAgIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciCiAgICAgICAgIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIgogICAgICAgICB4bWxuczp4c2x0PSJodHRwOi8vd3d3LmtpdGU5Lm9yZy9zY2hlbWEveHNsdCIKICAgICAgICAgaWQ9ImRpYWdyYW0tMTEzIgogICAgICAgICBzdHlsZT0iLS1raXRlOS1sYXlvdXQ6IHJpZ2h0OyAiCiAgICAgICAgIHhzbHQ6dGVtcGxhdGU9Ii9wdWJsaWMvdGVtcGxhdGVzL3Jpc2stZmlyc3Qvcmlzay1maXJzdC10ZW1wbGF0ZS54c2wiPgogICA8bWl0aWdhdGVkPgogICAgICA8cmlzayBjbGFzcz0iZmVhdHVyZSIvPgogICA8L21pdGlnYXRlZD4KICAgPGFjdGlvbj5BZG9wdCBDb21wbGV4IERlcGVuZGVuY3k8L2FjdGlvbj4KICAgPHJpc2sgY2xhc3M9ImludGVybmFsLW1vZGVsIi8+CiAgIDxyaXNrIGNsYXNzPSJjb21tdW5pY2F0aW9uIi8+CiAgIDxyaXNrIGNsYXNzPSJsb2NrLWluIi8+CjwvZGlhZ3JhbT4K + type="text/xml;purpose=adl;base64">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGRpYWdyYW0geG1sbnM9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS9hZGwiCiAgICAgICAgIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciCiAgICAgICAgIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIgogICAgICAgICB4bWxuczp4c2x0PSJodHRwOi8vd3d3LmtpdGU5Lm9yZy9zY2hlbWEveHNsdCIKICAgICAgICAgaWQ9ImRpYWdyYW0tMTEzIgogICAgICAgICBzdHlsZT0iLS1raXRlOS1sYXlvdXQ6IHJpZ2h0OyAiCiAgICAgICAgIHhzbHQ6dGVtcGxhdGU9Ii9wdWJsaWMvdGVtcGxhdGVzL3Jpc2stZmlyc3Qvcmlzay1maXJzdC10ZW1wbGF0ZS54c2wiPgogICA8Y29udGFpbmVyIGJvcmRlcmVkPSJ0cnVlIiBpZD0iYyIgc3R5bGU9Ii0ta2l0ZTktbGF5b3V0OiBkb3duOyAiPgogICAgICA8bWl0aWdhdGVkPgogICAgICAgICA8cmlzayBjbGFzcz0iZmVhdHVyZS1maXQiLz4KICAgICAgPC9taXRpZ2F0ZWQ+CiAgICAgIDxsYWJlbD5DbGllbnRzIG5lZWQgZmVhdHVyZXMuLi48L2xhYmVsPgogICA8L2NvbnRhaW5lcj4KICAgPGFjdGlvbj5BZG9wdCBDb21wbGV4IERlcGVuZGVuY3k8L2FjdGlvbj4KICAgPGNvbnRhaW5lciBib3JkZXJlZD0idHJ1ZSIgaWQ9ImMiIHN0eWxlPSItLWtpdGU5LWxheW91dDogZG93bjsgIj4KICAgICAgPHJpc2sgY2xhc3M9ImludGVybmFsLW1vZGVsIi8+CiAgICAgIDxyaXNrIGNsYXNzPSJjb21tdW5pY2F0aW9uIi8+CiAgICAgIDxyaXNrIGNsYXNzPSJsb2NrLWluIi8+CiAgIDwvY29udGFpbmVyPgo8L2RpYWdyYW0+Cg== - + k9-ui="drag delete align connect insert autoconnect layout label fill stroke size align" + k9-elem="container" + k9-type="connected"> - + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [0.0 0.0 0.0 0.0]; min-size: [160.0 213.33334350585938]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [73.0, 257.0]; rect-size: [193.0, 226.0]; position: none; painter: direct-svg; "> - - - - - - - - - - - - + + + width="193" + pp:y="$y" + pp:height="$height" + pp:x="$x" + rx="5pt" + ry="5pt" + height="226" + pp:width="$width"/> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + + + + + + + + + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [53.0, 509.0]; rect-size: [232.0, 25.0]; position: none; painter: direct-svg; "> - - - - - - - + @@ -1570,21 +1639,12 @@ fill-opacity: 1; - + k9-info="margin: [13.333333969116211 13.333333969116211 13.333333969116211 13.333333969116211]; padding: [16.0 29.33333396911621 16.0 16.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; layout: null; rectangular: connected; rect-pos: [338.0, 364.0]; rect-size: [343.0, 57.0]; position: none; painter: direct-svg; "> + k9-info="margin: [0.0 0.0 0.0 0.0]; padding: [0.0 0.0 0.0 0.0]; min-size: [0.0 0.0]; sizing: [minimize minimize]; horiz: center; vert: center; rectangular: connected; rect-pos: [354.0, 380.0]; rect-size: [298.0, 25.0]; position: none; painter: direct-svg; "> - @@ -1611,243 +1671,269 @@ fill-opacity: 1; - + k9-ui="drag delete align connect insert autoconnect layout label fill stroke size align" + k9-elem="container" + k9-type="connected"> - - - - - - - - - - - - + + + width="193" + pp:y="$y" + pp:height="$height" + pp:x="$x" + rx="5pt" + ry="5pt" + height="226" + pp:width="$width"/> - - - - - - + + + + + + + + - - - + + + + - - - - - - - - - - - - - - + + + + + + + + + + + + - - - + + + width="193" + pp:y="$y" + pp:height="$height" + pp:x="$x" + rx="5pt" + ry="5pt" + height="226" + pp:width="$width"/> - - - - - - + + + + + + + + - - - + + + + - - - - - - - - - - - - - - + + + + + + + + + + + + - - - + + + width="193" + pp:y="$y" + pp:height="$height" + pp:x="$x" + rx="5pt" + ry="5pt" + height="226" + pp:width="$width"/> - - - - - - + + + + + + + + - - - + + + + + + + + + + + + + + + + + + diff --git a/static/img/generated/single/risks/Coordination-Risk.svg b/static/img/generated/single/risks/Coordination-Risk.svg new file mode 100644 index 000000000..3d6b16189 --- /dev/null +++ b/static/img/generated/single/risks/Coordination-Risk.svg @@ -0,0 +1,1562 @@ + + + + http://robs-pro:8080/api/renderer?format=svg + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/static/img/generated/single/risks/Internal-Model-Risk.svg b/static/img/generated/single/risks/Internal-Model-Risk.svg new file mode 100644 index 000000000..82f91bff9 --- /dev/null +++ b/static/img/generated/single/risks/Internal-Model-Risk.svg @@ -0,0 +1,1562 @@ + + + + http://robs-pro:8080/api/renderer?format=svg + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/static/img/generated/single/risks/Reputational-Risk.svg b/static/img/generated/single/risks/Reputational-Risk.svg new file mode 100644 index 000000000..21f4a2d2f --- /dev/null +++ b/static/img/generated/single/risks/Reputational-Risk.svg @@ -0,0 +1,1562 @@ + + + + http://robs-pro:8080/api/renderer?format=svg + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/static/img/generated/titles/risks/Coordination-Risk.png b/static/img/generated/titles/risks/Coordination-Risk.png new file mode 100644 index 000000000..41f5464a5 Binary files /dev/null and b/static/img/generated/titles/risks/Coordination-Risk.png differ diff --git a/static/img/generated/titles/risks/Dependency-Risks/Lock-In-Risk/Cycles.png b/static/img/generated/titles/risks/Dependency-Risks/Lock-In-Risk/Cycles.png new file mode 100644 index 000000000..1e42c97ba Binary files /dev/null and b/static/img/generated/titles/risks/Dependency-Risks/Lock-In-Risk/Cycles.png differ diff --git a/static/img/generated/titles/risks/Dependency-Risks/Lock-In-Risk/Ecosystems.png b/static/img/generated/titles/risks/Dependency-Risks/Lock-In-Risk/Ecosystems.png new file mode 100644 index 000000000..9b6fa6bd3 Binary files /dev/null and b/static/img/generated/titles/risks/Dependency-Risks/Lock-In-Risk/Ecosystems.png differ diff --git a/static/img/generated/titles/risks/Dependency-Risks/Lock-In-Risk/Managing.png b/static/img/generated/titles/risks/Dependency-Risks/Lock-In-Risk/Managing.png new file mode 100644 index 000000000..d44480954 Binary files /dev/null and b/static/img/generated/titles/risks/Dependency-Risks/Lock-In-Risk/Managing.png differ diff --git a/static/img/generated/titles/risks/Internal-Model-Risk.png b/static/img/generated/titles/risks/Internal-Model-Risk.png new file mode 100644 index 000000000..9b79106ae Binary files /dev/null and b/static/img/generated/titles/risks/Internal-Model-Risk.png differ diff --git a/static/img/generated/titles/risks/Reputational-Risk.png b/static/img/generated/titles/risks/Reputational-Risk.png new file mode 100644 index 000000000..69b8daffe Binary files /dev/null and b/static/img/generated/titles/risks/Reputational-Risk.png differ