- This is part of a broader quality framework
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: we refer to these as our engineering "red lines", and we consider them to be requirements rather than guidance.
We have chosen to put in place a governance process for:
- Any exceptions to these red lines in the services we build
- The ongoing re-assessment of any exceptions to the red lines
- Changes to the list of red lines
You will find references to the red lines throughout this framework (the references look like this: RED-LINE) - and for convenience this list is the complete set of red lines.
Drafting notes for any changes to this list:
- Red lines must be specific and measurable, for example Bake in security is a good principle but would not be a valid red line, because it's open-ended. Some of the specific security practices that fall under this general security principle would however be suitable candidates for red lines.
- All new services must be developed on public cloud
- Red line for the principle overproduction — building when you could instead reuse or buy and the pattern outsource from the bottom up
- Relates to the architecture principles ARCHITECTURE-CLOUD and ARCHITECTURE-REUSE
- For further details please see cloud services
- 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
- Relates to the architecture principle ARCHITECTURE-SUSTAINABILITY
- For further details please see cloud services ("services should scale automatically up and down", "infrastructure should always be fully utilised", etc)