diff --git a/dictionary.txt b/dictionary.txt index c1c54f7ac..ca043b40c 100644 --- a/dictionary.txt +++ b/dictionary.txt @@ -359,3 +359,6 @@ erratically eidos lara croft +accrete +decommissioned +ratchets diff --git a/docs/practices/Deployment-And-Operations/Automation.md b/docs/practices/Deployment-And-Operations/Automation.md index 7a1d9e673..fd580175d 100644 --- a/docs/practices/Deployment-And-Operations/Automation.md +++ b/docs/practices/Deployment-And-Operations/Automation.md @@ -27,7 +27,7 @@ practice: - tag: Invisibility Risk reason: "The quality and performance characteristics may be obscured by automation." - tag: Process Risk - reason: "Automation introduces a process" + reason: "Automation introduces a process, which therefore means a new source of Process Risk." - tag: Agency Risk reason: Automated processes have their own agency and might not work as desired. - tag: Security Risk diff --git a/docs/practices/Deployment-And-Operations/Configuration-Management.md b/docs/practices/Deployment-And-Operations/Configuration-Management.md index 2499ec6cd..cdde21749 100644 --- a/docs/practices/Deployment-And-Operations/Configuration-Management.md +++ b/docs/practices/Deployment-And-Operations/Configuration-Management.md @@ -22,8 +22,6 @@ practice: - tag: Complexity Risk reason: "Reduces complexity by managing system changes in a controlled and documented manner." attendant: - - tag: Process Risk - reason: "The CM process can introduce bureaucratic overhead." - tag: Dependency Risk reason: "Dependencies on the CM tools and processes can become critical points of failure." - tag: Security Risk diff --git a/docs/practices/Deployment-And-Operations/Monitoring.md b/docs/practices/Deployment-And-Operations/Monitoring.md index 29eac9474..177397c8e 100644 --- a/docs/practices/Deployment-And-Operations/Monitoring.md +++ b/docs/practices/Deployment-And-Operations/Monitoring.md @@ -19,6 +19,8 @@ practice: reason: "Identifies and addresses potential issues before they impact system reliability." - tag: Security Risk reason: "Monitors for security breaches and anomalies." + - tag: Process Risk + reason: "Monitoring a process can ensure that when it misbehaves the issues are quickly caught." attendant: - tag: Complexity Risk reason: "Implementing comprehensive monitoring solutions can add complexity." diff --git a/docs/practices/Deployment-And-Operations/Release.md b/docs/practices/Deployment-And-Operations/Release.md index 1ae86fdbf..26d0457dd 100644 --- a/docs/practices/Deployment-And-Operations/Release.md +++ b/docs/practices/Deployment-And-Operations/Release.md @@ -26,6 +26,8 @@ practice: reason: "Delays in the release process can impact overall project timelines." - tag: Operational Risk reason: "Releasing software means that the software has to be supported in production." + - tag: Process Risk + reason: "Complex release procedures are a source of process risk." related: - ../Planning-and-Management/Change-Management - ../Tools-and-Standards/Version-Control diff --git a/docs/practices/Development-And-Coding/Coding.md b/docs/practices/Development-And-Coding/Coding.md index 46086cd2e..d5cbf51e3 100644 --- a/docs/practices/Development-And-Coding/Coding.md +++ b/docs/practices/Development-And-Coding/Coding.md @@ -16,7 +16,7 @@ practice: - tag: Feature Risk reason: "Build or improve some features which our clients will find useful." - tag: Process Risk - reason: Problems with processes can be fixed by adding code. + reason: Problems and edge cases with software processes can be fixed by adding code. attendant: - tag: Implementation Risk reason: "Poor coding practices can lead to significant implementation issues." diff --git a/docs/practices/External-Relations/Contracts.md b/docs/practices/External-Relations/Contracts.md index be7be97be..1638d5cb4 100644 --- a/docs/practices/External-Relations/Contracts.md +++ b/docs/practices/External-Relations/Contracts.md @@ -25,7 +25,7 @@ practice: - tag: Coordination Risk reason: "Requires careful coordination to ensure all terms are met." - tag: Process Risk - reason: "The process of drafting, negotiating, and managing contracts can be complex and time-consuming." + reason: "The process of drafting, negotiating, and managing contracts is a process with significant risk." - tag: Deadline Risk reason: "Contracts often stipulate certain conditions must be met at certain times." related: diff --git a/docs/practices/Planning-And-Management/Approvals.md b/docs/practices/Planning-And-Management/Approvals.md index 3221a2975..e36cc22b1 100644 --- a/docs/practices/Planning-And-Management/Approvals.md +++ b/docs/practices/Planning-And-Management/Approvals.md @@ -26,7 +26,7 @@ practice: - tag: Coordination Risk reason: "Requires coordination among stakeholders to provide timely sign-off." - tag: Process Risk - reason: "Approval processes may lack required flexibility" + reason: "Adding approvals to a process increases the number of stakeholders involved and can impact process performance." related: - ../Planning-and-Management/Stakeholder-Management - ../Communication-and-Collaboration/Review diff --git a/docs/practices/Planning-And-Management/Change-Management.md b/docs/practices/Planning-And-Management/Change-Management.md index 30c657f83..475e7ea3f 100644 --- a/docs/practices/Planning-And-Management/Change-Management.md +++ b/docs/practices/Planning-And-Management/Change-Management.md @@ -23,7 +23,7 @@ practice: - tag: Schedule Risk reason: "Managing changes systematically can introduce delays." - tag: Process Risk - reason: "Change management can increase dependency on approval processes and stakeholders." + reason: "Change control is a process, and therefore is a source of process risk. " related: - ../Development-and-Coding/Coding - ../Testing-and-Quality-Assurance/Integration-Testing diff --git a/docs/practices/Planning-And-Management/Delegation.md b/docs/practices/Planning-And-Management/Delegation.md index 74fcb436d..946e297ad 100644 --- a/docs/practices/Planning-And-Management/Delegation.md +++ b/docs/practices/Planning-And-Management/Delegation.md @@ -18,8 +18,6 @@ practice: reason: "Ensures optimal utilization of team members' skills and capabilities." - tag: Schedule Risk reason: "Distributes workload effectively, helping to meet deadlines." - - tag: Process Risk - reason: "Delegation can be used to stop processes getting in the way of progress." attendant: - tag: Agency Risk reason: "Can lead to a loss of control over task execution and quality." diff --git a/docs/practices/Planning-And-Management/Issue-Management.md b/docs/practices/Planning-And-Management/Issue-Management.md index c33645669..8eb9dd185 100644 --- a/docs/practices/Planning-And-Management/Issue-Management.md +++ b/docs/practices/Planning-And-Management/Issue-Management.md @@ -30,7 +30,7 @@ practice: - tag: Complexity Risk reason: "Managing an excessive number of logged issues can add complexity." - tag: Process Risk - reason: "Creates dependency on issue tracking tools and their accuracy." + reason: "The issue lifecycle from creation to resolution is a process, therefore a source of process risk." - tag: Schedule Risk reason: "Managing and resolving logged issues can impact project timelines." related: diff --git a/docs/risks/Dependency-Risks/Agency-Risks/_category_.yaml b/docs/risks/Dependency-Risks/Agency-Risks/_category_.yaml index 43bf86ec5..b20827d55 100644 --- a/docs/risks/Dependency-Risks/Agency-Risks/_category_.yaml +++ b/docs/risks/Dependency-Risks/Agency-Risks/_category_.yaml @@ -1,4 +1,4 @@ -position: 4 +position: 7 link: type: doc id: Agency-Risk \ No newline at end of file diff --git a/docs/risks/Dependency-Risks/Boundary-Risk.md b/docs/risks/Dependency-Risks/Boundary-Risk.md index 91bdc2427..fdcd33478 100644 --- a/docs/risks/Dependency-Risks/Boundary-Risk.md +++ b/docs/risks/Dependency-Risks/Boundary-Risk.md @@ -6,7 +6,7 @@ slug: /risks/Boundary-Risk featured: class: c element: '' -sidebar_position: 11 +sidebar_position: 6 tags: - Risks - Boundary Risk diff --git a/docs/risks/Dependency-Risks/Deadline-Risk/_category_.yaml b/docs/risks/Dependency-Risks/Deadline-Risk/_category_.yaml index f76e70d95..9f19f4e1c 100644 --- a/docs/risks/Dependency-Risks/Deadline-Risk/_category_.yaml +++ b/docs/risks/Dependency-Risks/Deadline-Risk/_category_.yaml @@ -1,4 +1,4 @@ -position: 4 +position: 3 link: type: doc id: Deadline-Risk \ No newline at end of file diff --git a/docs/risks/Dependency-Risks/Dependency-Risk.md b/docs/risks/Dependency-Risks/Dependency-Risk.md index aa47b9dd7..ce2d80cfd 100644 --- a/docs/risks/Dependency-Risks/Dependency-Risk.md +++ b/docs/risks/Dependency-Risks/Dependency-Risk.md @@ -1,5 +1,5 @@ --- -title: Dependency Risk +title: Dependency Risks description: Risk faced by depending on something else, e.g. an event, process, person, piece of software or an organisation. featured: diff --git a/docs/risks/Dependency-Risks/Process-Risk.md b/docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md similarity index 62% rename from docs/risks/Dependency-Risks/Process-Risk.md rename to docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md index 258a9e00b..0475383c7 100644 --- a/docs/risks/Dependency-Risks/Process-Risk.md +++ b/docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md @@ -1,48 +1,36 @@ ---- -title: Process Risk -description: Risks due to the following a particular protocol of communication with a dependency, which may not work out the way we want. -slug: /risks/Process-Risk -featured: - class: c - element: '' -sidebar_position: 10 -tweet: yes -tags: - - Risks - - Process Risk -part_of: Dependency Risk ---- - -[Process Risk](/tags/Process-Risk) is the risk you take on whenever you embark on completing a _process_. -> "**Process**: a process is a set of activities that interact to achieve a result." - [Process, _Wikipedia_](https://en.wikipedia.org/wiki/Process) + + + + + Processes commonly involve _forms_: if you're filling out a form (whether on paper or on a computer) then you're involved in a process of some sort, whether an "Account Registration" process, "Loan Application" process or "Consumer Satisfaction Survey" process. Sometimes, they involve events occurring: a [build process](https://en.wikipedia.org/wiki/Software_build) might start after you commit some code, for example. The _code we write_ is usually describing some kind of process we want performed. -## The Purpose Of Process -![Introducing process can mitigate many risks](/img/generated/risks/process/process-risk-introduction.svg) -As the above diagram shows, process exists to mitigate other kinds of risk. For example: - - **[Coordination Risk](/tags/Coordination-Risk)**: you can often use process to help people coordinate. For example, a [Production Line](https://en.wikipedia.org/wiki/Production_line) is a process where work being done by one person is pushed to the next person when it's done. A room booking process is designed to efficiently allocate meeting rooms. - - **[Operational Risk](/tags/Operational-Risk)**: this encompasses the risk of people _not doing their job properly_. But, by having a process, (and asking, did this person follow the process?) you can draw a distinction between a process failure and a personnel failure. For example, accepting funds from a money launderer _could_ be a failure of a bank employee. But, if they followed the _process_, it's a failure of the [Process](/tags/Process-Risk) itself. - - **[Complexity Risk](/tags/Complexity-Risk)**: working _within a process_ can reduce the amount of [Complexity](/tags/Complexity-Risk) you have to think about. We accept that processes are going to slow us down, but we appreciate the reduction in risk this brings. Clearly, the complexity hasn't gone away, but it's hidden within design of the process. For example, [McDonalds](https://en.wikipedia.org/wiki/McDonald's) tries to design its operation so that preparing each food item is a simple process to follow, reducing complexity (and training time) for the staff. +## Bureaucracy + +Where we've talked about process evolution above, the actors involved have been acting in good faith: they are working to mitigate risk in the organisation. The [Process Risk](/tags/Process-Risk) that accretes along the way is an _unintended consequence_: There is no guarantee that the process that arises will be humane and intuitive. Many organisational processes end up being baroque or Kafka-esque, forcing unintuitive behaviour on their users. This is partly because process design is _hard_ and it's difficult to anticipate all the various ways a process will be used ahead-of-time. + +But [Parkinson's Law](https://en.wikipedia.org/wiki/Parkinsons_law) takes this one step further: the human actors shaping the organisation will abuse their positions of power in order to further their own careers (this is [Agency Risk](/tags/Agency-Risk), which we will come to in a future section): + +> "Parkinson's law is the adage that "work expands so as to fill the time available for its completion". It is sometimes applied to the growth of bureaucracy in an organisation... He explains this growth by two forces: (1) 'An official wants to multiply subordinates, not rivals' and (2) 'Officials make work for each other.'" - [Parkinson's Law, _Wikipedia_](https://en.wikipedia.org/wiki/Parkinsons_law) + +This implies that there is a tendency for organisations to end up with _needless levels of [Process Risk](/tags/Process-Risk)_. + +To fix this, design needs to happen at a higher level. In our code, we would [Refactor](/risks/Complexity-Risk#technical-debt) these processes to remove the unwanted complexity. In a business, it requires re-organisation at a higher level to redefine the boundaries and responsibilities between the teams. + +Next in the tour of [Dependency Risks](/tags/Dependency-Risk), it's time to look at [Boundary Risk](/tags/Boundary-Risk). -These are all examples of [Risk Mitigation](/tags/Mitigated-Risk) for the _owners_ of the process. But often the _consumers_ of the process end up picking up [Process Risks](/tags/Process-Risk) as a result: - - **[Invisibility Risk](/tags/Invisibility-Risk)**: it's often not possible to see how far along a process is to completion. Sometimes, you can do this to an extent. For example, when I send a package for delivery, I can see roughly how far it's got on the tracking website. But this is still less-than-complete information and is a representation of reality. - - **[Dead-End Risk](/tags/Dead-End-Risk)**: even if you have the right process, initiating a process has no guarantee that your efforts won't be wasted and you'll be back where you started from. The chances of this happening increase as you get further from the standard use-case for the process, and the sunk cost increases with the length of time the process takes to complete. - - **[Feature Access Risk](/tags/Feature-Access-Risk)**: processes generally handle the common stuff, but ignore the edge cases. For example, a form on a website might not be designed to be accessible to disabled people, or might only cater to some common subset of use-cases. - -![Process Risk, and its consequences, compared with Agency Risk](/img/generated/risks/process/process-risk.svg) - -When we talk about "[Process Risk](/tags/Process-Risk)" we are really referring to these types of risks, arising from "following a set of instructions." Compare this with [Agency Risk](/tags/Agency-Risk) (which we will review in a forthcoming section), which is risks due to _not_ following the instructions, as shown in the above diagram . Let's look at two examples, how [Process Risk](/tags/Process-Risk) can lead to [Invisibility Risks](/tags/Invisibility-Risk) and [Agency Risk](/tags/Agency-Risk). -### Processes And Invisibility Risk + +s And Invisibility Risk Processes tend to work well for the common cases because *practice makes perfect*, but they are really tested when unusual situations occur. Expanding processes to deal with edge-cases incurs [Complexity Risk](/tags/Complexity-Risk), so often it's better to try and have clear boundaries of what is "in" and "out" of the process' domain. @@ -111,31 +99,4 @@ In this example, you can see how the organisation evolves process to mitigate ri Two key take-aways from this: - **The System Gets More Complex**: with different teams working to mitigate different risks in different ways, we end up with a more complex situation than when we started. Although we've _evolved_ in this direction by mitigating risks, it's not necessarily the case that the end result is _more efficient_. In fact, as we will see in [Map-And-Territory Risk](Map-And-Territory-Risk#markets), this evolution can lead to some very inadequate (but nonetheless stable) systems. - - **Organisational process evolves to mitigate risk**: just as we've shown that [actions are about mitigating risk](/thinking/Start), we've now seen that these actions get taken in an evolutionary way. That is, there is "pressure" on our internal processes to reduce risk. The people maintaining these processes feel the risk, and modify their processes in response. Let's look at a real-life example: - -## An Example - Release Processes - -Over the years I have worked in the Finance Industry it's given me time to observe how, across an entire industry, process can evolve both in response to regulatory pressure, organisational maturity and mitigating risk: - -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. -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, developers would _automate_ the processes for release, sometimes 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, because effectively, that meant that developers could get access to production with the press of a button, taking you back to step 1... - -## Bureaucracy - -Where we've talked about process evolution above, the actors involved have been acting in good faith: they are working to mitigate risk in the organisation. The [Process Risk](/tags/Process-Risk) that accretes along the way is an _unintended consequence_: There is no guarantee that the process that arises will be humane and intuitive. Many organisational processes end up being baroque or Kafka-esque, forcing unintuitive behaviour on their users. This is partly because process design is _hard_ and it's difficult to anticipate all the various ways a process will be used ahead-of-time. - -But [Parkinson's Law](https://en.wikipedia.org/wiki/Parkinsons_law) takes this one step further: the human actors shaping the organisation will abuse their positions of power in order to further their own careers (this is [Agency Risk](/tags/Agency-Risk), which we will come to in a future section): - -> "Parkinson's law is the adage that "work expands so as to fill the time available for its completion". It is sometimes applied to the growth of bureaucracy in an organisation... He explains this growth by two forces: (1) 'An official wants to multiply subordinates, not rivals' and (2) 'Officials make work for each other.'" - [Parkinson's Law, _Wikipedia_](https://en.wikipedia.org/wiki/Parkinsons_law) - -This implies that there is a tendency for organisations to end up with _needless levels of [Process Risk](/tags/Process-Risk)_. - -To fix this, design needs to happen at a higher level. In our code, we would [Refactor](/risks/Complexity-Risk#technical-debt) these processes to remove the unwanted complexity. In a business, it requires re-organisation at a higher level to redefine the boundaries and responsibilities between the teams. - -Next in the tour of [Dependency Risks](/tags/Dependency-Risk), it's time to look at [Boundary Risk](/tags/Boundary-Risk). - - + - **Organisational process evolves to mitigate risk**: just as we've shown that [actions are about mitigating risk](/thinking/Start), we've now seen that these actions get taken in an evolutionary way. That is, there is "pressure" on our internal processes to reduce risk. The people maintaining these processes feel the risk, and modify their processes in response. Let's look at a real-life example: \ No newline at end of file diff --git a/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md b/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md new file mode 100644 index 000000000..0d816b9f9 --- /dev/null +++ b/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md @@ -0,0 +1,104 @@ +--- +title: Process Risk +description: When you depend on a business process, human process or software process to give you something you need. + +slug: /risks/Process-Risk +featured: + class: c + element: '' +sidebar_position: 10 +tweet: yes +tags: + - Risks + - Process Risk +part_of: Dependency Risk +--- + + + +[Process Risk](/tags/Process-Risk) is the risk you are exposed to when depending on the completion of an activity or process. + +> "**Process**: a process is a set of activities that interact to achieve a result." - [Process, _Wikipedia_](https://en.wikipedia.org/wiki/Process) + +Process Risk intersects with several other types of risk we've covered so far: + +- [Scarcity Risk](/tags/Scarcity-Risk): Processes may become scarce when they lack resources (think of CPU bottlenecks or queues at the post-office counter). +- [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). +- [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 Risks](/tags/Feature-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). + +So clearly there is overlap here with other types of risk we've looked at: a good process should be reliable, available (i.e. not scarce), transparent in its communications and obedient to our wishes. In fact, Process Risk really should be thought of as just a wrapper for other things. Nevertheless, it's a useful pattern to talk about as it comes up repeatedly. + +![Process Risk Overlap Venn Diagram](/img/risks/process-risk/Process-Risk-Overlap.svg) + +## Worked Example + +A team in a large organisation is struggling to deal with the complexity and variety of requests made to it. They are also struggling to justify poor response times, accusations of favouritism and lack of communication to other internal customers they work for. In order to establish some control, the manager of the team introduces an [Issue Management system](/tags/Issue-Management) so that work is done in the order it arrives and there is a clear audit of how long requests took to process and who in the team is dealing with them. Issues are raised via an online form. + +There are two ways to look at how this action changes the risk profile for the team: the team's internal risk profile and that of the customers of the team. Let's look at each in turn. + +### Team's Risk Perspective + +![Process Risk - Team](/img/generated/risks/posters/process-risk1.svg) + +In this case, the team is using a process to help with the following risks: + + - **[Coordination Risk](/tags/Coordination-Risk)**: you can often use process to help people coordinate. For example, a [Production Line](https://en.wikipedia.org/wiki/Production_line) is a process where work being done by one person is pushed to the next person when it's done. A room booking process is designed to efficiently allocate meeting rooms. + + - **[Communication Risk](/tags/Communication-Risk)**: processes can be used as a means to communicate. Here, it might be possible for the team leader to see what staff are working on at any given moment, or track the rate at which work is being completed each week. + + - **[Agency Risk](/tags/Agency-Risk)**: by using the issue management system, decisions about what to work on are being taken out of the team's control, hopefully addressing the concerns of favouritism. + +On the downside, the team adopts a level of [Process Risk](/tags/Process-Risk): Should the issue management system be unavailable, they may not be able to track what it is they're supposed to do next and it may not be apparent whether work is being prioritised in the right order. + +### Customer's Risk Perspective + +![Process Risk - Customer](/img/generated/risks/posters/process-risk2.svg) + +For the customers of the team, the introduction of the issue management system changes the way they interact with the team: + + - The nature of the **[Communication Risk](/tags/Communication-Risk)** is changed. Work status may be more visible to customers but they may find it harder to be precise about what they want done, but... + + - The introduced **[Process Risk](/tags/Process-Risk)** may be that customers can't urgent work addressed quickly, find it hard to request the right kind of work through the ticketing interface or find that their work is no longer "paired" to the members of the team who understood their needs best, reducing the overall quality of the service. + + +## Example Threats + + +### 1. Poor Fit + +- **Threat**: Processes can become over-complicated and take too long to initiate. + +- **Threat**: Processes are often over-rigid and don't fit to individual circumstances. + +- **Threat**: Processes are often introduced to cut costs and damage service quality as a side-effect. + +### 2. Resistance to Change + +- **Threat**: Often processes are imposed without regard to whether or not the people impacted by the process (in the above example, the customers and the team members) are going to be happy with the change. + + **See:** [Change Management](https://en.wikipedia.org/wiki/Change_management) + +- **Threat**: Once embedded, processes can be _hard to change_ in much the same way as they are hard to implement in the first place. This can be especially true as the world around them changes and they are inflexible to new demands. + +### 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. + +### 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. + +:::tip Anecdote Corner + +Over the years I have worked in the Finance Industry it's given me time to observe how, across an entire industry, process can evolve both in response to regulatory pressure, organisational maturity and mitigating risk: + +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. +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/Process-Risk/_category_.yaml b/docs/risks/Dependency-Risks/Process-Risk/_category_.yaml new file mode 100644 index 000000000..a522e2825 --- /dev/null +++ b/docs/risks/Dependency-Risks/Process-Risk/_category_.yaml @@ -0,0 +1,4 @@ +position: 5 +link: + type: doc + id: Process-Risk \ No newline at end of file diff --git a/docs/risks/Dependency-Risks/Reliability-Risk.md b/docs/risks/Dependency-Risks/Reliability-Risk.md index 04f1d1a0c..6c7b0fd01 100644 --- a/docs/risks/Dependency-Risks/Reliability-Risk.md +++ b/docs/risks/Dependency-Risks/Reliability-Risk.md @@ -6,7 +6,7 @@ slug: /risks/Reliability-Risk featured: class: c element: '' -sidebar_position: 6 +sidebar_position: 1 tags: - Dependency Risk - Fit Risk diff --git a/docs/risks/Dependency-Risks/Scarcity-Risks/_category_.yaml b/docs/risks/Dependency-Risks/Scarcity-Risks/_category_.yaml index 2956a564a..da6d60d27 100644 --- a/docs/risks/Dependency-Risks/Scarcity-Risks/_category_.yaml +++ b/docs/risks/Dependency-Risks/Scarcity-Risks/_category_.yaml @@ -1,4 +1,4 @@ -position: 6 +position: 2 link: type: doc id: Scarcity-Risk \ No newline at end of file diff --git a/docs/risks/Dependency-Risks/Software-Dependency-Risk.md b/docs/risks/Dependency-Risks/Software-Dependency-Risk.md index 6a2f099a4..84446d34f 100644 --- a/docs/risks/Dependency-Risks/Software-Dependency-Risk.md +++ b/docs/risks/Dependency-Risks/Software-Dependency-Risk.md @@ -6,7 +6,7 @@ slug: /risks/Software-Dependency-Risk featured: class: c element: '' -sidebar_position: 9 +sidebar_position: 4 tweet: yes tags: - Risks diff --git a/docs/risks/Dependency-Risks/Agency-Risks/Security-Risk.md b/docs/risks/Security-Risk.md similarity index 100% rename from docs/risks/Dependency-Risks/Agency-Risks/Security-Risk.md rename to docs/risks/Security-Risk.md diff --git a/numbers/Practices.numbers b/numbers/Practices.numbers index fb57fcde2..af49bdfa1 100644 Binary files a/numbers/Practices.numbers and b/numbers/Practices.numbers differ diff --git a/src/images/generated/risks/posters/complexity-risk1.adl b/src/images/generated/risks/posters/complexity-risk1.adl index 887b643d7..d21e2b528 100644 --- a/src/images/generated/risks/posters/complexity-risk1.adl +++ b/src/images/generated/risks/posters/complexity-risk1.adl @@ -16,7 +16,7 @@ Redundancy - + diff --git a/src/images/generated/risks/posters/process-risk1.adl b/src/images/generated/risks/posters/process-risk1.adl new file mode 100644 index 000000000..0c59e5119 --- /dev/null +++ b/src/images/generated/risks/posters/process-risk1.adl @@ -0,0 +1,37 @@ + + + + + + + + + + + + + + + + + + + + Issue Management + + + + + + diff --git a/src/images/generated/risks/posters/process-risk2.adl b/src/images/generated/risks/posters/process-risk2.adl new file mode 100644 index 000000000..1ddd0e4ef --- /dev/null +++ b/src/images/generated/risks/posters/process-risk2.adl @@ -0,0 +1,44 @@ + + + + + + + + + + + + + + + + + Issue Management + + + + + + + + + + + + diff --git a/static/img/generated/risks/posters/complexity-risk1.svg b/static/img/generated/risks/posters/complexity-risk1.svg index 1d7355e87..d8d3b9483 100644 --- a/static/img/generated/risks/posters/complexity-risk1.svg +++ b/static/img/generated/risks/posters/complexity-risk1.svg @@ -1445,7 +1445,7 @@ fill-opacity: 1; xlink:type="simple" id="adl:markup" xlink:show="other" - type="text/xml;purpose=adl;base64">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGRpYWdyYW0geG1sbnM9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS9hZGwiCiAgICAgICAgIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciCiAgICAgICAgIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIgogICAgICAgICB4bWxuczp4c2x0PSJodHRwOi8vd3d3LmtpdGU5Lm9yZy9zY2hlbWEveHNsdCIKICAgICAgICAgaWQ9ImRpYWdyYW0tMTEzIgogICAgICAgICB4c2x0OnRlbXBsYXRlPSIvcHVibGljL3RlbXBsYXRlcy9yaXNrLWZpcnN0L3Jpc2stZmlyc3QtdGVtcGxhdGUueHNsIj4KICAgPGNvbnRhaW5lciBib3JkZXJlZD0idHJ1ZSIgaWQ9ImMiIHN0eWxlPSItLWtpdGU5LWxheW91dDogZG93bjsgIj4KICAgICAgPHJpc2sgY2xhc3M9Im9wZXJhdGlvbmFsIi8+CiAgICAgIDxsYWJlbCBpZD0iaWRfMTYiPgogICAgICBUaGUgd2Vic2l0ZSBjb21pbmcgZG93biBjb3VsZCBkYW1hZ2UKICAgICAgdGhlIHdob2xlIGNvbW11bml0eS4KICAgIDwvbGFiZWw+CiAgIDwvY29udGFpbmVyPgogICA8Z3JvdXAgc3R5bGU9Ii0ta2l0ZTktbGF5b3V0OiBkb3duOyAtLWtpdGU5LWhvcml6b250YWwtYWxpZ246IGxlZnQ7Ij4KICAgICAgPGFjdGlvbiBzdHlsZT0iLS1raXRlOS1ob3Jpem9udGFsLWFsaWduOiBsZWZ0OyI+UmVkdW5kYW5jeTwvYWN0aW9uPgogICA8L2dyb3VwPgogICA8Y29udGFpbmVyIGlkPSJkIiBzdHlsZT0iLS1raXRlOS12ZXJ0aWNhbC1zaXppbmc6IG1heGltaXplOyAgIj4KICAgICAgPHJpc2sgY2xhc3M9ImNvbXBsZXhpdHkiIHN0eWxlPSItLWtpdGU5LXZlcnRpY2FsLWFsaWduOiB0b3A7ICAiLz4KICAgICAgPGxhYmVsIGlkPSJpZF8xNi1vYSI+QXR0ZW5kYW50IFJpc2tzPC9sYWJlbD4KICAgPC9jb250YWluZXI+CjwvZGlhZ3JhbT4K + type="text/xml;purpose=adl;base64">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGRpYWdyYW0geG1sbnM9Imh0dHA6Ly93d3cua2l0ZTkub3JnL3NjaGVtYS9hZGwiCiAgICAgICAgIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciCiAgICAgICAgIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIgogICAgICAgICB4bWxuczp4c2x0PSJodHRwOi8vd3d3LmtpdGU5Lm9yZy9zY2hlbWEveHNsdCIKICAgICAgICAgaWQ9ImRpYWdyYW0tMTEzIgogICAgICAgICB4c2x0OnRlbXBsYXRlPSIvcHVibGljL3RlbXBsYXRlcy9yaXNrLWZpcnN0L3Jpc2stZmlyc3QtdGVtcGxhdGUueHNsIj4KICAgPGNvbnRhaW5lciBib3JkZXJlZD0idHJ1ZSIgaWQ9ImMiIHN0eWxlPSItLWtpdGU5LWxheW91dDogZG93bjsgIj4KICAgICAgPHJpc2sgY2xhc3M9Im9wZXJhdGlvbmFsIi8+CiAgICAgIDxsYWJlbCBpZD0iaWRfMTYiPgogICAgICBUaGUgd2Vic2l0ZSBjb21pbmcgZG93biBjb3VsZCBkYW1hZ2UKICAgICAgdGhlIHdob2xlIGNvbW11bml0eS4KICAgIDwvbGFiZWw+CiAgIDwvY29udGFpbmVyPgogICA8Z3JvdXAgc3R5bGU9Ii0ta2l0ZTktbGF5b3V0OiBkb3duOyAtLWtpdGU5LWhvcml6b250YWwtYWxpZ246IGxlZnQ7Ij4KICAgICAgPGFjdGlvbiBzdHlsZT0iLS1raXRlOS1ob3Jpem9udGFsLWFsaWduOiBsZWZ0OyI+UmVkdW5kYW5jeTwvYWN0aW9uPgogICA8L2dyb3VwPgogICA8Y29udGFpbmVyIGlkPSJkIiBzdHlsZT0iLS1raXRlOS12ZXJ0aWNhbC1zaXppbmc6IG1heGltaXplOyAgIj4KICAgICAgPHJpc2sgY2xhc3M9ImNvbXBsZXhpdHkiLz4KICAgICAgPGxhYmVsIGlkPSJpZF8xNi1vYSI+QXR0ZW5kYW50IFJpc2tzPC9sYWJlbD4KICAgPC9jb250YWluZXI+CjwvZGlhZ3JhbT4K - + 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: [778.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: [858.0, 66.0]; rect-size: [34.0, 35.0]; position: none; painter: direct-svg; "> @@ -1735,7 +1734,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: [841.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: [841.0, 114.0]; rect-size: [68.0, 68.0]; position: none; painter: direct-svg; "> + + + http://robs-pro:8080/api/renderer?format=svg + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/static/img/generated/risks/posters/process-risk1.svg b/static/img/generated/risks/posters/process-risk1.svg new file mode 100644 index 000000000..31d11c7c0 --- /dev/null +++ b/static/img/generated/risks/posters/process-risk1.svg @@ -0,0 +1,2072 @@ + + + + http://robs-pro:8080/api/renderer?format=svg + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/static/img/generated/risks/posters/process-risk2.svg b/static/img/generated/risks/posters/process-risk2.svg new file mode 100644 index 000000000..e0edbcfb5 --- /dev/null +++ b/static/img/generated/risks/posters/process-risk2.svg @@ -0,0 +1,2125 @@ + + + + http://robs-pro:8080/api/renderer?format=svg + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/static/img/risks/process-risk/Process-Risk-Overlap.svg b/static/img/risks/process-risk/Process-Risk-Overlap.svg new file mode 100644 index 000000000..63d44ebef --- /dev/null +++ b/static/img/risks/process-risk/Process-Risk-Overlap.svg @@ -0,0 +1 @@ + \ No newline at end of file