Skip to main content

https://defencedigital.blog.gov.uk/2020/07/09/how-we-are-improving-architecture-governance-across-nelson-and-navy-digital/

How we are improving architecture governance across NELSON and Navy Digital

In this blog post, the Royal Navy’s NELSON gives us a behind-the-scenes look at their work to create a new architecture community for Navy Digital.

Joining the dots

The NELSON Coordination team is helping to meet the Navy Digital and Data Strategy by taking a more joined up approach to service delivery. Acting as the ‘glue’ between our different teams, we’re aiming to drive greater consistency, collaboration and best practice across NELSON to help create better services for the Navy.

Community spirit

As part of the wider plan to establish communities of practice that align with the Digital, Data and Technology (DDAT) framework, NELSON is following best practice GDS guidance to create our own Communities of Practice, including user research, architecture, design and development.

Each community will bring together individuals from different teams to share skills, knowledge and experience in a particular discipline. They will draw on all the expertise we have on the programme, enable scaled delivery and eventually provide a channel for knowledge transfer to crown servants.

An architecture community for Navy Digital

To meet the Navy’s high demand for better services, we’ve scaled up the number of digital services we’re helping to deliver. However, this has left less time than we’d like for coordination between different teams and we’ve been listening to the growing pains from that.

So to help us coordinate and manage architectural risk more effectively, we’ve set up a Navy Digital Architecture Community.

The community’s key areas of focus will be to:

  • ensure that the NELSON capability and services we’re building align to the longer term NELSON, Navy and wider MOD strategies
  • drive a more joined up and consistent approach to architecture and design
  • provide rigorous but lightweight governance for architectural challenges and technical design outputs across all our services
  • identify and scope common capabilities and components that can be shared by the digital services we’re building
  • prevent nascent risks from becoming issues further down the line
  • identify and resolve issues and blockers both within service delivery teams and across NELSON

Starting up

There are a few things we had to put in place when forming the new architecture group, especially a Terms of Reference to capture everything we needed to make it work effectively.

As we’ve learnt things over the first few weeks of operating as a community, we’ve had to revisit some of our initial assumptions and statements. Rather than leave the Terms of Reference ‘on the shelf’ to collect dust, we're using it as a living document that the community agrees and stays aligned to as we make adjustments. It’s become an important artefact.

Here’s the key elements of our Terms of Reference that we’ve found to be of real value.

  • Drivers - setting out why the community is needed.
  • Role - explaining the community’s strategic context and how it interacts with other governance groups.
  • Responsibilities - detailing the community’s specific tasks and their scope.
  • Meetings - describing how these will be run.
  • The responsible, accountable, consulted and informed (RACI) model - making sure everyone understands and explicitly agrees to their role within the group.

In terms of our members, our fundamental principle is to have every team represented, so they’re aware of any impacts and dependencies that may affect them.

We’ve agreed to run a weekly forum initially and in true agile spirit, we’ll run regular retrospectives to get feedback and improve how we’re working.

Building the machinery

A first step in getting our new community off the ground was to create some frameworks to manage meetings and agendas, track actions and record what’s been agreed.

We’ve also defined what the group will work on when it meets, which we call a ‘3+1’ view.

  1. Reviewing technical options or proposals and making recommendations to our Technical Design Authority.
  2. Identifying and scoping things that need to be done for the greater good. This could be, for example, producing a consistent set of templates for documentation across teams, or standardising guidance for non-functional requirements.
  3. Identifying and scoping common services that our application delivery teams can share and reuse, such as authentication or logging and monitoring.

The ‘+1’ is a common thread in each session to keep sharing ideas, issues or updates that might be of interest to everyone. As well as bringing the right things into the group for review, we want to make sure everyone is joined up when communicating with teams, which helps to reduce overall delivery risk.

A graphic showing Learner Plate

Running with ‘L’ plates

There’s been a strong focus on identifying opportunities to improve our current technology and better support more services for Navy Digital. We did some early research to find out the scale and scope of the problems that need to be solved. Then, as a community, we discussed and prioritised them into a clearly defined backlog. This has helped us to separate bigger ticket items from quick wins and we’re building momentum on those smaller items to get early value.

Keeping to an agile philosophy, we started small with a simple framework to help us manage backlog items and we’ve improved this incrementally. As delivery gets underway, we’ll be looking to adopt standard tools and processes to help us strengthen our capability in this area.

Although we’ve spent time on getting our Terms of Reference right from the outset, we’ve had some feedback on where things could be clearer.  We’ve taken this on board as part of our learning experience.

Creating a funnel

After running a few sessions, some of the early feedback was that:

  • we needed to be clearer about the types of things we would review
  • we needed to avoid getting clogged up with lower level issues that would take time away from the core governance aspects we should be focusing on

One of the key challenges in setting up a group like this is to strike the right governance balance - it needs to be an enabler not a blocker. If it’s too lightweight it could become ineffective by not providing a minimum level of rigour. If it’s too heavyweight it could become a bottleneck and delay vital work.

Since then, we’ve taken a simple but effective ‘filtering’ approach, so that we bring technical proposals or options to the group for review only where the scope and impact of change deviate from a set criteria. This restricts the amount of governance ‘churn’ and ensures we’re using our time wisely. The major rules are that we only review if:

  • there is some architectural impact within a service team, even if minor
  • the scope of a technical change could impact other teams or services
  • there’s deviation from a range of other criteria, for example, Navy strategy, architectural principles or security policies

Reflecting on our progress

We’ll be running our first retrospective soon focusing on what we liked, what we learned, what we lacked and what we wished for. Taking a step back to reflect and feedback on how we’ve worked so far will give us an opportunity to improve the way we work as a community.

One of the key challenges we’re facing is how to turn the larger pieces of work from our backlog into real work, such as a new common service. As our teams are already focused on delivering digital services, we’ve recognised the need for a capability that can scope and prioritise these things into the overall NELSON portfolio of work. This will enable NELSON to fully realise its part in the Digital & Data Strategy by ensuring the services we’re building are both prepared for the present and fit for the future.

Scaling for the future

Although the architecture community will focus internally on NELSON in the short-term, we’re aware that we’re only one part of the bigger picture. We want to work towards building into a wider Community of Practice, potentially linking with other areas across Defence such as Defence Digital, Naval Combat Systems Integration Support Services (NCSISS) and the  Defence Science and Technology Laboratory (Dstl). As we broaden out the scope over time, we’ll need to understand the interactions and dependencies with other groups and learn how to scale this to a larger community.

Sharing what we learn

Since forming the architecture community for Navy Digital, we’ve already started to see benefits in terms of governing technical change more effectively and working as a wider, more cohesive community across our teams. As we progress on our journey, we’ll blog about what we’ve learnt to get feedback and help others across Defence and government.

If you’d like to share experiences from your own Community of Practice,  or would like to find out more about our architecture community, please get in touch. We’d love to hear from you.

To find out more about NELSON, read this blog post about our work.

Sharing and comments

Share this page

Leave a comment

We only ask for your email address so we know you're a real person

By submitting a comment you understand it may be published on this public website. Please read our privacy notice to see how the GOV.UK blogging platform handles your information.