Solving technical architecture challenges in 4 steps

Being a Technical Architect is a varied and challenging job role. During my time at Government Digital Service (GDS) I’ve worked on everything from database remodelling for improving analytics performance to data modelling and prediction for GOV.UK PaaS cost and recharge patterns.

Working in multidisciplinary teams on different projects, looking at industry best practice and observing other architects has led me to develop my own methodology to tackle technical and business challenges.

Different interpretations of technical architecture

In the building and construction industry, the role of an architect is well defined. Architects usually gather the requirements and are responsible for the initial design and planning, before handing off the construction to engineers or builders.  

In agile software development, technical architecture usually isn’t a clearly defined role, and the hand-off from design to implementation can vary. The requirements of getting the design right the first time is not as critical, and is a more iterative process. 

Under the Digital, Data and Technology (DDaT) Profession Capability Framework, the role of a technical architecture includes: 

• strategy
• governance
• making and guiding decisions
• understanding the whole context
• turning business problems into technical design
• bridging the gap between the technical and non-technical

The DDaT descriptions provide a good general overview of the role, and have defined the quality and skills needed to fulfil our responsibilities. 

There are other blog posts that talk about architecting in technology. Martin Fowler, Chief Scientist at ThoughtWorks uses the metaphor of an “architect elevator” to describe his view on architects. He talks about their ability to work on the ground to provide technical skills and knowledge to teams, as well as preparing to travel up the elevator to unblock organisational hurdles. 

Meanwhile, software delivery consultant Peter Hodgson promotes the strategic architectural initiatives framework in his delivering on an architecture strategy post. He views architects as technology leaders who define a vision for architecture and lead towards it. 

A good architect allows teams to make decisions and helps them to align with the bigger picture to meet organisational objectives, for example by using common toolings.

Developing an architecture blueprint 

I agree with both sets of views on technical architecture. Their major ideas, shared by many of us, are centered around the need for connecting: 

• technical to non-technical people 
• business and technical goals
• local or team autonomy to organisation strategies 
• the current horizon to the vision

An architect may not be the most technical person in a project, but is good at putting the different pieces together to achieve the goal. 

I’ve developed a blueprint, which I’ve used to build architectural strategies to solve problems or achieve particular goals. I’ve found it useful to visualise both technical and non-technical problems and construct the steps needed to complete the tasks.

The 4 steps I take to build a strategy are:

1. Check the current landscape of the problem: when presented with a problem, it’s important to gain a full understanding of the strengths and weaknesses, constraints and options, of the technical and non-technical aspects - I found that user research, auditing, context gathering, data analysis, consulting stakeholders and cost modeling are useful tools.
2. Define the vision: this is the vision of what the ideal outcome should be, if you have all the resources you need - I found best practice and anti-pattern research, governance, standards and guidance, prototyping, user research results, gap analysis and market research are useful tools. 
3. Close the gap between the vision and what is achievable: from the “ideal” scenario, we need to come up with a realistic vision of what we can achieve - I found that talking to the people who deliver, sharing the vision with an open mindset and getting feedback on the vision are useful tools. 
4. Build strategies to close the gap between the current landscape and the vision: you need to consider the strengths and weaknesses of all the aspects of your project, to construct these strategies - if certain aspects of the projects have not been considered properly, the project may be at risk.

Ways of working 

Different architects have their own ways of working and individual skill sets. I work quite closely with the teams, usually attending agile rituals including standups, workshops and retros. 

At GDS we have an architect community that meets up bi-weekly. In my experience, I find it useful to attend strategic meetings, and work closely with different people from other disciplines, including business analysts and economists. This helps me gain visibility and understanding of the different aspects of the project.  

Developing technical architectural skills is an agile process in itself. It takes many iterations to get it right. The success and the failure along the journey are equally important to help iterate and shape our vision of technical architecture.