diff --git a/docs/estimating/Fractals.md b/docs/estimating/Fractals.md
index 41726b14f..297ecf876 100644
--- a/docs/estimating/Fractals.md
+++ b/docs/estimating/Fractals.md
@@ -98,7 +98,7 @@ Although there are some high-profile wins with these types of problems, generall
## Applying Risk-First
-Let's look at the conclusions we reached in [Boundary Risk](/tags/Boundary-Risk):
+Let's look at the conclusions we reached in [Lock-In Risk](/tags/Lock-In-Risk):
> - **Human need is [Fractal](https://en.wikipedia.org/wiki/Fractal)**: this means that over time, software products have evolved to more closely map human needs. Software that would have delighted us ten years ago lacks the sophistication we expect today.
- **Software and hardware are both improving with time**: due to evolution and the ability to support greater and greater levels of complexity.
diff --git a/docs/estimating/Interference-Checklist.md b/docs/estimating/Interference-Checklist.md
index 4344379f5..ae5693f00 100644
--- a/docs/estimating/Interference-Checklist.md
+++ b/docs/estimating/Interference-Checklist.md
@@ -77,7 +77,7 @@ Download this in [PDF](/estimating/Interference-Checklist.pdf) or [Numbers](/est
| | No prior work exists in this area | | |
| | Significant algorithmic innovation is required | | |
| | | | |
-| **\- [Boundary Risk](/tags/Boundary-Risk)** | Ecosystem choice | | |
+| **\- [Lock-In Risk](/tags/Lock-In-Risk)** | Ecosystem choice | | |
| | Platform choice | | |
| | App stores | | |
| | Language choice | | |
diff --git a/docs/practices/Development-And-Coding/Library-Adoption.md b/docs/practices/Development-And-Coding/Library-Adoption.md
index 006f7fb58..e22d37896 100644
--- a/docs/practices/Development-And-Coding/Library-Adoption.md
+++ b/docs/practices/Development-And-Coding/Library-Adoption.md
@@ -23,7 +23,7 @@ practice:
attendant:
- tag: Software Dependency Risk
reason: "Creates dependencies on the adopted standards and libraries."
- - tag: Boundary Risk
+ - tag: Lock-In Risk
reason: "Limits flexibility by adhering to specific standards and libraries which may be hard to change later."
- tag: Funding Risk
reason: "Can incur costs associated with adopting standards or libraries."
diff --git a/docs/practices/Development-And-Coding/Tool-Adoption.md b/docs/practices/Development-And-Coding/Tool-Adoption.md
index e342c989e..cf04dcf9a 100644
--- a/docs/practices/Development-And-Coding/Tool-Adoption.md
+++ b/docs/practices/Development-And-Coding/Tool-Adoption.md
@@ -26,7 +26,7 @@ practice:
reason: "Can incur costs associated with acquiring and maintaining tools."
- tag: Complexity Risk
reason: "Integrating multiple tools can add complexity to the development process."
- - tag: Boundary Risk
+ - tag: Lock-In Risk
reason: Once tools become embedded in the process, they can be hard to change.
related:
- ../Planning-and-Management/Change-Management
diff --git a/docs/practices/External-Relations/Analysis.md b/docs/practices/External-Relations/Analysis.md
index cfd248dd5..619949b7f 100644
--- a/docs/practices/External-Relations/Analysis.md
+++ b/docs/practices/External-Relations/Analysis.md
@@ -28,7 +28,7 @@ practice:
reason: "Can be time-consuming, potentially delaying the start of development."
- tag: Agency Risk
reason: "Creates dependencies on the availability and accuracy of information from stakeholders."
- - tag: Boundary Risk
+ - tag: Lock-In Risk
reason: "Well-defined analysis can create rigid boundaries that limit flexibility."
related:
- ../Planning-and-Management/Requirements-Capture
diff --git a/docs/practices/External-Relations/Contracts.md b/docs/practices/External-Relations/Contracts.md
index 691574943..65776b955 100644
--- a/docs/practices/External-Relations/Contracts.md
+++ b/docs/practices/External-Relations/Contracts.md
@@ -20,7 +20,7 @@ practice:
- tag: Schedule Risk
reason: "Establishes timelines and milestones to keep the project on track."
attendant:
- - tag: Boundary Risk
+ - tag: Lock-In Risk
reason: "Contracts can create rigid boundaries that limit flexibility."
- tag: Coordination Risk
reason: "Contracting work can often involve setting careful terms to minimise coordination risks."
diff --git a/docs/practices/Planning-And-Management/Design.md b/docs/practices/Planning-And-Management/Design.md
index 1b6ccecc9..b62e75fc2 100644
--- a/docs/practices/Planning-And-Management/Design.md
+++ b/docs/practices/Planning-And-Management/Design.md
@@ -24,7 +24,7 @@ practice:
- tag: Market Risk
reason: (Research and) design allows you to leapfrog competitors and provide new sources of value.
attendant:
- - tag: Boundary Risk
+ - tag: Lock-In Risk
reason: "Design decisions can create boundaries that limit flexibility and adaptability."
- tag: Software Dependency Risk
reason: "Creates dependencies on software components and design patterns."
diff --git a/docs/practices/Planning-And-Management/Terms-Of-Reference.md b/docs/practices/Planning-And-Management/Terms-Of-Reference.md
index 04e53b989..088a25592 100644
--- a/docs/practices/Planning-And-Management/Terms-Of-Reference.md
+++ b/docs/practices/Planning-And-Management/Terms-Of-Reference.md
@@ -18,7 +18,7 @@ practice:
- tag: Coordination Risk
reason: "Provides a clear framework for coordination among team members and stakeholders."
attendant:
- - tag: Boundary Risk
+ - tag: Lock-In Risk
reason: "Poorly defined terms can create rigid boundaries that limit flexibility."
- tag: Coordination Risk
reason: "Requires alignment and coordination among all parties to agree to the terms."
diff --git a/docs/presentations/AgileVsOpenSource/index.md b/docs/presentations/AgileVsOpenSource/index.md
index 9f5f6219f..703a38c69 100644
--- a/docs/presentations/AgileVsOpenSource/index.md
+++ b/docs/presentations/AgileVsOpenSource/index.md
@@ -128,7 +128,7 @@ hide_table_of_contents: true
For example, if I was building a twitter-based website for printing T-Shirts, I might use some twitter APIs, some OAuth2 login piece, an API for getting the T-Shirts printed, and some kind of payments API like Stripe.
-
One really key risk then for me is what I call Boundary Risk: can I get all those dependencies to behave together in a cohesive manner. What happens when the dependencies change? Will they all co-operate in the way I want.
+
One really key risk then for me is what I call Lock-In Risk: can I get all those dependencies to behave together in a cohesive manner. What happens when the dependencies change? Will they all co-operate in the way I want.
If some of my libraries are written in Java, and some in C++, will I be in the situation above where I’m trying to join Lego with those sticklebrick things on the left?
@@ -136,7 +136,7 @@ hide_table_of_contents: true
One tennet of Agile development is do “the simplest thing that could possibly work”.
-
But is that going to lead you into this Boundary Risk problem? Are you going to try to combine things that just don’t work together?
+
But is that going to lead you into this Lock-In Risk problem? Are you going to try to combine things that just don’t work together?
This goes back to that whole “Meta-Game” idea that I was talking about earlier.
@@ -170,7 +170,7 @@ hide_table_of_contents: true
-
So this Boundary Risk problem is getting worse over time. Every day there are more and more Open Source libraries to choose from. No one has time to evaluate even a tiny fraction of them.
+
So this Lock-In Risk problem is getting worse over time. Every day there are more and more Open Source libraries to choose from. No one has time to evaluate even a tiny fraction of them.
I call this the “Broccoli Problem”. To start with, on the left, we had computers, which did.. well, computing.
diff --git a/docs/risks/Complexity-Risk/Complexity-Risk.md b/docs/risks/Complexity-Risk/Complexity-Risk.md
index 886c27f1a..5ca26e455 100644
--- a/docs/risks/Complexity-Risk/Complexity-Risk.md
+++ b/docs/risks/Complexity-Risk/Complexity-Risk.md
@@ -43,7 +43,7 @@ It's the early 2000s: your Pokémon website is becoming really popular and profi
-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/Boundary-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
diff --git a/docs/risks/Complexity-Risk/Kolmogorov-Complexity.md b/docs/risks/Complexity-Risk/Kolmogorov-Complexity.md
index 361fb1ca8..1e836c718 100644
--- a/docs/risks/Complexity-Risk/Kolmogorov-Complexity.md
+++ b/docs/risks/Complexity-Risk/Kolmogorov-Complexity.md
@@ -92,4 +92,4 @@ In the third version of the program, we used the method `.repeat()`, which allow
-So as the above diagram shows, we can also reduce [Codebase Risk](/tags/Codebase-Risk) in our choice of _languages_ and _third party libraries_. 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 [Boundary Risk](/tags/Boundary-Risk) instead.
+So as the above diagram shows, we can also reduce [Codebase Risk](/tags/Codebase-Risk) in our choice of _languages_ and _third party libraries_. 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.
diff --git a/docs/risks/Dependency-Risks/Boundary-Risk.md b/docs/risks/Dependency-Risks/Boundary-Risk.md
deleted file mode 100644
index fdcd33478..000000000
--- a/docs/risks/Dependency-Risks/Boundary-Risk.md
+++ /dev/null
@@ -1,225 +0,0 @@
----
-title: Boundary Risk
-description: Risks due to the commitments we make around dependencies, and the limitations they place on our ability to change.
-
-slug: /risks/Boundary-Risk
-featured:
- class: c
- element: ''
-sidebar_position: 6
-tags:
- - Risks
- - Boundary Risk
-tweet: yes
-part_of: Dependency Risk
----
-
-
-
-In the previous sections on [Dependency Risk](/tags/Dependency-Risk) we've touched on [Boundary Risk](/tags/Boundary-Risk) several times, but now it's time to tackle it head-on and discuss this important type of risk.
-
-
-
-As shown in the above diagram, [Boundary Risk](/tags/Boundary-Risk) is the risk we face due to _commitments_ around dependencies and the limitations they place on our ability to change. To illustrate, lets consider two examples:
-
-- Although I eat cereals for breakfast, I don't have [Boundary Risk](/tags/Boundary-Risk) on them. If the supermarket runs out of cereals when I go, I can just buy some other food and eat that.
-- However the hot water system in my house uses gas. If that's not available I can't just switch to using oil or solar without cost. There is [Boundary Risk](/tags/Boundary-Risk), but it's low because the supply of gas is plentiful and seems like it will stay that way.
-
-In terms of the [Risk Landscape](/risks/Risk-Landscape), [Boundary Risk](/tags/Boundary-Risk) is exactly as it says: a _boundary_, _wall_ or other kind of obstacle in your way to making a move you want to make. This changes the nature of the [Risk Landscape](/tags/Risk-Landscape), and introduces a maze-like component to it. It also means that we have to make _commitments_ about which way to go, knowing that our future paths are constrained by the decisions we make.
-
-As we discussed in [Complexity Risk](/tags/Complexity-Risk), there is always the chance we end up at a [Dead End](/tags/Dead-End-Risk), having done work that we need to throw away. In this case, we'll have to head back and make a different decision.
-
-## In Software Development
-
-In software development, although we might face [Boundary Risk](/tags/Boundary-Risk) choosing staff or offices, most of the everyday dependency commitments we have to make are around _abstractions_.
-
-As discussed in [Software Dependency Risk](/tags/Software-Dependency-Risk), if we are going to use a software tool as a dependency, we have to accept the complexity of its [protocols](/tags/Protocol-Risk). You have to use its protocol: it won't come to you.
-
-
-
-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'.
- - We could use library 'b', using the [Protocols](/tags/Protocol-Risk) of 'b', and having a dependency on 'b'.
- - We could use neither, and avoid the dependency, but potentially pick up lots more [Codebase Risk](/tags/Codebase-Risk) and [Schedule Risk](/tags/Schedule-Risk) because we have to code our own alternative to 'a' and 'b'.
-
-The choice of approach presents us with [Boundary Risk](/tags/Boundary-Risk) 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:
-
- - Maybe 'a' has some undocumented drawbacks that are going to hold us up.
- - Maybe 'b' works on some streaming API basis, that is incompatible with the input protocol.
- - Maybe 'a' runs on Windows, whereas our code runs on Linux
-
-... and so on.
-
-This is a toy example, but in real life this dilemma occurs when we choose between database vendors, cloud hosting platforms, operating systems, software libraries etc. and it was a big factor in our analysis of [Software Dependency Risk](/tags/Software-Dependency-Risk).
-
-## Factors In Boundary Risk
-
-The degree of [Boundary Risk](/tags/Boundary-Risk) is dependent on a number of factors:
-
- - **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.
- - **Life Expectancy**: libraries and products come and go. A choice that was popular when it was made may be superseded in the future by something better. (_cf._ [Market Risk](/tags/Market-Risk)). This may not be a problem until you try to renew a support contract, or try to do an operating system update. Although no-one can predict how long a technology will last, [The Lindy Effect](https://en.wikipedia.org/wiki/Lindy_effect) suggests that _future life expectancy is proportional to current age_. So, you might expect a technology that has been around for ten years to be around for a further ten.
- - **The level of [Lock In](#ecosystems-and-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.
- - **Future needs**: will the dependency satisfy your expanding requirements going forward? (_cf._ [Feature Drift Risk](/tags/Feature-Drift-Risk))
- - **Ownership changes:** Microsoft buys [GitHub](https://en.wikipedia.org/wiki/GitHub). What will happen to the ecosystem around GitHub now?
- - **Licensing changes:** (e.g. [Oracle](https://oracle.com) buys Tangosol who make [Coherence](https://en.wikipedia.org/wiki/Oracle_Coherence) for example). 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.
-
-## 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.
-
-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).
- - They both use a [LAMP (Linux, Apache, MySql, PHP) Stack](https://en.wikipedia.org/wiki/LAMP_(software_bundle)).
- - They were both started around the same time (2001 for Drupal, 2003 for WordPress).
- - They are both Open-Source, and have a wide variety of [_plugins_](https://en.wikipedia.org/wiki/Plug-in_(computing)), that is, ways for other programmers to extend the functionality in new directions.
-
-But crucially, the underlying abstractions of WordPress and Drupal are different, so the plugins available for each are different. The quality and choice of plugins for a given platform, along with factors such as community and online documentation, is often called its _ecosystem_:
-
-> "... 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.
-
-Ecosystem size is one key determinant of [Boundary Risk](/tags/Boundary-Risk):
-
-- **A large ecosystem** has a large boundary circumference. [Boundary Risk](/tags/Boundary-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
-
-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):
-
-> "... the positive effect described in economics and business that an additional user of a good or service has on the value of that product to others. When a network effect is present, the value of a product or service increases according to the number of others using it." - [Network Effect, _Wikipedia_](https://en.wikipedia.org/wiki/Network_effect)
-
-](/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%.
-
-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).
-
-But, by now, if they _are_ to be compared side-by-side, WordPress _might be better_ due to the sheer number of people in this ecosystem who are...
-
- - Creating web sites.
- - Using those sites.
- - Submitting bug requests.
- - Fixing bugs.
- - Writing documentation.
- - Building plugins.
- - Creating features.
- - Improving the core platform.
-
-But is bigger always better? Perhaps not.
-
-### 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_:
-
-> "The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to their 'level of incompetence'." - [The Peter Principle, _Wikipedia_](https://en.wikipedia.org/wiki/Peter_principle)
-
-Although designed for _people_, it can just as easily be applied to any other dependency you can think of. This means when things get popular, there is a tendency towards [Conceptual Integrity Risk](/tags/Conceptual-Integrity-Risk) and [Complexity Risk](/tags/Complexity-Risk).
-
-
-
-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
-
-As we saw in [Software Dependency Risk](/tags/Software-Dependency-Risk), 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).
-
-Each new version has a greater functional scope than the one before (pushing back [Boundary Risk](/tags/Boundary-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.
-
-
-
-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 [Learning Curve Risk](/tags/Learning-Curve-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.
-
-## Managing Boundary Risk
-
-Let's look at two ways in which we can manage [Boundary Risk](/tags/Boundary-Risk): _bridges_ and _standards_.
-
-### Ecosystem 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.
-
-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 [Boundary Risk](/tags/Boundary-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.
-
-|Protocol Risk From A |Protocol Risk From B |Resulting Bridge Complexity |Example |
-|-----------------------------|----------------------------|-----------------------------|---------------------------------------------------------|
-|Low |Low |Simple |Changing from one date format to another. |
-|High |Low |Moderate |Status Dashboard. |
-|High |High |Complex |Object-Relational Mapping (ORM) Tools. |
-
-
-
-From examining the [Protocol Risk](/tags/Protocol-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.
-
-### Standards
-
-Standards mitigate [Boundary Risk](/tags/Boundary-Risk) in one of two ways:
-
-1. **Abstract over the ecosystems.** Provide a _standard_ protocol (a _lingua franca_) which can be converted down into the protocol of any of a number of competing ecosystems.
-
- - The [C](https://en.wikipedia.org/wiki/C_(programming_language)) programming language provided a way to get the same programs compiled against different CPU instruction sets, therefore providing some _portability_ to code.
-
- - [Java](https://en.wikipedia.org/wiki/Java_(programming_language)) took what C did and went one step further, providing interoperability at the library level. Java code could run anywhere where Java was installed.
-
-2. **Force adoption.** All of the ecosystems start using the standard for fear of being left out in the cold. Sometimes, a standards body is involved, but other times a "de facto" standard emerges that everyone adopts.
-
- - [ASCII](https://en.wikipedia.org/wiki/ASCII): fixed the different-character-sets [Boundary Risk](/tags/Boundary-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.
-
-## Boundary Risk Cycle
-
-
-
-[Boundary Risk](/tags/Boundary-Risk) seems to progress in cycles. As a piece of technology becomes more mature, there are more standards and bridges, and [Boundary Risk](/tags/Boundary-Risk) is lower. Once [Boundary Risk](/tags/Boundary-Risk) is low and a particular approach is proven, there will be innovation upon this, giving rise to new opportunities for [Boundary Risk](/tags/Boundary-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 [Boundary Risk](/tags/Boundary-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.
-
-
-## Everyday Boundary Risks
-
-Although ecosystems are one very pernicious type of boundary in software development, it's worth pointing out that [Boundary Risk](/tags/Boundary-Risk) occurs all the time. Let's look at some ways:
-
-- **Configuration**. When software has to be deployed onto a server, there has to be configuration (usually on the command line, or via configuration property files) in order to bridge the boundary between the _environment it's running in_ and the _software being run_. Often this is setting up file locations, security keys and passwords, and telling it where to find other files and services.
-
-- **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 [Boundary Risk](/tags/Boundary-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 [protocol risk](/tags/Protocol-Risk): 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.
-
-- **Teams**. if you're asked to build a new tool for an existing team, are you creating [Boundary Risk](/tags/Boundary-Risk) by using tools that the team aren't familiar with?
-
-- **Organisations**. Getting teams or departments to work with each other often involves breaking down [Boundary Risk](/tags/Boundary-Risk). Often the departments use different tool-sets or processes, and have different goals making the translation harder.
-
-## Patterns In Boundary Risk
-
-In [Feature Risk](/tags/Feature-Drift-Risk), we saw that the features people need change over time. Let's get more specific about this:
-
-- **Human need is [Fractal](https://en.wikipedia.org/wiki/Fractal)**: this means that over time, software products have evolved to more closely map human needs. Software that would have delighted us ten years ago lacks the sophistication we expect today.
-- **Software and hardware are both improving with time**: due to evolution and the ability to support greater and greater levels of complexity.
-- **Abstractions accrete too**: as we saw in [Process Risk](/tags/Process-Risk), we _encapsulate_ earlier abstractions in order to build later ones.
-
-The only thing we can expect in the future is that the lifespan of any ecosystem will follow the arc shown in the above diagram, through creation, adoption, growth, use and finally either be abstracted over or abandoned.
-
-Although our discipline is a young one, we should probably expect to see "Software Archaeology" in the same way as we see it for biological organisms. Already we can see the dead-ends in the software evolutionary tree: COBOL and BASIC languages, CASE systems. Languages like FORTH live on in PostScript, SQL is still embedded in everything
-
-Let's move on now to the last [Dependency Risk](/tags/Dependency-Risk) section, and look at [Agency Risk](/tags/Agency-Risk).
-
diff --git a/docs/risks/Dependency-Risks/Dependency-Risks.md b/docs/risks/Dependency-Risks/Dependency-Risks.md
index db1887a9f..2bc9440f5 100644
--- a/docs/risks/Dependency-Risks/Dependency-Risks.md
+++ b/docs/risks/Dependency-Risks/Dependency-Risks.md
@@ -28,7 +28,7 @@ In order to avoid repetition, and also to break down this large topic, we're goi
- We'll cover [Deadline Risk](/tags/Deadline-Risk), and discuss the purpose of Events and Deadlines, and how they enable us to coordinate around dependency use.
- Then, we'll move on to look specifically at [Software Dependency Risk](/tags/Software-Dependency-Risk), covering using libraries, software services and building on top of the work of others.
- Then, we'll take a look at [Process Risk](/tags/Process-Risk), which is still [Dependency Risk](/tags/Dependency-Risk), but we'll be considering more organisational factors and how bureaucracy comes into the picture.
- - After that, we'll take a closer look at [Boundary Risk](/tags/Boundary-Risk) and [Dead-End Risk](/tags/Dead-End-Risk). These are the risks you face in making choices about what to depend on.
+ - After that, we'll take a closer look at [Lock-In Risk](/tags/Lock-In-Risk) and [Dead-End Risk](/tags/Dead-End-Risk). These are the risks you face in making choices about what to depend on.
- Finally, we'll wrap up this analysis with a look at some of the specific problems around depending on other people or businesses in [Agency Risk](/tags/Agency-Risk).
## Why Have Dependencies?
diff --git a/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md b/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md
index affd41ea5..65f463576 100644
--- a/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md
+++ b/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md
@@ -8,7 +8,7 @@ slug: /risks/Funding-Risk
featured:
class: c
element: ''
-sidebar_position: 1
+sidebar_position: 3
tweet: yes
tags:
- Risks
diff --git a/docs/risks/Dependency-Risks/Funding-Risk/_category_.yaml b/docs/risks/Dependency-Risks/Funding-Risk/_category_.yaml
index 68cdf5241..2c2a62a3f 100644
--- a/docs/risks/Dependency-Risks/Funding-Risk/_category_.yaml
+++ b/docs/risks/Dependency-Risks/Funding-Risk/_category_.yaml
@@ -1,4 +1,4 @@
-position: 2
+position: 3
link:
type: doc
id: Funding-Risk
\ 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
new file mode 100644
index 000000000..23eb2e4a7
--- /dev/null
+++ b/docs/risks/Dependency-Risks/Lock-In-Risk/Ecosystems.md
@@ -0,0 +1,73 @@
+
+
+
+## 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.
+
+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).
+ - They both use a [LAMP (Linux, Apache, MySql, PHP) Stack](https://en.wikipedia.org/wiki/LAMP_(software_bundle)).
+ - They were both started around the same time (2001 for Drupal, 2003 for WordPress).
+ - They are both Open-Source, and have a wide variety of [_plugins_](https://en.wikipedia.org/wiki/Plug-in_(computing)), that is, ways for other programmers to extend the functionality in new directions.
+
+But crucially, the underlying abstractions of WordPress and Drupal are different, so the plugins available for each are different. The quality and choice of plugins for a given platform, along with factors such as community and online documentation, is often called its _ecosystem_:
+
+> "... 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.
+
+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
+
+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):
+
+> "... the positive effect described in economics and business that an additional user of a good or service has on the value of that product to others. When a network effect is present, the value of a product or service increases according to the number of others using it." - [Network Effect, _Wikipedia_](https://en.wikipedia.org/wiki/Network_effect)
+
+](/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%.
+
+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).
+
+But, by now, if they _are_ to be compared side-by-side, WordPress _might be better_ due to the sheer number of people in this ecosystem who are...
+
+ - Creating web sites.
+ - Using those sites.
+ - Submitting bug requests.
+ - Fixing bugs.
+ - Writing documentation.
+ - Building plugins.
+ - Creating features.
+ - Improving the core platform.
+
+But is bigger always better? Perhaps not.
+
+### 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_:
+
+> "The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to their 'level of incompetence'." - [The Peter Principle, _Wikipedia_](https://en.wikipedia.org/wiki/Peter_principle)
+
+Although designed for _people_, it can just as easily be applied to any other dependency you can think of. This means when things get popular, there is a tendency towards [Conceptual Integrity Risk](/tags/Conceptual-Integrity-Risk) and [Complexity Risk](/tags/Complexity-Risk).
+
+
+
+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
+
+As we saw in [Software Dependency Risk](/tags/Software-Dependency-Risk), 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).
+
+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.
+
+
+
+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 [Learning Curve Risk](/tags/Learning-Curve-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.
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
new file mode 100644
index 000000000..c447655ac
--- /dev/null
+++ b/docs/risks/Dependency-Risks/Lock-In-Risk/Lock-In-Risk.md
@@ -0,0 +1,112 @@
+---
+title: Lock-In Risk
+description: Risks due to the commitments we make around dependencies, and the limitations they place on our ability to change.
+
+slug: /risks/Lock-In-Risk
+featured:
+ class: c
+ element: ''
+sidebar_position: 6
+tags:
+ - Risks
+ - Lock-In Risk
+tweet: yes
+part_of: Dependency Risk
+---
+
+
+
+In the previous sections on [Dependency Risk](/tags/Dependency-Risk) we've touched on [Lock-In Risk](/tags/Lock-In-Risk) several times, but now it's time to tackle it head-on and discuss this important type of risk.
+
+
+
+As shown in the above diagram, [Lock-In Risk](/tags/Lock-In-Risk) is the risk we face due to _commitments_ around dependencies and the limitations they place on our ability to change. To illustrate, lets consider two examples:
+
+- Although I eat cereals for breakfast, I don't have [Lock-In Risk](/tags/Lock-In-Risk) on them. If the supermarket runs out of cereals when I go, I can just buy some other food and eat that.
+- However the hot water system in my house uses gas. If that's not available I can't just switch to using oil or solar without cost. There is [Lock-In Risk](/tags/Lock-In-Risk), but it's low because the supply of gas is plentiful and seems like it will stay that way.
+
+When we have to make _commitments_ around dependencies our future paths are constrained by the decisions we make. In terms of the [Risk Landscape](/risks/Risk-Landscape), [Lock-In Risk](/tags/Lock-In-Risk) is a _boundary_, _wall_ or other kind of obstacle in your way to making a move you want to make. This changes the nature of the [Risk Landscape](/tags/Risk-Landscape), and introduces a maze-like component to it.
+
+## Worked Example
+
+In software development, although we might face [Lock-In Risk](/tags/Lock-In-Risk) choosing staff or offices, most of the everyday dependency commitments we have to make are around _abstractions_.
+
+
+
+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 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:
+
+ - Maybe 'a' has some undocumented drawbacks that are going to hold us up.
+ - Maybe 'b' works on some streaming API basis, that is incompatible with the input protocol.
+ - Maybe 'a' runs on Windows, whereas our code runs on Linux
+
+... and so on.
+
+After having chosen either 'a', 'b' or even our own approach, we have significant sunk costs and are committed to the implementation - changing to another option is going to be expensive and means we have to re-trace our steps.
+
+This is a toy example, but in real life this dilemma occurs when we choose between database vendors, cloud hosting platforms, operating systems, software libraries etc. and is a big factor in our analysis of [Software Dependency Risks](/tags/Software-Dependency-Risk).
+
+## Everyday Lock-In Risks
+
+Although ecosystems are one very pernicious type of boundary in software development, it's worth pointing out that [Lock-In Risk](/tags/Lock-In-Risk) occurs all the time. Let's look at some ways:
+
+- **Configuration**. When software has to be deployed onto a server, there has to be configuration (usually on the command line, or via configuration property files) in order to bridge the boundary between the _environment it's running in_ and the _software being run_. Often this is setting up file locations, security keys and passwords, and telling it where to find other files and services.
+
+- **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 [protocol risk](/tags/Protocol-Risk): 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.
+
+- **Teams**. if you're asked to build software, do you use the tools familiar to your team, or choose unfamiliar but perhaps more appropriate tools? If the latter, are you creating [Lock-In Risk](/tags/Lock-In-Risk) by using tools that the team aren't familiar with?
+
+- **Organisations**. Getting teams or departments to work with each other often involves breaking down [Lock-In Risk](/tags/Lock-In-Risk). Often the departments use different tool-sets or processes, and have different goals making the translation from one department to another harder (the so-called [Silo](https://en.wikipedia.org/wiki/Information_silo) effect).
+
+
+
+## Factors Affecting Lock-In Risk
+
+### 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.
+
+**Threat**: Although you can anticipate the level of commitment, choosing a dependency in advance is a [bet](/tags/Bet) where you have limited information.
+
+### 2. Life Expectancy
+
+Softare libraries and products come and go. A choice that was popular when it was made may be superseded in the future by something better. (_cf._ [Market Risk](/tags/Market-Risk)). This may not be a problem until you try to renew a support contract, or try to do an operating system update. Although no-one can predict how long a technology will last, [The Lindy Effect](https://en.wikipedia.org/wiki/Lindy_effect) suggests that _future life expectancy is proportional to current age_. So, you might expect a technology that has been around for ten years to be around for a further ten.
+
+**Threat**: Committing to new technologies when they have an unproven track record.
+
+### 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.
+
+**Threat**: Pervasive commitments (e.g. around language choices) have much higher levels of Lock-In Risk.
+
+### 4. Future-Proofing
+
+Will the dependency satisfy your expanding requirements going forward? It's often dangerous to make commitments based on the status quo when a project is evolving.
+
+**Threat**: Making a commitment may limit _flexibility_ for changing needs in the future.
+
+### 5. Ownership Changes
+
+**Example:** Microsoft buys [GitHub](https://en.wikipedia.org/wiki/GitHub). What will happen to the ecosystem around GitHub now? Is it improved or worsened by new ownership?
+
+**Threat**: Making commitments to dependencies where the ownership of the dependency can change increases risk.
+
+### 6. Licensing Changes
+
+**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)).
+
+
+
+
diff --git a/docs/risks/Dependency-Risks/Lock-In-Risk/Managing.md b/docs/risks/Dependency-Risks/Lock-In-Risk/Managing.md
new file mode 100644
index 000000000..3868b251e
--- /dev/null
+++ b/docs/risks/Dependency-Risks/Lock-In-Risk/Managing.md
@@ -0,0 +1,60 @@
+
+
+
+## Managing Lock-In Risk
+
+Let's look at two ways in which we can manage [Lock-In Risk](/tags/Lock-In-Risk): _bridges_ and _standards_.
+
+### Ecosystem 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.
+
+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.
+
+|Protocol Risk From A |Protocol Risk From B |Resulting Bridge Complexity |Example |
+|-----------------------------|----------------------------|-----------------------------|---------------------------------------------------------|
+|Low |Low |Simple |Changing from one date format to another. |
+|High |Low |Moderate |Status Dashboard. |
+|High |High |Complex |Object-Relational Mapping (ORM) Tools. |
+
+
+
+From examining the [Protocol Risk](/tags/Protocol-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.
+
+### Standards
+
+Standards mitigate [Lock-In Risk](/tags/Lock-In-Risk) in one of two ways:
+
+1. **Abstract over the ecosystems.** Provide a _standard_ protocol (a _lingua franca_) which can be converted down into the protocol of any of a number of competing ecosystems.
+
+ - The [C](https://en.wikipedia.org/wiki/C_(programming_language)) programming language provided a way to get the same programs compiled against different CPU instruction sets, therefore providing some _portability_ to code.
+
+ - [Java](https://en.wikipedia.org/wiki/Java_(programming_language)) took what C did and went one step further, providing interoperability at the library level. Java code could run anywhere where Java was installed.
+
+2. **Force adoption.** All of the ecosystems start using the standard for fear of being left out in the cold. Sometimes, a standards body is involved, but other times a "de facto" standard emerges that everyone adopts.
+
+ - [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](/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.
+
\ No newline at end of file
diff --git a/docs/risks/Dependency-Risks/Lock-In-Risk/_category_.yaml b/docs/risks/Dependency-Risks/Lock-In-Risk/_category_.yaml
new file mode 100644
index 000000000..74de82f87
--- /dev/null
+++ b/docs/risks/Dependency-Risks/Lock-In-Risk/_category_.yaml
@@ -0,0 +1,4 @@
+position: 9
+link:
+ type: doc
+ id: Lock-In-Risk
\ No newline at end of file
diff --git a/docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md b/docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md
index 0475383c7..6faa846db 100644
--- a/docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md
+++ b/docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md
@@ -25,7 +25,7 @@ This implies that there is a tendency for organisations to end up with _needless
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).
+Next in the tour of [Dependency Risks](/tags/Dependency-Risk), it's time to look at [Lock-In Risk](/tags/Lock-In-Risk).
diff --git a/docs/risks/Dependency-Risks/Schedule-Risk/_category_.yaml b/docs/risks/Dependency-Risks/Schedule-Risk/_category_.yaml
new file mode 100644
index 000000000..b3b4f731e
--- /dev/null
+++ b/docs/risks/Dependency-Risks/Schedule-Risk/_category_.yaml
@@ -0,0 +1,4 @@
+position: 2
+link:
+ type: doc
+ id: Schedule-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-Risks/Software-Dependency-Risk.md
similarity index 95%
rename from docs/risks/Dependency-Risks/Software-Dependency-Risk.md
rename to docs/risks/Dependency-Risks/Software-Dependency-Risks/Software-Dependency-Risk.md
index 84446d34f..3edcaaef4 100644
--- a/docs/risks/Dependency-Risks/Software-Dependency-Risk.md
+++ b/docs/risks/Dependency-Risks/Software-Dependency-Risks/Software-Dependency-Risk.md
@@ -1,21 +1,17 @@
---
-title: Software Dependency Risk
-description: Specific dependency risks due to relying on software.
+title: Software Dependency Risks
+description: Specific risks due to relying on software as a dependency.
-slug: /risks/Software-Dependency-Risk
+slug: /risks/Software-Dependency-Risks
featured:
class: c
element: ''
sidebar_position: 4
tweet: yes
tags:
- - Risks
- Software Dependency Risk
-part_of: 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 Risk](/tags/Dependency-Risk).
@@ -195,7 +191,7 @@ In essence, this is Conway's Law:
By choosing a particular software library, we are making a move on the [Risk Landscape](/risks/Risk-Landscape) in the hope of moving to a place with more favourable risks. Typically, using library code offers a [Schedule Risk](/tags/Schedule-Risk) and [Complexity Risk](/tags/Complexity-Risk) Silver Bullet - a high-speed route over the risk landscape to somewhere nearer where we want to be. But, in return we expect to pick up:
- **[Communication Risk](/tags/Communication-Risk)**: because we now have to learn how to communicate with this new dependency.
-- **[Boundary Risk](/tags/Boundary-Risk)**: - because now are limited to using the functionality provided by this dependency. We have chosen it over alternatives and changing to something else would be more work and therefore costly.
+- **[Lock-In Risk](/tags/Lock-In-Risk)**: - because now are limited to using the functionality provided by this dependency. We have chosen it over alternatives and changing to something else would be more work and therefore costly.
But, it's quite possible that we could wind up in a worse place than we started out, by using a library that's out-of-date, riddled with bugs or badly supported. i.e. full of new, hidden [Feature Risk](/tags/Feature-Risk).
@@ -216,7 +212,7 @@ But, leaving that aside, let's try to build a model of what this decision making
In the table above, I am summarising three different sources (linked at the end of the section), which give descriptions of which factors to look for when choosing open-source libraries. Here are some take-aways:
- **[Feature Risk](/tags/Feature-Risk) is a big concern**: How can you be sure that the project will do what you want it to do ahead of schedule? Will it contain bugs or missing features? By looking at factors like _release frequency_ and _size of the community_ you get a good feel for this which is difficult to fake.
- - **[Boundary Risk](/tags/Boundary-Risk) is also very important**: You are going to have to _live_ with your choices for the duration of the project, so it's worth spending the effort to either ensure that you're not going to regret the decision, or that you can change direction later.
+ - **[Lock-In Risk](/tags/Lock-In-Risk) is also very important**: You are going to have to _live_ with your choices for the duration of the project, so it's worth spending the effort to either ensure that you're not going to regret the decision, or that you can change direction later.
- **Third is [Communication Risk](/tags/Communication-Risk)**: how well does the project deal with its users? If a project is "famous", then it has communicated its usefulness to a wide, appreciative audience. Avoiding [Communication Risk](/tags/Communication-Risk) is also a good reason to pick _tools you are already familiar with_.
@@ -253,7 +249,7 @@ The diagram above summarises the risks raised in some of the available literatur
- Clearly, [Operational Risk](/tags/Operational-Risk) is now a big concern. By depending on a third-party organisation you are tying yourself to its success or failure in a much bigger way than just by using a piece of open-source software. What happens to data security, both in the data centre and over the Internet? Although you might choose a SaaS solution to mitigate _internal_ [Operational Risk](/tags/Operational-Risk), you might just be "throwing it over the wall" to a third party, who might do a worse job.
- With [Feature Risk](/tags/Feature-Risk) you now have to contend with the fact that the software will be upgraded _outside your control_, and you may have limited control over which features get added or changed.
-- [Boundary Risk](/tags/Boundary-Risk) is also a different proposition: you are tied to the software provider by _a contract_. If the service changes in the future, or isn't to your liking, you can't simply fork the code (like you could with an open source project).
+- [Lock-In Risk](/tags/Lock-In-Risk) is also a different proposition: you are tied to the software provider by _a contract_. If the service changes in the future, or isn't to your liking, you can't simply fork the code (like you could with an open source project).
@@ -276,8 +272,8 @@ Let's expand this view slightly and look at where different pieces of software s
-- Where there is value in **the [Network Effect](https://en.wikipedia.org/wiki/Network_effect)** it's often a sign that the software will be free, or open source: programming languages and Linux are the obvious examples of this. Bugs are easier to find when there are lots of eyes looking, and learning the skill to use the software has less [Boundary Risk](/tags/Boundary-Risk) if you know you'll be able to use it at any point in the future.
-- At the other end of the spectrum, clients will happily pay for software if it clearly **reduces [Operational Risk](/tags/Operational-Risk)**. Take [Amazon Web Services (AWS)](https://en.wikipedia.org/wiki/Amazon_Web_Services). The essential trade here is that you substitute the complexity of hosting and maintaining various pieces of hardware, in exchange for metered payments ([Funding Risk](/tags/Funding-Risk) for you). Since the AWS _interfaces_ are specific to Amazon, there is significant [Boundary Risk](/tags/Boundary-Risk) in choosing this option.
+- Where there is value in **the [Network Effect](https://en.wikipedia.org/wiki/Network_effect)** it's often a sign that the software will be free, or open source: programming languages and Linux are the obvious examples of this. Bugs are easier to find when there are lots of eyes looking, and learning the skill to use the software has less [Lock-In Risk](/tags/Lock-In-Risk) if you know you'll be able to use it at any point in the future.
+- At the other end of the spectrum, clients will happily pay for software if it clearly **reduces [Operational Risk](/tags/Operational-Risk)**. Take [Amazon Web Services (AWS)](https://en.wikipedia.org/wiki/Amazon_Web_Services). The essential trade here is that you substitute the complexity of hosting and maintaining various pieces of hardware, in exchange for metered payments ([Funding Risk](/tags/Funding-Risk) for you). Since the AWS _interfaces_ are specific to Amazon, there is significant [Lock-In Risk](/tags/Lock-In-Risk) in choosing this option.
- In the middle there are lots of **substitute options** and therefore high competition. Because of this prices are pushed towards zero and therefore often advertising is used to monetise the product. [Angry Birds](https://en.wikipedia.org/wiki/Angry_Birds) is a classic example: initially, it had demo and paid versions, however [Rovio](https://en.wikipedia.org/wiki/Rovio_Entertainment) discovered there was much more money to be made through advertising than from the [paid-for app](https://www.deconstructoroffun.com/blog/2017/6/11/how-angry-birds-2-multiplied-quadrupled-revenue-in-a-year).
## Choice
@@ -288,4 +284,4 @@ Choosing dependencies can be extremely difficult. As we discussed above, the us
Having chosen a dependency, whether or not you end up in a more favourable position risk-wise is going to depend heavily on the quality of the execution and the skill of the implementor. With software dependencies we often have to live with the decisions we make for a long time: _choosing_ the software dependency is far easier than _changing it later_.
-Let's take a closer look at this problem in the section on [Boundary Risk](/tags/Boundary-Risk). But first, lets looks at [processes](/tags/Process-Risk).
+Let's take a closer look at this problem in the section on [Lock-In Risk](/tags/Lock-In-Risk). But first, lets looks at [processes](/tags/Process-Risk).
diff --git a/docs/risks/Dependency-Risks/Software-Dependency-Risks/_category_.yaml b/docs/risks/Dependency-Risks/Software-Dependency-Risks/_category_.yaml
new file mode 100644
index 000000000..903987b60
--- /dev/null
+++ b/docs/risks/Dependency-Risks/Software-Dependency-Risks/_category_.yaml
@@ -0,0 +1,4 @@
+position: 10
+link:
+ type: doc
+ id: Software-Dependency-Risk
\ No newline at end of file
diff --git a/docs/risks/Internal-Model-Risk/Metrics.md b/docs/risks/Internal-Model-Risk/Metrics.md
index 7584da79e..a1106d050 100644
--- a/docs/risks/Internal-Model-Risk/Metrics.md
+++ b/docs/risks/Internal-Model-Risk/Metrics.md
@@ -75,5 +75,5 @@ But how does [Map and Territory Risk](/tags/Map-And-Territory-Risk) apply across
So concepts and abstractions spread through an audience. But what happens next?
- - People will use and abuse new ideas up to the point when they start breaking down. (We also discussed this as the **Peter Principle** in [Boundary Risk](/tags/Boundary-Risk).)
+ - People will use and abuse new ideas up to the point when they start breaking down. (We also discussed this as the **Peter Principle** in [Lock-In Risk](/tags/Lock-In-Risk).)
- At the same time, reality itself _evolves_ in response to the idea: the new idea displaces old ones, behaviour changes, and the idea itself can change.
diff --git a/docs/risks/Operational-Risk.md b/docs/risks/Operational-Risk.md
index faad489f5..d0d7aed09 100644
--- a/docs/risks/Operational-Risk.md
+++ b/docs/risks/Operational-Risk.md
@@ -119,9 +119,9 @@ Since our operation exists in a world of risks like [Red Queen Risk](/tags/Red-Q
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.
-You might think that for an IT operation, tasks like [Design](#design) belong within a separate "Development" function within an organisation. Traditionally, this might have been the case. However separating Development from Operations implies [Boundary Risk](/tags/Boundary-Risk) between these two functions. For example, the developers might employ different tools, equipment and processes to the Operations team resulting in a mismatch when software is delivered.
+You might think that for an IT operation, tasks like [Design](#design) belong within a separate "Development" function within an organisation. Traditionally, this might have been the case. However separating Development from Operations implies [Lock-In Risk](/tags/Lock-In-Risk) between these two functions. For example, the developers might employ different tools, equipment and processes to the Operations team resulting in a mismatch when software is delivered.
-In recent years the [DevOps](https://en.wikipedia.org/wiki/DevOps) movement has brought this [Boundary Risk](/tags/Boundary-Risk) into sharper focus. This specifically means:
+In recent years the [DevOps](https://en.wikipedia.org/wiki/DevOps) movement has brought this [Lock-In Risk](/tags/Lock-In-Risk) into sharper focus. This specifically means:
- 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.
diff --git a/docs/risks/Risk-Landscape.md b/docs/risks/Risk-Landscape.md
index 84adf30c1..aff0606fa 100644
--- a/docs/risks/Risk-Landscape.md
+++ b/docs/risks/Risk-Landscape.md
@@ -61,7 +61,7 @@ Below is a table outlining the different risks we'll see. There _is_ an order t
|[Deadline Risk](/tags/Deadline-Risk) |The risk of creating a dependency around a point in time.|
|[Software Dependency Risk](/tags/Software-Dependency-Risk)|The risk of depending on a software library, service or function.|
|[Process Risk](/tags/Process-Risk) |When you depend on a business process, or human process to give you something you need.|
-|[Boundary Risk](/tags/Boundary-Risk) |Risks due to making decisions that limit your choices later on. Sometimes, you go the wrong way on the [Risk Landscape](/risks/Risk-Landscape) and it's hard to get back to where you want to be.|
+|[Lock-In Risk](/tags/Lock-In-Risk) |Risks due to making decisions that limit your choices later on. Sometimes, you go the wrong way on the [Risk Landscape](/risks/Risk-Landscape) and it's hard to get back to where you want to be.|
|[Agency Risk](/tags/Agency-Risk) |Risks that staff have their own [Goals](/tags/Goal), which might not align with those of the project or team.|
|[Coordination Risk](/tags/Coordination-Risk) |Risks due to the fact that systems contain multiple agents, which need to work together.|
|[Map And Territory Risk](/tags/Map-And-Territory-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).)|
diff --git a/docs/risks/Staging-And-Classifying.md b/docs/risks/Staging-And-Classifying.md
index cc074585c..e66111889 100644
--- a/docs/risks/Staging-And-Classifying.md
+++ b/docs/risks/Staging-And-Classifying.md
@@ -30,7 +30,7 @@ If you've been reading closely, you'll notice that a number of themes come up ag
## The Power Of Abstractions
-[Abstraction](/tags/Abstraction) appears as a concept continually: in [Communication Risk](/tags/Communication-Risk), [Complexity Metrics](/risks/Complexity-Risk#kolmogorov-complexity), [Map and Territory Risk](/tags/Map-And-Territory-Risk) or how it causes [Boundary Risk](/tags/Boundary-Risk). We've looked at some complicated examples of abstractions, such as [network protocols](/tags/Protocol-Risk), [dependencies on technology](/tags/Software-Dependency-Risk) or [Business Processes](Process-Risk#the-purpose-of-process).
+[Abstraction](/tags/Abstraction) appears as a concept continually: in [Communication Risk](/tags/Communication-Risk), [Complexity Metrics](/risks/Complexity-Risk#kolmogorov-complexity), [Map and Territory Risk](/tags/Map-And-Territory-Risk) or how it causes [Lock-In Risk](/tags/Lock-In-Risk). We've looked at some complicated examples of abstractions, such as [network protocols](/tags/Protocol-Risk), [dependencies on technology](/tags/Software-Dependency-Risk) or [Business Processes](Process-Risk#the-purpose-of-process).
Let's now _generalize_ what is happening with abstraction. To do this, we'll consider the simplest example of abstraction: _naming a pattern_ of behaviour we see in the real world, such as "Binge Watching" or "Remote Working", or naming a category of insects as "Beetles".
@@ -54,7 +54,7 @@ As shown in the above diagram, _inventing a new abstraction_ means:
- **Mitigating [Feature Risk](/tags/Feature-Risk).** By _giving a name to something_ (or building a new product, or a way of working) you are offering up something that someone else can use. This should mitigate [Feature Risk](/tags/Feature-Risk) in the sense that other people can choose to use your it, if it fits their requirements.
- **Creating a [Protocol](/tags/Protocol-Risk).** Introducing _new words to a language_ creates [Protocol Risk](/tags/Protocol-Risk) as most people won't know what it means.
- **Increasing [Complexity Risk](/tags/Complexity-Risk).** Because, the more words we have, the more complex the language is.
-- **Creating the opportunity for [Boundary Risk](/tags/Boundary-Risk).** By naming something, you _implicitly_ create a boundary, because the world is now divided into "things which _are_ X" and "things which _are not_ X". _Boundary Risk arises from abstractions._
+- **Creating the opportunity for [Lock-In Risk](/tags/Lock-In-Risk).** By naming something, you _implicitly_ create a boundary, because the world is now divided into "things which _are_ X" and "things which _are not_ X". _Lock-In Risk arises from abstractions._
### Learning A New Abstraction
@@ -63,7 +63,7 @@ As shown in the above diagram, _inventing a new abstraction_ means:
As shown in the above diagram, _learning a new abstraction_ means:
- **Overcoming a [Learning Curve](/tags/Learning-Curve-Risk)**: because you have to _learn_ a name in order to use it (whether it is the name of a function, a dog, or someone at a party).
- - **Accepting [Boundary Risks](/tags/Boundary-Risk).** Commitment to one abstraction over another means that you have the opportunity cost of the other abstractions that you could have used.
+ - **Accepting [Lock-In Risks](/tags/Lock-In-Risk).** Commitment to one abstraction over another means that you have the opportunity cost of the other abstractions that you could have used.
- **Accepting [Map And Territory Risk](/tags/Map-And-Territory-Risk).** Because the word refers to the _concept_ of the thing, and _not the thing itself_.
Abstraction is everywhere and seems to be at the heart of what our brains do. But clearly, like [taking any other action](/tags/Take-Action) there is always trade-off in terms of risk.
diff --git a/docs/thinking/One-Size-Fits-No-One.md b/docs/thinking/One-Size-Fits-No-One.md
index 79db47ad8..3150ecaa8 100644
--- a/docs/thinking/One-Size-Fits-No-One.md
+++ b/docs/thinking/One-Size-Fits-No-One.md
@@ -99,7 +99,7 @@ Here are some high-level differences we see in some other popular methodologies:
- **[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.
- - **[DevOps](https://en.wikipedia.org/wiki/DevOps)**. Many software systems struggle at the [boundary](/tags/Boundary-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.
+ - **[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.
While this is a limited set of examples, you should be able to observe that the [actions](/tags/Take-Action) promoted by a methodology are contingent on the risks it considers important.
diff --git a/docs/thinking/Track-Risk.md b/docs/thinking/Track-Risk.md
index 5d24c8767..62d97ad73 100644
--- a/docs/thinking/Track-Risk.md
+++ b/docs/thinking/Track-Risk.md
@@ -63,7 +63,7 @@ We'll come back to this in a minute.
Arguably, Risk-First uses the term 'Risk' wrongly: most literature suggests [risk can be measured](https://keydifferences.com/difference-between-risk-and-uncertainty.html) whereas uncertainty represents things that cannot.
-I am using **risk** everywhere because later we will talk about specific risks (e.g. [Boundary Risk](/tags/Boundary-Risk) or [Complexity Risk](/tags/Complexity-Risk)) and it doesn't feel grammatically correct to talk about those as **uncertainties**.
+I am using **risk** everywhere because later we will talk about specific risks (e.g. [Lock-In Risk](/tags/Lock-In-Risk) or [Complexity Risk](/tags/Complexity-Risk)) and it doesn't feel grammatically correct to talk about those as **uncertainties**.
Additionally there is pre-existing usage in Banking of terms like [Operational Risk](https://en.wikipedia.org/wiki/Operational_risk) or [Reputational risk](https://www.investopedia.com/terms/r/reputational-risk.asp) which are also not really a-priori measurable.
diff --git a/src/images/generated/risks/posters/lock-in-risk.adl b/src/images/generated/risks/posters/lock-in-risk.adl
new file mode 100644
index 000000000..493b3cf51
--- /dev/null
+++ b/src/images/generated/risks/posters/lock-in-risk.adl
@@ -0,0 +1,26 @@
+
+
+
+
+
+
+
+
+ Commitment
+
+
+
+
+
+
diff --git a/static/img/generated/risks/posters/lock-in-risk.svg b/static/img/generated/risks/posters/lock-in-risk.svg
new file mode 100644
index 000000000..c023c7022
--- /dev/null
+++ b/static/img/generated/risks/posters/lock-in-risk.svg
@@ -0,0 +1,1831 @@
+
+
diff --git a/static/img/generated/single/risks/Lock-In-Risk.svg b/static/img/generated/single/risks/Lock-In-Risk.svg
new file mode 100644
index 000000000..06a1a8c9f
--- /dev/null
+++ b/static/img/generated/single/risks/Lock-In-Risk.svg
@@ -0,0 +1,1556 @@
+
+
diff --git a/static/img/generated/single/risks/Software-Dependency-Risks.svg b/static/img/generated/single/risks/Software-Dependency-Risks.svg
new file mode 100644
index 000000000..10d5f1145
--- /dev/null
+++ b/static/img/generated/single/risks/Software-Dependency-Risks.svg
@@ -0,0 +1,1568 @@
+
+
diff --git a/static/img/generated/titles/risks/Lock-In-Risk.png b/static/img/generated/titles/risks/Lock-In-Risk.png
new file mode 100644
index 000000000..a85458501
Binary files /dev/null and b/static/img/generated/titles/risks/Lock-In-Risk.png differ
diff --git a/static/img/generated/titles/risks/Software-Dependency-Risks.png b/static/img/generated/titles/risks/Software-Dependency-Risks.png
new file mode 100644
index 000000000..32cd04091
Binary files /dev/null and b/static/img/generated/titles/risks/Software-Dependency-Risks.png differ
diff --git a/unused_content/complexity/Towers-Of-Abstraction.md b/unused_content/complexity/Towers-Of-Abstraction.md
index 96c8a0ef2..09c1c9dd4 100644
--- a/unused_content/complexity/Towers-Of-Abstraction.md
+++ b/unused_content/complexity/Towers-Of-Abstraction.md
@@ -24,7 +24,7 @@ In [Crystals-And-Code](Crystals-And-Code.md) we looked at how a well-factored In
Here, we're going to look at [Towers Of Abstraction](Towers-Of-Abstraction.md). When we are modelling our concepts and building our Information Systems, we stand on the shoulders of giants, using libraries, frameworks and languages to make our lives easier.
-But as we discussed in [Boundary Risk](/tags/Boundary-Risk), using these abstractions comes at a cost: ecosystem lock-in. Once we have chosen our Towers of Abstraction, change is expensive.
+But as we discussed in [Lock-In Risk](/tags/Lock-In-Risk), using these abstractions comes at a cost: ecosystem lock-in. Once we have chosen our Towers of Abstraction, change is expensive.
## Conceptual Portability
diff --git a/unused_content/misc/Web3.md b/unused_content/misc/Web3.md
index 68c4a8297..472a61103 100644
--- a/unused_content/misc/Web3.md
+++ b/unused_content/misc/Web3.md
@@ -33,9 +33,9 @@ To understand this, we need to understand why it happens in the first place. T
-As shown in the above diagram, successful platforms beget success. This is how the big get bigger. This is why we see a power-law distribution of wealth in the world, and also why platforms like Wordpress are orders of magnitude more successful than its rivals like Drupal. As we discussed in Boundary Risk:
+As shown in the above diagram, successful platforms beget success. This is how the big get bigger. This is why we see a power-law distribution of wealth in the world, and also why platforms like Wordpress are orders of magnitude more successful than its rivals like Drupal. As we discussed in Lock-In Risk:
-> "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 the Network Effect." - [Boundary Risk, _Risk-First_](/tags/Boundary-Risk)
+> "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 the Network Effect." - [Lock-In Risk, _Risk-First_](/tags/Lock-In-Risk)
## Coordination Trumps Competition
