TRG

The role of TRG

TRG is the Technical Review and Governance group and is made up of technical experts from across our organisation. It meets every first and third Wednesday each month.

TRG provides technical governance by ensuring that all developments and activities align to published policies, principles, patterns and standards.

The Live Services Board looks to TRG. If programmes have not been to TRG they will not be supported in going live. As a technical and/or project professional working on a new programme or project, it therefore makes sense to engage with TRG at an early stage.

Taking something through the TRG

We are required, by the Government, to provide fully audited and traceable governance of all the services we at NHS Digital deliver. TRG is how we do this for technology. The role of the TRG is to provide technical reviews and governance across the delivery lifecycle of all NHS Digital projects. We ensure that the right criteria are being met (principles, strategies, policies, standards and guidance) at every step of the way from Discovery stage to Go Live.

• The TRG are not there to increase workload or complexity – rather the opposite. We ensure scalability and flexibility but with the necessary controls.
• This process helps make sure the right decisions are being made at the right time. Protecting public spending and providing a level of confidence in the programmes being launched to reduce risk of failure.

What do I need to take to TRG?

All works (programmes, projects or other initiatives) which lead to a change to the systems and services impacting technology need to have TRG consideration. Identifying where there is a need for TRG involvement and ensuring that the right information is provided early on avoids any potential for delays or misunderstandings later. It also ensures that each of the CCCs have the information they need at the right time.

TRG submissions are made up of two main artefacts, the Solution Design Overview (SDO) and Key Architecture Decision (KAD). Additionally, if you require a new cloud hosting account/subscription a Cloud Hosting Request (CHR) should be completed, if you are proposing the use of a commercial off the shelf product or service you should complete a Commercial Off-The-Shelf product request (COTS). Both KADs, CHRs and COTS are attached to specific SDOs so an SDO will need to be completed first, before moving on to the other forms.

Solution Design Overview

The Solution Design Overview (SDO) captures overarching information about the solution or service which is being developed. Within the SDO you can attach supporting solution design and programme documents. Within the SDO you will also need to complete a risk assessment which is made up of two components.

1. The Data Classification Risk Assessment – This is the existing assessment from the NHS Cloud Guidance. We have converted the spreadsheet to a form should you wish to use it – or you can just enter the classification.
2. The Architecture Risk Assessment – This takes you through some basic questions to gauge the complexity of your service or change and we use it to establish the appropriate governance route – simple changes with a low risk can be fast tracked, higher risk change is fully assessed.

Key Architecture Decision (KAD)

A KAD documents the fundamental technology choices you make as you develop your service covering elements such as hosting, authentication, technology or product choices, API design etc.

The KAD form is very simple but you will be expected to provide additional information, normally in the form of a slide deck which outlines how you reached your decision, options considered and a clear rationale for the final choice made.

Cloud Hosting Request (CHR)

As part of the NHS Digital's Platform Strategy, the organisation has identified a position of “Cloud First” for all future services. To request a new account/subscription for AWS, Azure or Texas you should complete the CHR form detailing the intended platform and anticipated costs.

Commercial Off-The-Shelf request (COTS)

The COTS submission is used by a programme to outline to TRG the proposed procurement or use of a Commercial Off-The-Shelf product or service. TRG would be interested in the technical fit for its intended purpose, how that was determined, and any close alternatives may have been considered.

All forms and further information can be found here TRG Homepage

TRG Top Tips

1. Engage with TRG as you make decisions (at whatever life cycle stage). Do not come to TRG a week before your go live!
2. Be really clear what you want from TRG in your submissions & presentations e.g. “We want TRG to approve these KADs….”
3. Ensure the Lead Technical Architect supports the decisions you are making, it will help your position and provides a simple escalation route if there are issues.
4. Ensure you have good rationale for the decisions you make and options you discount.
5. If in doubt, ask us!! trg.mailbox@nhs.net

Aalto

You will be expected as part of developing your solution to create or update the information held in the Enterprise Architecture tool, Aalto. As a minimum this includes Archimate layer model and technology and interface changes. TRG will ask that you have done this.

If you need help with this please contact the EA team directly via their email aalto.architecture@nhs.net

Examples of work that would require TRG engagement

New solution designs (from concept to physical design process), cloud infrastructure requests and code-in-the-open submissions. TRG is also there to review current long-term, large scale programmes against PPPS (Principles, Policies, Patterns and Standards). These are frequently updated as part of our continual improvement process, so please always look at the latest version which are held in Aalto

What DON’T I need to take to TRG?

However, there are many things (applications, standards, tech stacks) which will have already been approved and published as “Preferred” or “Strategic”. In these cases, you won’t need to present them for review, you just have to simply ensure Aalto is up to date with this information. You can access a list of everything TRG has approved in Aalto

TRG meeting attendance

We would like to see people attend the formal TRG meetings by exception only. We will use the risk assessments to ensure only more complex changes require board attendance. Following review, if attendance is required then you will be contacted by the secretariat.

What is my responsibility with CCCs?

All submissions will be made via the TRG Forms (SDO, KAD, CHR & COTS) which can be found here TRG Homepage and these will be visible to those responsible for each of the cross-cutting concerns (CCCs).

There are ten CCCs

Data, Development, Enterprise Architecture, Infrastructure, Interoperability, Service Management, Security, Solution Assurance, Sustainability and Usability and Accessibility.

We would recommend that you engage each CCC that is relevant to your project as early as possible in the process of writing your submission. Engagement with the CCC leads does not replace any programme level engagement you would normally do, for example security or IG SMES.

With the benefit of their experience, they may be able to save both time and investment as they have visibility of all projects going through the TRG. They can identify duplication in current submissions that may provide learning for your own project and will know if a similar solution has already been designed to meet the same objective(s).

For a list of who the CCCs are and more information – please see the link below:

Find out more about the role of the CCCs.