Skip to content

Commit

Permalink
Possible approach to adding red line narrative
Browse files Browse the repository at this point in the history
  • Loading branch information
andyblundell committed Mar 20, 2024
1 parent 9726ef4 commit db11bbe
Show file tree
Hide file tree
Showing 5 changed files with 30 additions and 1 deletion.
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ The framework is a companion to:

The framework consists of:

* [Engineering principles](principles.md) and [blueprints](blueprints.md)
* [Engineering principles](principles.md), [blueprints](blueprints.md) and [red lines](red-lines.md)
* [Engineering quality review tool](insights/review.md)
* [Communities of practice guidelines](communities/communities-of-practice.md) and active communities:
* [Product Development Test Automation Working Group](communities/pd-test-automation-working-group.md)
Expand Down
4 changes: 4 additions & 0 deletions patterns/outsource-bottom-up.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,10 @@
- [ARCHITECTURE-CLOUD](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/public-cloud-first)
- [ARCHITECTURE-REUSE](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/reuse-before-buy-build)

## Red lines

This pattern relates to [**RED-LINE**](red-lines.md): All new services must be developed on public cloud

## The pattern

Use managed services where available and appropriate. The aim is to reduce operational burden by handing responsibility to the cloud provider. They have made a business from doing this better than most organisations can.
Expand Down
1 change: 1 addition & 0 deletions practices/cloud-services.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,7 @@
- Understand how rapidly demand can spike and ensure scaling can meet these requirements. Balance scaling needs with the desire to avoid over provisioning and use [pre-warming](https://petrutandrei.wordpress.com/2016/03/18/pre-warming-the-load-balancer-in-aws/) of judiciously where required. Discuss this with the cloud provider well before go live they can assist with pre-warming processes ([AWS](https://aws.amazon.com/premiumsupport/programs/iem/)).
- Infrastructure should always be fully utilised (if it isn't, it's generating waste).
- Though balance this with potential need to run with some overhead to accommodate failed instance replacement times without overloading remaining instances.
- [**RED-LINE**](../red-lines.md): Development and test environments must not be run 24 by 7
- Keep up to date.
- Services/components need prompt updates to dependencies where security vulnerabilities are found — even if they are not under active development.
- Services which use deprecated or unsupported technologies should be migrated onto alternatives as a priority.
Expand Down
4 changes: 4 additions & 0 deletions principles.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,13 +14,16 @@

Our principles guide the way we work and interact with each other. They are based on the seven Lean principles as expressed in Lean Software Development: An Agile Toolkit by Mary Poppendieck and Tom Poppendieck.

A subset of these principles relate to our [red lines](red-lines.md) - these are identified by links like this: [**RED-LINE**](red-lines.md)

### 1. Eliminate waste

Waste is anything that interferes with giving customers what they really value at the time and place where it will provide the most value. Here are some examples, listed against the seven types of waste identified by Lean.

**Inventory — partially done work**, e.g. plans and designs, code. Limit work in progress (WIP) and use a pull-based approach.

**[Inventory — unnecessary resources](practices/cloud-services.md)** [ARCHITECTURE-SUSTAINABILITY](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/deliver-sustainable-services), e.g. server over-provisioning, complicated tools where simple ones would do. Adopt a "just enough, not just in case" mindset.
* [**RED-LINE**](red-lines.md): Development and test environments must not be run 24 by 7

**Overproduction — building unnecessary features.** Start simple and basic, get feedback and iterate.

Expand All @@ -31,6 +34,7 @@ Waste is anything that interferes with giving customers what they really value a
**Overproduction — reinventing the wheel.** Solving the same problem repeatedly in an organisation. Make sure there are effective ways to share knowledge between teams to avoid this.

**[Overproduction — building when you could instead reuse or buy](practices/cloud-services.md).** [ARCHITECTURE-REUSE](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/reuse-before-buy-build) Remember to consider all these alternatives.
* [**RED-LINE**](red-lines.md): All new services must be developed on public cloud

**Overproduction — premature optimisation for reusability.** Before making something reusable, first make it usable. Prefer explicit logic to implicit. Excessively generic systems create accidental complexity. [KISS](http://principles-wiki.net/principles:keep_it_simple_stupid) and [YAGNI](https://www.martinfowler.com/bliki/Yagni.html) and the caveats in [structured code](practices/structured-code.md) again.

Expand Down
20 changes: 20 additions & 0 deletions red-lines.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
# Engineering red lines

The engineering principles, practices and patterns in this framework provide guidance around best-practice engineering.

There is a lot of this guidance - it's all important, but we consider some of these principles, and some specific practices related to them, to be especially significant and therefore mandatory requirements for the services we build: these are our engineering "red lines".

We have chosen to put in place a formal governance process for any exceptions to these red lines (including how frequently any exceptions need to be re-assessed), and any changes to this central list of red lines.

You will find references to the red lines throughout this framework (the references look like this: [**RED-LINE**](red-lines.md)) - and for convenience this list is the complete set of red lines.

## Cloud / Infrastructure

1. All new services must be developed on public cloud
* Red line for the principle [overproduction — building when you could instead reuse or buy](principles.md#1-eliminate-waste) and the pattern [outsource from the bottom up](patterns/outsource-bottom-up.md)
* Relates to the architecture principles [ARCHITECTURE-CLOUD](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/public-cloud-first) and [ARCHITECTURE-REUSE](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/reuse-before-buy-build)
* For further details please see [cloud services](practices/cloud-services.md)
2. Development and test environments must not be run 24 by 7 and either need to be serverless so incur minimal charges when not being run or on demand and shutdown daily or run for less than 8 hours a day
* Red line for the principle [inventory — unnecessary resources](principles.md#1-eliminate-waste)
* Relates to the architecture principle [ARCHITECTURE-SUSTAINABILITY](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/deliver-sustainable-services)
* For further details please see [cloud services](practices/cloud-services.md) ("services should scale automatically up and down", "infrastructure should always be fully utilised", etc)

0 comments on commit db11bbe

Please sign in to comment.