A woman with a pen and colourful postits

Why you should involve solutions architects early in agile projects

Rob Smart

During a public sector digital agile project, the beta phase is when most of the technical work is done. It’s where solutions architects naturally play a prominent role.

But here, I will outline how we [solutions architects] add value well before we get to that point. I believe this provides valuable insight into how the service design teams should work. And just as importantly, the dangers that crop up if technical input is missing early in the process.

How solutions architects can unlock success in public sector digital projects

A solutions architect’s day at Zaizi is varied and depends on the phase of delivery a project is in. We might meet business stakeholders to discuss and help scope out a problem. The next day, we could be researching technical options and producing the detailed designs a development team needs to build a service. Another, we might be tracking down people in related government departments to discuss a data integration approach.

Our role is to research the problem space from a technical perspective. We design and help teams implement technical solutions. But we also need to ensure these appropriately solve the problem in a secure and supportable way. 

This demands a wide range of technical knowledge. It also means we need communication and other soft skills that come into play throughout the process and are critical to the success of public sector digital projects.

Pre-discovery

Our work begins in the pre-discovery sales phase. Here we help assess a project to check whether it falls within our technical capability and experience. We’re honest if it’s not. This is important for establishing whether we should proceed or pass the opportunity on.

Once we have helped assess our relevance to the task, the real work for us begins at the outset of discovery. Our input and analysis in this early phase of the process typically breaks down as follows.

READ: Discovery to alpha: Mastering ambiguity in digital public service delivery

Review of the technical landscape in a business context

At this stage, we work closely alongside our service design and user research colleagues. We ask questions that will be critical to establishing both technical and operational viability. What are the possible technology solutions to the problem? What other services might this new service have to interact with? And what constraints might be caused by that? 

We’re not just thinking about technology at this stage. We work alongside the rest of the design team to get to the root of the business issues and user needs. And hence, what the technical implications of those might be.

An example: At Zaizi, we recently worked on an alpha project that looked at establishing a private rental property register. Landlords will need to sign up and submit information to the register, so to help optimise their use of the service, we worked with our designers to make that process as easy as possible for them. From a technical perspective, this meant that during discovery we needed to investigate some crucial areas:

Our process in this discovery phase was focused on exploring the technical and organisational landscape the service will live in. We identified constraints, dependencies and potential integrations. This helped us determine the technical feasibility. 

By doing this, we set the team up to move on to alpha with a clearer view of the different ways we could use the various systems and services. If we hadn’t, the project would have been more likely to reach a technical stalemate later in the process.

Collaboration on user research

This may sound unusual – by no means everyone in my role does it. But I make a point of sitting in on user research sessions when possible during discovery rather than relying on a second-hand summary of what was discussed. This is important for picking up subtleties that may have a big technical impact on what you’re trying to achieve.

For instance, a target service user who works in the field might say in an interview that they need access to all the jobs they need to complete in a day on a phone. But they might also mention that they often work in high-rise buildings. I know from experience that in central stairwells in high-rise buildings, you’re unlikely to get a mobile phone signal. This might lead me to think that the application’s data needs to be stored locally on the phone so that jobs can be held and actioned offline. A non-technical person could easily miss this — someone who might simply have recorded the need to make the service work on a phone.

The role of the solutions architect in user research, even though it’s not traditionally our remit, is to understand the full context of the problem so you can best propose potential solutions. Lack of technical input at this stage will result in a narrower perspective that doesn’t capture the whole problem. 

READ: User research in government digital services — 7 steps to get it right

Moving forward

During discovery, we start to pick up on non-functional requirements that might have an impact on a service.  If we’re delivering a transactional service that could potentially be used by several million people — are they all likely to visit in one day, or will they come in over several months?

We also: 

This latter point is important. Solutions architects add significant value between discovery and alpha by identifying the riskiest assumptions within technology recommendations and outlining proof of concept (POC) work.

These recommendations are important for continuity between phases. The way government procurement works, you cannot guarantee that the same team will be working on both the discovery and alpha phases of a project.

Regardless of whether you have two different teams on the two phases, well-defined POCs developed by your solutions architects are critical to investigating where the technical risk is. Without them, there is a greater risk of running into technology dead-ends.

Towards a viable service

During the alpha, the interplay between the solutions architect and the rest of the service design team continues.

When we’re developing prototypes, we continually feedback on whether the technical aspects required to make the user journey run in the way designers envisage will work. We identify where steps in the journey (often those that require unavailable data) are not going to be technically possible. We also explore whether there is an easier way. For example, we might consider removing steps in the process because we can do that part of the journey automatically.  

The value of the tight connection between solutions architects and the wider design team will become clear at this point of the design process.

By working closely together at every stage, we ensure as a team that we don’t just look at user needs. We also look at the full context the service will run in. The danger of not doing so is that we go too far down the line with non-feasible solutions that waste considerable time and resources.

If you would like to learn more how we can help you develop your next public sector digital project,  please get in touch with us.

Thanks for joining us! We’ll keep you informed with regular updates.

Sign up to our newsletter

Consent(Required)
This field is for validation purposes and should be left unchanged.