In this blog, I explore the role of technical architecture in driving outcomes. I’ll cover the tools and approaches that’ll help ensure success. Things such as defining the non-negotiables, collaborating with stakeholders, communicating clearly, and managing risks. 

Establish the non-negotiables

The first step in establishing a technical architecture approach that drives the right outcomes is to set a north star. When push comes to shove and difficult priority calls need to be made, what is your single most important non-negotiable? This could be a particular technology choice, a cost saving that needs to be made, or the team shape available. Whatever it is, identify it and accept that all other decision points exist to support that goal. 

It’s important to listen to what users and the experts within your organisation are saying. That said, different stakeholders will likely have different priorities, so non-negotiables may differ depending on who you ask. So as a technical architect, the ability to communicate, build rapport, influence and advise, are all skills I keep sharp in my tool box. Have the conversations – lots of them. Find common ground, bring people on the journey with you and get buy-in. Once you’ve identified what your non-negotiables are, you’ll be able to have meaningful conversations about where to compromise, and what hard constraints you’ll have to navigate. 

Get agreement on key architecture qualities

One effective way to reach a consensus on architecture quality is through collaboration. Here’s a straightforward approach that I’ve found works.

1. Gather stakeholders: Bring together key representatives from each stakeholder group for a whiteboard session.
2. List architecture qualities: Write a list of architecture qualities.
3. Rank priorities: Have each stakeholder list their top 5 most important qualities in order of priority. Let them share their unique perspectives with the group.
4. Assign points: Assign points based on priority (e.g., 5 points for priority 1, 1 point for priority 5). You might need more granular scoring but it’s the discussions that follow that matter most.
5. Discuss and agree: Count up the votes, discuss the outcome, and agree on the top 5-7 most important qualities as a group.

I’ve found that this collaborative exercise builds empathy among stakeholders and surfaces important qualities. It reveals a potentially long list of qualities that, as a group, no one is overly concerned about, as well as insights into what has mattered historically and what may become more important in the future. 

Communicate your technical architecture

Technical communication done well enables digital and non digital teams/stakeholders to understand if an architecture is driving the right outcomes. 

My rule of thumb is that if you need to provide in-depth explanations or detailed walk-throughs to make your diagrams make sense, they’re probably not as effective as you thought. I recommend modelling your architecture in code to help you to describe it accurately and concisely, it will also ensure consistency and promote reuse. 

The C4 Model with Structurizr is my go-to practice and tool of choice. It helps present the relevant parts of your architecture, at the right level of abstraction based on your audience. That makes it ideal for communicating your technical architecture effectively, and it’s extremely powerful when it comes to helping you diagnose issues in a collaborative way. Like all diagram techniques, it does take some practice. Using the C4 Model diagrams requires discipline. I’d urge you to focus on what exactly you’re trying to achieve with it and always think about your audience. It’s not about documenting everything in a diagram, it’s about building a shared understanding.

What’s great about using Structurizr is that the constraints imposed by the domain-specific language (DSL) help you rationalise and describe the architecture of each system in a consistent way. Once you have a model of your architecture, it then takes minutes to create clear and concise visualisations.

Assess performance

The next step is to view your architecture from the perspective of a particular quality goal or outcome that you feel your architecture is struggling to meet. 

On many projects I work on, we uncover and reveal key issues that stop an organisation from achieving their desired outcomes, simply by using system context diagrams. These diagrams are crucial because they are digestible by both technical and non-technical stakeholders. 

Working with one particular government organisation, we brought together leaders from across various departments and ran a risk storming exercise on their entire technical estate. What we learned changed how we viewed their architecture, brought to light how the current set-up was impacting their goals, and helped us focus on the most critical issues for the organisation from that point on.

We also gained valuable insights into their specific quality goals, such as system resilience. We produced detailed system container diagrams for different engineering teams within a complex technical environment. This enabled us to run a collaborative risk storming session with all squads simultaneously, with prompts to focus their thinking towards reliability engineering concepts. This highlighted clear high risk areas which we explored together to help them decide where to focus their mitigation efforts and identify which were low risks they could tolerate.

Regular risk storming is my preferred method for evaluating how a system’s architecture is performing, whether looking at the most important qualities or specific outcomes. They’re also useful for sprint retrospectives, post-mortems, or rebuilding stakeholder trust. The key is to keep assessing and addressing your biggest risks.

However, running these sessions can be challenging. I recommend careful planning, active stakeholder engagement, clear prompts for the attendees, and creating a safe environment for discussion.

Standing on the shoulders of giants

Crafting an effective technical architecture can be challenging and daunting, given the sheer number of options available and the need to meet user and organisational needs. The list of giants that have elevated our understanding of what software is, and what it can do, is a long one. I won’t attempt to list them all here, but the following are the main ones that influence the way I work with clients. 

• Mark Richards, Neil Ford, Pramod Sadalage & Zhamak Dehghani for giving us the books “Fundamentals of Software Architecture: An Engineering Approach” and the sequel “Software Architecture: The Hard Parts”. These provide the foundation for understanding the essential practices of modern software architecture and how to perform effective trade-off analysis across distributed systems.  

• Murat Erder and Pierre Pureur for giving us the book “Continuous Architecture In Practice” which takes a principled approach and focuses on how to continuously deliver an evolving architecture that drives quality. 

• Simon Brown’s C4 Model and collaborative risk identification technique risk-storming. As described within this blog, I’ve found this instrumental in my day-to-day work.

By standing on the shoulders of these giants (and the many others), we can see further. We are armed with a wealth of knowledge that helps us build architectures that truly drive the right outcomes for end users and citizens. I encourage you to draw on these resources, blend them with your own experiences, and continually adapt as your organisation evolves.

What I’ve shared here comes from my own experiences and the valuable insights from others in the field. As you use these strategies, know that they’re part of a bigger picture of knowledge, practice and completely yours to make your own.

The post Is your technical architecture driving the right outcomes? appeared first on Made Tech.

A pressing need for smart digital strategies

In a recent interview, Cat Little, Chief Operating Officer and Permanent Secretary of the Cabinet Office said that the government is currently grappling with ‘how can we use data and digital for better service outcomes …. and can we do that with less resource?’ 

I’ve listed below a few digital strategies that I believe can be intelligently applied to keep things working, without exponentially increasing the size of your Digital, Data, and Technology (DDAT) workforce.

• Fund digital teams, not just projects: Now’s the time to stop discussing and actually make this happen. Funding models need to support digital teams on an ongoing basis, rather than just one-off projects. Teams that stay together are more effective. They can manage and enhance multiple similar digital services efficiently. An enduring relationship allows them to quickly adapt to and meet changing needs, driving long-term savings across several initiatives rather than disbanding after a single project wraps up.
• Embrace ‘good enough’ over perfection: Digital teams getting stuck in the beta phase, obsessing over 100%, is all too common. Teams should be encouraged to set a ‘good enough’ benchmark that meets most users’ primary needs. This move speeds up the transition to live service, letting you deliver value faster and avoid getting bogged down by endless tweaks.
• Make delivery the goal: Ruthlessly prioritise. It’s far better to successfully deliver two services to live operation than to initiate ten discoveries that lack the budget or resources to ever get delivered. 
• Develop and use common components: Let’s push for more shared components across different departments. This approach will enable you  to cut down on duplication and ensure a consistent user experience. Tools like GDS Forms and GDS Notify are prime examples of how reusable components can happily serve a wide-range of needs.
• Refocus your procurement strategy: Here, you need to focus on total cost of ownership rather than just the cheapest solution. This will make things more sustainable and easier to manage down the line. It’s also a good opportunity to rethink your budgets and projects, to make sure that you’re not putting in place systems that just mimic your existing organisational structures or current teams (applying Conway’s Law).
• Adopt team topologies: Shift to a team topologies model to help develop and support multiple services more efficiently. If you set up platform teams to create standardised tools for example, you’ll reduce duplicated effort and encourage shared learning across the board.
• Lean on Managed Service Providers (MSPs): For ongoing operational support, especially in ‘Run’ mode, tapping into managed service providers or Site Reliability Engineering (SRE) teams could be a game-changer. This way, you can draw on specialised expertise and scale benefits without needing to ramp up your internal team sizes.
• Embrace compact, agile teams: Opt for smaller, agile teams to streamline communication and keep everyone in the loop efficiently. Reducing communication layers allows for quicker decisions and seamless collaboration. Shift from rigid job titles to versatile roles, leveraging ‘T-shaped’ professionals who can adapt and cover multiple functions. For instance, a delivery manager with business analysis skills or an interaction designer who also handles content design will make your team more flexible and more efficient. 

Digital transformation isn’t just a nice-to-have; it’s essential for keeping our government services robust amid cuts. By putting in place some of these strategies, you’re not just sitting back and making do; you’re setting the stage for a more agile and responsive public service. Let’s keep our eyes on the prize: a digital-first government where innovation, practicality, and efficiency are at the heart of public service delivery.

For more on this topic, watch my recent webinar on the often-overlooked steps that can make or break a successful digital delivery.

The post Leaning on digital to deliver more with less appeared first on Made Tech.

Less than a year later, we’ve graduated and are working on client projects to improve lives for public sector teams, citizens and society. I’m delighted to have found a project that suits my skills and interests with the Met Office, helping to improve the accessibility of their website. 

Reflecting as you often do when a new year rolls around, this got me thinking about my journey and where I am now. 

My journey into content design 

Before coming to Made Tech I worked as a clinical animal behaviourist both in a private practice and for an animal welfare charity. After developing severe allergies to animals I decided to take a step back and explore other, more hypoallergenic career opportunities. 

I discovered user-centred design (UCD) while microtasking to make some extra cash as a stay at home mum. I took part in different types of user research studies like face-to-face interviews, card sorts and website user testing studies. My husband who works in software was familiar with Made Tech and told me they’d created a user research and design academy.

The academy gave us a grounding in the world of UCD, covering everything from user research, service design, interaction design and content design. The emphasis was on design that solves the needs of real people in the public sector. It gave us a safe space to learn through workshops and tutorials with exercises alone, in pairs and groups. Experienced design and user research teams ran specialist workshops on their areas of expertise. 

At the end of the academy I joined Made Tech as a permanent member of the team. I have a real interest in climate change and sustainability, so I showed my interest in working on a project with the Met Office exploring accessibility and content design. 

Here’s the thing about accessibility

Accessibility is about making your digital service work for as many people as possible. At its core accessibility is usability for all – everyone can face challenges when accessing a website. 

Many people change their settings to make websites and apps easier to use – maybe you do, too? Someone might increase the font size, zoom in or navigate with a keyboard instead of a mouse. And some people use assistive technologies like screen readers or voice recognition to access the internet. This includes people with impaired vision, motor difficulties, cognitive impairments, learning disabilities, deafness or impaired hearing. 

Good digital accessibility means that everyone can perceive, understand and use websites and mobile apps.

Accessibility in the public sector

Digital accessibility is an important part of inclusion. Following good accessible design practices benefits everyone and makes user experience better, quicker and less frustrating.

When it comes to public sector services, accessibility is a legal requirement. Citizens don’t have a choice when accessing public services – they have to use your site. Since September 2018 public sector services need to meet the Web Content Accessibility Guidelines (WCAG) to at least AA standard. The WCAG outlines ways that websites can be made more accessible and is broken down into three levels: A, AA and AAA. Each additional ‘A’ gives us more criteria to follow. 

Public sector organisations must also audit their website, publish an accessibility statement and review it regularly. This statement tells users:

• how accessible the site or app is
• about any inaccessible parts of the website or app
• how they can get alternatives to content that’s not accessible
• who to contact to report accessibility issues

Accessibility in the public sector means making your content and design clear and simple enough so most people can use it without needing to adapt it, while supporting those who do. 

Making the Met Office website more accessible 

Beginning my first ever client project at Made Tech, it was great to feel like a key member in a truly multidisciplinary team. Working closely with others who have skills in programming, project management, user research and content design; learning was a daily occurrence. 

I hadn’t worked on an agile project before and the initial sprint felt difficult to navigate as I adjusted to the new ceremonies, processes and language involved. My team was patient, understanding and supportive. As I became used to the agile methodology, I started to understand its benefits. Of these, there were plenty of opportunities to discuss our work, figure out how complex tasks were and discuss together how long they would take. 

Getting stuck into all things accessibility I was able to work closely with the Met Office team. I helped solve some accessibility challenges with their website content that included:

• page titles which didn’t accurately describe the content
• lack of headings within articles which created large blocks of text, making the page difficult to read
• images without alt text (a description of the image) meaning users unable to see visual content couldn’t use this information

We helped make these parts more accessible by:

• creating new page titles that describes content of the page – helping users decide whether that content is relevant to them
• dividing pages into easy to read sections with descriptive headings
• adding alt text to images to help screen reader users understand images – this also helps those who need to use settings which turn off visual images and can improve search engine optimisation (SEO)

The wider team are also working on a content strategy to upskill those creating content for the Met Office in accessibility. This means any future content or edits are created with accessibility in mind from the very start.

The value our work is going to add to not only the Met Office but those who use their services is clear. And it felt good to be part of something that’s improving inclusivity in the public sector.  

Looking to the future

Reflecting on my first piece of user-centred design work I had a great experience. I was empowered to take responsibility from the very start and during collaborative discussions the sense of autonomy was clear. I had opportunities to recognise new areas of work where greater clarity and consistency within the content might improve the user experience while helping the client meet their goals. 

On my first ever project, working with a great client, having a clear culture around collaboration and agile principles has really supported my development as a content designer. I’m looking forward to continuing to grow my skills , knowledge of content design and accessibility and working on sustainability and climate projects I’m passionate about. 

The post Accessibility at the Met Office: my first Made Tech project appeared first on Made Tech.

Not only is the demand for online public services increasing, but the expectations citizens have for the quality of those services is higher than ever. The UK falls far behind countries like Estonia and South Korea, where 80% of government interactions happen online, compared to just 50% here in the UK. This low engagement level leaves us ranked 11th by the United Nations (down from 7th last year) when it comes to government digital services.

So why is the UK lagging behind and what can we do about it?

The need for quality digital services

There are 2 key reasons for this. Currently a lot of services are not digitalised, and those that are often don’t meet the standards citizens expect. 

Services are not digitalised

Last year, over a third of citizens couldn’t complete digital journeys solely online. Despite accessing services online, they were at some point required to complete a paper form, make a phone call or attend an in-person meeting to receive the support they needed.  

Services considered fully digitalised are, in some cases, not digitalised at all. Inaccessible designs lead to a high drop-out rate and the need for people to try again – or via a non-digital channel. Surprisingly up to 90% of England’s biggest councils struggle to meet accessibility regulations, meaning digitalised journeys are often not digitalised for all.

Services don’t meet standards

A trend we see again and again is that despite certain services being digitalised, citizens are often not interested in using them. Users compare government digital services to their best last digital experience. The problem with this is that it often means comparisons with the consumer services from the private sector, where some big names have set an incredibly high bar. 

What can we do?

Fortunately for us as members of the public, the government is working to improve online government services. By 2025, the plan is to transform the UK government to be a “more efficient digital government that provides better outcomes for everyone” and government departments have been guided to “remediate what already exists”.

Whilst maintenance might seem less radical than replacement, it marks a huge shift in government strategy. This approach will significantly reduce the government’s current annual bill of over £2 billion (and growing) that’s spent on keeping the lights on for poor quality legacy services.

This shift in strategy must be met with a shift in equivalent methodology that focuses on users, reduces the burdens associated with Legacy IT and unlocks the potential for transformation.

Support, maintain and continuously improve

The government spends 50% of its annual digital budget on supporting and maintaining services. That number was £2.3 billion in 2019 and is expected to reach £4.4 billion by 2024 without intervention. 

This £2 billion maintenance operation needs continuous improvement to deliver the methodology shift required. Continuous improvement in this context is the idea that changing and improving a service doesn’t have to be a dedicated project. Instead, it’s part of the operating model for supporting that service. This approach involves continually monitoring the service, speaking to users to understand how their needs are changing over time, and making changes to keep the quality high. 

As it stands, a large proportion of government services are supported by teams that work in isolation. This means the responsibility to keep the service up and running is handed over to a team removed from digital strategy and departmental policy making. This support team is measured using service level agreements (SLAs) such as uptime or incident response time. However, the Government Digital Services (GDS) has identified that 88% of online services are essentially unmonitored and these crucial metrics are not well measured or reported.

By pivoting to an embedded delivery model, government departments can build strategy and policy directly into the support structures for live online services. All this makes continuous improvement an essential and measurable expectation of support service providers through the use of experience level agreements (XLAs). Government departments can also implement the government’s recommendation of not trading away short-term savings and meet CDDOs goals of a digital government that provides better outcomes for everyone.

How we can help

Made Tech is responsible for a wide range of government digital services. From the newly-created Maritime and Coastguard Agency’s (MCA) beacon service, to critical national infrastructure such as the Bichard 7 portal that was originally built in 2011. What these very different services have in common is that they’re supported using Made Tech’s transparent and user-led approach, meaning they’re not only maintained but continuously improved. 

By working closely with service owners and even more closely with users themselves, this iterative support model has removed the need for expensive replacement services to be built. It’s also led to users giving their thanks to the service support team rather than the frustration seen across so many other digital public services.

As we get the opportunity to shift more government services into a new way of doing support, the quality of the digital services provided to UK citizens can be improved rapidly. By doing things in this new and cost-effective way we can positively impact the experience of all UK citizens. Bringing a user-led approach to a space typically led by contractual response times will push engagement in online public services up from its current level of 50% and establish the UK as a global leader in online government services.

If you’d like to hear more from us on all things digital in the public sector, sign up for Made Tech Insights to get new content delivered straight to your inbox.

The post Making the UK a global leader in online government services appeared first on Made Tech.

We’d now like to share some of the insights we’ve drawn from conversations with various GOV.UK PaaS users and other stakeholders over recent weeks and also from our own research.

PaaS or passé?

One of our initial avenues of investigation was to assess the feasibility of continuing to run the existing platform (or something that looks a lot like it) by taking advantage of its open source lineage. We evaluated this approach with two specific outcomes in mind:

1. As a short term mitigation…

Reuse of open source GDS code would have the immediate benefit of backward compatibility, enabling existing services to be migrated relatively easily and retaining familiarity for maintainers. It would also buy additional time for those organisations that don’t have the budget or resources to migrate services elsewhere within the stated decommissioning timeline.

The existing GOV.UK PaaS platform is largely built on Cloud Foundry. We were able to spin up a test environment relatively quickly based on the code shared by the GDS team on GitHub to evaluate how straightforward this approach would be in practice.

Our conclusion is that the complexity of Cloud Foundry would make this approach more difficult than we’d like, although it remains an option if an inability to migrate elsewhere within the 18 month decommissioning timeline becomes a reality for our clients.

2. As a strategic way forward…

We wanted to understand better the viability of the platform as a long term proposition and particularly the potential impact of moving custodianship of a public sector-oriented PaaS from public to private hands. The blog post from GDS already hints at some of the reasons for backing away from the platform in its current form. We talked to the GOV.UK PaaS product team and a variety of users of the platform to glean more insight into current pain points and obstacles which may limit the feasibility of this approach.

While Cloud Foundry made sense as a foundation platform for GOV.UK PaaS back in 2015 when it was originally conceived, the technology landscape has since moved on significantly and it’s likely that it wouldn’t be the first choice today. The massive growth of containerisation technologies – particularly Kubernetes – and their widespread adoption across the industry is hugely significant. Cloud vendors have also upped their respective games and introduced more features and levels of service abstraction in recent years, which means prospective GOV.UK PaaS users now have many more options to choose from in comparison to 2015.

The increasing demand for access to more sophisticated data analysis tooling is also a limiting factor, with the current GOV.UK PaaS feature set missing advanced data processing capabilities.

It’s apparent that the charging model currently used results in significant hidden costs: for example, AWS data transfer fees are not passed on to users and are instead covered by GDS. Compute infrastructure is not shared, which often makes it uneconomic when compared to an analogous serverless implementation. All of this makes the platform much less attractive by comparison on a true cost basis, especially when compared to a potential equivalent based on more recent best practice architecture.

One final consideration is trust. GDS are a public body who have also built a reputation for reliability and high quality engineering over many years. New entrants offering PaaS solutions will have a challenge to build a similar level of trust in a relatively short time if they want to offer a migration path to existing GOV.UK PaaS users within 18 months.

Our conclusion here is that, on balance, given the constraints and downsides listed above, it doesn’t feel this is likely to be the best way forward for the majority of our clients. Other organisations, with differing needs and priorities, may think differently.

PaaStures new?

While considering the future of public sector PaaS, we also invested significant time in exploring other options for our clients and the wider GOV.UK PaaS user base.

Where we’re actively involved in delivering services on GOV.UK PaaS, we took the opportunity to assess realistic and specific ways forward for each of those assets. We also reached out via our networks to speak to as many teams using the platform as possible. As a final step, we trawled GitHub for the many public repositories behind GOV.UK PaaS services and analysed them to identify patterns and potential opportunities to optimise and ease migration to alternative platforms.

So what options are there? We can consider the standard six approaches to cloud migration:

And finally, for those teams who maintain their own infrastructure, bringing services back in house is also an option, although one that would go against policy and best practice for most public sector organisations.

While there is still more work to do, our research so far leads us to a few conclusions:

We have observed that most of the organisations using PaaS that we’ve talked to fall into three broad categories:

• Digitally mature – these tend to be larger organisations that successfully run their own internal development and support functions.
• Build only – organisations that have a development capability and can build their own services but do not have the resources or inclination to run and support them.
• Outsourcers – these organisations have minimal internal digital capability and instead outsource development and operation of services to external partners.

The majority of services running on the platform share similar architectures and characteristics. This is most likely a result of the deliberately constrained range of services on offer within the platform. We anticipate this leading towards the development of one or more migration playbooks, where common strategies, tools and assets can be reused and adapted relatively easily to meet the needs of the majority of current service architectures hosted on the platform. This approach may sit somewhere between the Rearchitect and Replatform strategies described above, or could result in independent playbooks for each of those options.

Many of the current user base are also running IaaS services on other cloud platforms directly. This implies a higher degree of digital maturity amongst that segment of users and perhaps indicates that rearchitecting their PaaS services onto IaaS would be a good strategy.

One of the key motivators for organisations choosing to use the platform was the integrated support. While many users will have the capabilities needed to maintain and support services themselves, plenty of others will not. The latter will either need to build those skills in house or will need to find outsourcing partners to fulfil that role.

Next steps

As we mentioned in our previous post, we believe that an inclusive and aligned community effort will be critical to finding an optimal way forward following the decommissioning of GOV.UK PaaS. We’ve had an incredible response from the stakeholders we’ve talked to so far and we’re hoping to find more people who’d like to get involved.

The post GOV.UK PaaS – an update… appeared first on Made Tech.

It’s because we’re so aware of the growing demand for these assessments that we’ve put together an all-in-one package to support your organisation through a DDAT assessment with minimum disruption to your organisation.

Benefits of a DDAT assessment

The Digital, Data and Technology Profession Capability Framework assessment explores the different job roles in the DDaT space. By running a DDaT assessment in your organisation, you can give your teams the opportunity to evaluate their skills and capabilities. 

Giving people the option to review their roles and responsibilities allows you to coach, mentor and upskill your people while growing the digital skills to build government fit for the 21st century. And by identifying, recognising and valuing the skills you already have in place, you’re better placed to retain people with with essential DDaT knowledge and skills.  

Using the DDaT framework, teams can learn more about what different digital roles do in government, understand the need for specific skills and plan pathways in their specialist field their career progression. Assessing your organisation against this framework can also help to review individual skills in preparation for performance reviews, create effective job adverts and carry out human resources and workforce planning. 

It’s no secret that teams across all areas of the public sector are stretched, with complex workloads and limited resources. And, not to toot our trumpets too hard, but we know a bit about digital, data and technology in the public sector – it’s what we do all day.  So we’re keen to help public sector organisations through their DDaT assessments, saving your team time and effort so they can focus on helping citizens. 

The complete DDaT package

We can support you through 6 core areas of your DDaT assessment:

1. Independent evaluation of your self-assessment including a detailed report 
2. Delivery management of your DDaT project
3. Upskilling, mentoring and bringing together Communities of Practice through the introduction of Heads of Community
4. Business analysis, including cost analysis and identification of individuals who align to the DDaT roles
5. Business case support
6. Communications and engagement support

We’re particularly pleased to offer communications and engagement guidance, which includes workshops for line managers and those staff invited to take self assessments to help you develop your DDAT strategy and communications plan to set up everyone in your organisation for success.

Supporting a central government department through their first phase DDaT assessment

We supported a large central government department through the first phases of their DDaT assessments. We ran an end-to-end package in the heart of the department, making sure their teams felt valued while also attracting new specialisms into the organisation. 

Focusing on the organisation’s specific needs, we were able to collaborate with them on their communication and engagement strategies, business analysis and workshops to brief line managers and those colleagues identified as sitting in Group 1 roles within the DDaT framework. 

By transferring our sector knowledge, we’ve coached the team and purposefully developed a programme they can confidently run without further input from us.

The option for the DDaT self-evaluation has meant staff can actively assess and improve their skills, working toward their career progression while encouraging cross-government digital capability and transformation. 

After work began, we were delighted to be kept on for another 12 months, supporting the organisation through the next phases of the programme. 

If you want to find out more about our complete package for DDaT assessments or have a chat about how we can help you, please get in touch below.

All-in-one, but tailored to your org

The beauty of this approach is that it’s cost-effective, thanks to the reusable assets we’ve developed, yet has the scope to tailor to your organisation’s needs with Made Tech experts available to support at every stage. If you’d like to talk more about next steps, please get in touch. 

If you’d like to talk

The post Announcing an all-in-one DDaT Capability Framework roll-out package appeared first on Made Tech.

We’re big fans of GOV.UK PaaS at Made Tech, and have been impressed with the good work the team has done to build a simple service allowing teams to avoid operating their own platform if they don’t need to.

So you might have been as surprised as us to hear this week’s announcement that GOV.UK PaaS is being decommissioned. This has naturally been a shock for all of us who have been using the service for many years and has left many wondering what comes next.

GOV.UK PaaS is popular for several reasons. But, put simply, it’s because it allows teams to quickly deploy their applications to an easy-to-use, fully-managed platform that needs minimal operational oversight and support. 

It provides a feature-rich ecosystem that meets the majority of user needs while managing to remain a simple platform to set up and deploy services to. This is no mean feat – especially when you consider those requirements! 

Being a government platform, it’s vital it’s a secure and accredited service. GOV.UK PaaS follows security best practice and is able to support handling data up to the “OFFICIAL” data classification, making it suitable for most use cases. It provides robust logging and monitoring capabilities, support for numerous coding languages, and has had an active development team keeping things up to date and adding new features all the time.

Most important for several departments is the fact that it provides a fully-managed service. This means departments without the in-house skillset or desire to provision and support their own infrastructure can easily use GOV.UK PaaS to get their services live. And they know there are experts at GDS handling their infrastructure and support needs. This is one of the key factors that contributed to the success of GOV.UK PaaS – so whatever replaces it will need to follow a similar model.

What’s next? We have options…

So that brings us onto the big question: what comes next? Obviously, this is not something we can answer alone and any potential replacement needs the input of the many teams who have been using GOV.UK PaaS and now need to figure out a way forward. 

We believe forming a community around this will allow us all to share our experience and ideas so whatever comes next works for as many services as possible, and taking the approach of working in the open will avoid any duplication of effort and enable a collaborative future to all of our hosting needs.

With 18 months until GOV.UK PaaS is turned off, we want to begin this discussion now and get as many teams as possible involved. We’ve already begun investigating what options there are out there to support our clients who will need to migrate from the platform so that we can bring our ideas and experience to the table.

Fortunately, we’ve already been working with clients to migrate out of GOV.UK PaaS as their needs and capabilities have changed. We’re now looking to accelerate our migration offerings to provide this to more clients who want to move their services into other cloud platforms such as AWS or Azure.

Our close partnership with AWS and Azure puts us in a good place to investigate options and bring their expertise and input into the wider community. Alongside this we’re beginning talks with GDS about their future hosting plans and needs.

We’re also building a prototype hosting platform here at Made Tech to replace GOV.UK PaaS with our own fully-managed service. This will build on the great work that the GOV.UK PaaS team has done over the years and provide the same level of support and ease of use for clients while offering an easy migration of services between the platforms.

We’re in a good position to do this due to our extensive experience with GOV.UK PaaS and other Cloud Foundry platforms, our deep understanding of our clients needs, and our track record to quickly turn around new services that support the needs of our clients.

While only in the early stages of this journey, we’re looking for early feedback and conducting user research to validate our assumptions and make sure we’re building something that meets the needs of our clients. We plan to begin onboarding our first round of clients within the next 6 months and keep the community updated with our findings and progress throughout.

To aid us on this journey, we need your help. If you’re currently using GOV.UK PaaS, we want to understand how the decommissioning decision has affected you and what would help you going forward. What are your fears? What threats and opportunities will this provide you? How does this impact your existing roadmaps?

We plan to build out the community of support made up of civil servants, suppliers, and cloud vendors to get a group discussion going. We’ll be continuing to blog about this and holding webinars and other focus groups going forward. We’ll have a prototype of our own hosting platform to trial in due course, too. If you want to provide your thoughts or join in with the community please get in touch below.

If you’d like to talk

The post GOV.UK PaaS – a way forward appeared first on Made Tech.

The importance of transparency

But I’m not going to lie – it was a rocky start. Partly, because I caught COVID at the very beginning of the delivery. Fortunately, my team stepped up in a big way, keeping pace in what proved to be a rapid and challenging kick-off. But there were other challenges too. As we got familiar with the code base, we realised that most of the skills we’d need were new to all of us. 

To be open with the client, we shared that we’d need to learn and get familiar with the core languages of the project as well as particular frameworks – let alone the actual code base and its bespoke approaches. 

Understandably, the client was concerned, but they soon realised that the technical requirements of the code base would be challenging regardless of familiarity with the languages. We introduced the concept of polyglots – developers skilled in various languages and methodologies – and the benefits they bring. In particular, we discussed skills including extreme programming (XP) and clean architecture principles. 

This validated the importance of being honest and transparent with clients. Almost always, they’ll give you the freedom to prove your worth. And it prevents a mismatch in expectations. But there’s still hard work to do and frank conversations to have. 

There’s no substitute for experience

There’s a lot to be said around coding standards and subjective expectations. Here I mean the kinds of things that you can’t learn from a book or tutorial. The things that somehow get done through the established ways of working with various ecosystems. It’s the kind of knowledge that experienced developers forget they ever learned. 

Experience is key. In a lot of cases, the specific problem can only be learnt  by doing – and in particular, by making mistakes and fixing them. Eventually, newer developers feel at ease contributing too.

My take is that the benefits of tribal programming can be significant, so to get up to speed quicker, it pays to get familiar with the tribe’s language as soon as possible. A team should have developers who have experience with a part of the tech stack, with overall expertise spread among the team. 

You’ll be better placed to support each other. And it can help prevent unnecessary debates about trivial stuff. Honesty and hard work are vital in building trust, but that can be a balance between expense of time and speed to deliver. But anything that creates an extra overheard can count against you when performance is measured by certain metrics.

Pragmatism beats prescriptivism

We didn’t strictly follow extreme programming, in that pair programming wasn’t a convention. Neither was test-driven development (TDD), the code being a reflection of code after patterns, but at least tested, which is sealing code to help with change. 

XP simplicity rules or design principles were not always followed. The test pyramid was inverted after an architectural decision to cover a lot more than a unit test, using tools that were more inline with front-end ways of visualising problems. 

The biggest challenge for us was that these tools did not lend well to “TDDing” problems, leaving us with that empty feeling of lacking the tools to do the job. 

The backend could facilitate TDD, but this was difficult because these integration tests, incorrectly represented as unit tests, seeded real databases at the expense of very slow tests. This meant minutes for a test in some cases when even seconds would be unacceptable. 

This was not the fault of any API developers and was endorsed by this framework. This had probably worked very well on small projects, but problems emerged when scaling up. The bottom line is we couldn’t immediately demonstrate the code discipline we wanted and expected to practise, and at best felt useless in immediately solving problems with aligned best practices. 

A lot of these ideas were born from good but misinterpreted ideas, which is hard to change when this has come out of using “better” coding practises. A good example is Ian Cooper sharing a story of TDD and what went wrong, which people interpreted as “only do end-to-end testing” and delete most other tests as it will just bake you in concrete. Which is a bit like a builder removing the underpinning of the house because you’ve put in stronger window frames and added a porch. 

When historical code is littered with bad unit tests, it can reinforce the idea that unit testing is in itself bad. I have seen this a lot in different organisations, where devs go overboard with testing frameworks and with the wrong kind of tests. And I include myself in that when first introduced to TDD. I contributed to the same anti-patterns without realising it, so I sympathise at how easily this happens, even with the best of intentions. 

Tackle one thing at a time

The next few months were about solving specific problems, understanding the good and the less good, and trying to influence change where possible. We successfully solved several features facilitating experience through the entire stack, and including other microservices outside of the immediate project. 

After 10 months of experience with the project, we were able to facilitate work done for another department. We made client end users very happy with features making their user experience better, where they’d previously felt ignored or neglected. 

As time has gone on, we’re now at the stage of talking about the future and how inefficient some ways of working have become. Even though the intentions are good, the productivity is measurably more stifled, and the bottom line is that code entropy is not just about surface level code rules. 

We’ve been able to integrate with other teams, facilitating a faster transfer of domain knowledge and the potential to pair with developers outside the Made Tech mindset, but this has been slow to adopt. Wider adoption is gearing up. We’re still a long way from applying first principles but in first gear and making progress to the next stage. 

The important thing to pass on from our experience is that change doesn’t happen overnight. Patience and conviction of cause will help solve one problem at a time. You need to forge alliances and earn trust that will help change to happen. 

The rest is hard work, determination, coupled with good practises and value-driven objectives. If you can’t measure and understand success, it won’t happen. You are also part of a team where the group mentality is what you’re bringing to the offering, and should be agreed and understood by most, to keep it well aligned and build the momentum needed to make change possible.

You can read more about Made Tech’s work with central government on our website.

The post Lessons from central government software delivery appeared first on Made Tech.

While working in the Ministry of Justice (MoJ), I worked really closely with the Made Tech team. I was so impressed with how this team approached the problem, and how much they evidently cared about their people and wellbeing. The programme Made Tech worked on was one of the biggest in MoJ, and it was a new journey for the organisation. Made Tech helped other teams to up-skill, build pipelines – in essence, to do things the right way. This did not go unnoticed.

A quick skim of the Made Tech site revealed a company that wanted to make real change – and having seen this in practice in MoJ, those ideals rang true. When you see it, when you experience it, when you get such great feedback from Made Tech people, it does make you sit up and take notice. So here we are: I am now a Delivery Principal at Made Tech, but still work with great clients, and (hopefully!) delivering great outcomes.

The joining experience

The pre-onboarding experience was remarkably smooth: my MacBook was posted out ahead of the start date, work accounts were set up in advance, and on day one, I was ready to rock and roll (well kind of – as we started at 8am). But, the enthusiasm on that first call injected us all with such excitement for the week ahead. 

The old adage of freelancing is that you arrive at the door, fire up the laptop and away you go – though I do appreciate this is not always the case. So I arrived in the Made Tech world, unaware of the onboarding process. I will call this the “safe landing” into Made Tech, getting to know the company, the teams and the people. 

To that end, and rather alien to me, I experienced a week of onboarding! It was full on, but it was such fun, and it really does help you to quickly embed yourself into the company, along with its people, culture and goals. The week consisted of interactive talks from all areas of the company, plus a 2-day collaboration exercise to learn about Made Tech’s ways of working, and the roles of other people on the team. By the end I was thoroughly exhausted, but in the best possible way. I had such a great week.

Onwards!

Though delivery is an aspect of work I really relish, the development of people and teams is one of the big reasons I joined Made Tech. Developing communities of practice to support the teams, and building knowledge bases of the best ideas and ways of working – these are the areas that excite me. To have time to do this and also develop individually is fabulous.

I‘m now working in central government, doing work that makes a real difference. My experience of working in various government departments will, I hope, add value. It’s so good to now be doing this with a company that strives to make a tangible difference to people’s lives. I have made a great decision, and I look forward to the journey that lies ahead…

The post Why I joined Made Tech as a Delivery Principal appeared first on Made Tech.