This repository is home to the Operations Engineering's tools and utilities for managing, monitoring, and optimising software development processes at the Ministry of Justice. • This repository is defined and managed in Terraform
As a Member of Operations Engineering
I want a summary of all of the responsibilities for our Third-Party services
so that I can easily articulate the responsibilities of Operations Engineering for a Third-Party service and identify any potential risks appropriately.
Value
In retrospective, an issue was raised that we have "Ill-defined processes and responsibilities". This mainly concerned the processes and responsibilities Operations Engineering have for third-party tooling we own.
Having a reference list of Third-Party services and Operations Engineering defined responsibilities will enable the team to enforce boundaries and identify risks.
Functional Requirements (What):
[x] A list of all third-party services
[x] A list of potential responsibilities may have relating to third-party services
[x] A table of whether Operations Engineering currently takes responsibility of X for the Y service (for example, Operations Engineering currently takes responsibility of "paying the bill" for the "GitHub Enterprise Account")
Non-Functional Requirements (How):
[x] Documentation enables clear identification of current responsibilities
[x] Documentation enables the ability to identify risks where Operations Engineering does not take responsibility.
Acceptance Criteria:
[x] An artefact has been created to display Operations Engineering's current responsibility with third-party tooling
[x] A session has been set up to go through the artefact and identify gaps and risks
Created an initial spreadsheet detailing a broad range of responsibilities related to Third Party Tooling
Created the start of a diagram of the user requirements for Third Party Tooling, as it relates to Operations Engineering 👇
👀 Remaining Work
Complete the spreadsheet
Talk to @AntonyBishop to diagram in more detail the requirements of the procurement process (the current diagram feels shallow in this area at the moment)
Completed diagram of the user requirements for Third Party Tooling, as it relates to Operations Engineering. This now details the requirements of Third Party Tools that we would generally expect to satisfy the Demand Process to secure funding for purchasing the tools 👇
Ran a session with the team to run through the above artefacts
Added two risks to the Risk Register as an outcome of this work:
R019 | No Explicit Security/Configuration/Compliance Audits of Third Party Tooling
R020 | No consistent monitoring, reporting and analyses across Third Party Tooling
👀 Remaining Work
No more work at the moment, but the artefacts may help feed into work around Third Party Tooling
User Need
As a Member of Operations Engineering I want a summary of all of the responsibilities for our Third-Party services so that I can easily articulate the responsibilities of Operations Engineering for a Third-Party service and identify any potential risks appropriately.
Value
In retrospective, an issue was raised that we have "Ill-defined processes and responsibilities". This mainly concerned the processes and responsibilities Operations Engineering have for third-party tooling we own.
Having a reference list of Third-Party services and Operations Engineering defined responsibilities will enable the team to enforce boundaries and identify risks.
Functional Requirements (What):
Non-Functional Requirements (How):
Acceptance Criteria:
Notes: