Solving these challenges will take more than policy. It’ll take practical tools that support better, faster decision-making. Software can play a key role in helping planning teams access better data, streamline workflows and design services that actually serve the needs of local communities. While it can’t build consensus or set policy, it can make the process of applying those policies more transparent and more consistent.

Local Government Innovation Hackathon

Our friends at the Ministry of Housing, Communities and Local Government (MHCLG) agree. So, at the end of April I spent an enjoyably exhausting couple of days at their Local Government Innovation Hackathon, hosted at Nexus, University of Leeds, exploring some great ideas for building AI-based tools that could be part of a new, more efficient planning system.

Government Digital Service (GDS) and the Incubator for AI organised the event in partnership with the MHCLG Digital Planning Programme and Open Digital Planning. It brought together a wide range of professionals from across the public and private sectors to have a go at tackling some of the most pressing challenges facing the UK’s planning system. The hackathon gave people the chance to explore and experiment with new ways of delivering modern public services.

Critical challenges within the planning system

Wisely, our hosts focused attendees’ attention on a limited number of critical challenges within the planning system. 

1. Housing demand forecasting: Can we develop predictive data models that integrate population trends, migration patterns and economic indicators to improve forecasting? This would help councils plan more accurately for future growth and make sure that public investment goes where it’s needed most.
2. Planning process automation: How do we address the manual, time-consuming processes that hinder planning officers, particularly when assessing complex planning applications? The goal was to look at automation and AI augmentation to speed up application reviews, document processing and predictive maintenance.
3. Public engagement in planning: Can we improve the limited and often ineffective public engagement in planning processes? Is there a way to translate complex planning language and visions into more accessible terms?
4. Infrastructure and housing balance: How do we plan for new homes while balancing infrastructure constraints? This would help planners understand the wider implications of planning decisions.

The judges were looking for 3 key things:

Joanna Averley, Chief Planner at MHCLG, led an intimidatingly A-list judging panel.

Rapid prototyping

Day one kicked off with registration and a welcome session, followed by an overview of the planning system and the challenge statements. Our team was a motley but well-rounded mix, including developers, data scientists, data engineers, testers, IT leadership and planning support.

Our initial discussions focused on identifying our target persona. In other words, who was our application for? We considered developers, planners, central and local government officials and members of the public. Ultimately we decided to build our solution with the local government official in mind. By 3:30 PM, we had a basic outline of our idea, and we began to build our app.

AWS had provided a team on site to help with technical issues, but they also provided some equally welcome refreshment in the evening, which briefly distracted us before a late finish.

Day 2 was an early start and we worked diligently on our application until the 1 PM deadline. The afternoon was dedicated to presentations and judging. 

The presentations were impressive, showcasing a wide range of skills and innovative approaches. The judges were clearly impressed by the effort and ingenuity demonstrated.

Using AI to improve local planning decisions

Our team developed ‘Dwella’. A smart scenario assistant designed to help non-planning specialists (such as local councillors) quickly explore the effects of local changes on housing development plans. We trained our solution specifically on data from the Cotswolds district, but it is adaptable to any planning authority.

Dwella uses Retrieval Augmented Generation techniques to preload locally relevant statistics and policy information into a Large Language Model (LLM), specifically Anthropic Claude Sonnet. This enables a user-friendly, conversational approach to understanding complex planning scenarios. We deployed the application through AWS Bedrock and also had access to forecasting models implemented on AWS Sagemaker. We developed a simple browser-based chat interface to make it easy to use.

Councils could roll out a tool like Dwella, helping save time and resources while giving people more confidence in planning decisions.

Teams demonstrated lots of other great tools at the hackathon. The winner was ‘Clio’. A tool to recover and analyse planning histories for individual sites. This is currently a costly and time-consuming process for planning staff.

What I learned about the planning and housing sector

I’m pretty new to the planning and housing sector and I came away with a number of observations.

1. Efficiency is key: Although the second challenge was very clearly focused on efficiency, almost every project focused on improving it. It’s clear that the planning process is often cumbersome and time-consuming for everyone involved, including planning officers, developers, citizens and decision-makers.
2. Data skills gap: There’s a real need to educate the planning and local government community about what modern data tools can do and how to use them. Above all, we need to create software solutions that are simple, intuitive, easy to learn and clearly deliver immediate benefit to users.
3. Data challenges: The data ecosystem for planning is fragmented and complex. We encountered a wide range of datasets in diverse formats and with diverse standards. Much is unstructured and held within documents. Data discovery is often reliant on lore passed from person to person, although there are valiant attempts such as the Digital Planning Directory which try to address this.

Technically, the main eye-opener for me was Bedrock, the AWS interface for LLMs. I have some experience of building agents and RAG tools, but it was great to see how AWS has provided a useful abstraction layer over the complexities of individual Large Language Models (LLMs). I have some reservations about potential costs and ease of deployment. While it simplifies some aspects, I’m concerned that it might also obscure important configuration details. But we are still very early in the AI revolution and it will be interesting to see how tools like Bedrock evolve.

Hackathon warm-down

It’s called a Hackathon for a reason. Perhaps it wasn’t as gruelling as the London Marathon, but afterwards I felt a happy, exhausted sense of having learned a lot about the planning system and about some tools that might be useful in revolutionising it. Well done, and thank you, to our friends at MHCLG, GDS and i.AI. Let’s do it again, soon.

If you’re curious about how we help government organisations access data more easily and design services that work for real communities, take a look at what Made Tech do with local government here. You might want to browse some of our data and AI case studies too.

The post What happens when you hack the planning system? appeared first on Made Tech.

Behind those services is a wealth of infrastructure and architecture built to support the changing needs of ever-adapting civic services. But how do we make sure what we’re building is fit for the future? This is where AWS Well-Architected can help.

All things AWS Well-Architected

AWS Well-Architected is essentially a best-practice guide for cloud architects. It’s a great way of going through what you’ve built and how your AWS management is set up to make sure you’re doing it in a responsible way that’s also high quality. By following a simple framework, you can make sure you’re effectively reviewing your architecture design. 

The AWS Well-Architected framework documents an approach that allows you to understand if a specific architecture aligns well with current cloud best practices. To support Solution Architects and Chief Technology Officers, the framework gives a consistent approach to evaluating systems against the qualities you expect from modern cloud-based systems. Though this may sound complicated, it’s actually pretty simple. 

The review is built around 6 pillars: 

• operational excellence
• security
• reliability
• performance efficiency
• cost optimisation
• sustainability

These pillars will be familiar to seasoned DevOps engineers and not come as a surprise, but the AWS Well-architected review moves it into the 21st century.

Let’s talk functional and nonfunctional

The review raises the importance of different aspects of your build. It focuses on both the functional features you need to build to make the service work, and also the nonfunctional architecture, where we think about things that will help us if the service goes down suddenly. 

The type of questions it asks the development team to get them thinking more about nonfunctional parts could be:

• do we know if the service is working well? 
• can we recover from disaster? 

This is particularly important, but easily overlooked. When we think of cloud architecture, it’s easy to think only of what we’re building, but we need to make sure we’re giving equal focus to the other supportive stuff too. Leveraging those nonfunctional requirements is crucial and the review is a good way of making sure we’re doing it effectively. 

To give an example, a client we recently worked with provides emergency services to people in the UK. They use digital tools in emergency situations and often have to work quickly. So if the performance of the digital tool is poor or it’s just flat-out broken the business impact is significant.

Through the review, we were able to make sure there were these crucial nonfunctional considerations and solutions in place. It’s very easy to focus on what features your service should have, but the context of the user’s working environment is not always a focus of the architecture leading to performance and reliability becoming a second-class system. The well-architected review helps us shift the focus a bit. 

Benefits of a well-architected review

There are 3 main areas of benefit that I see in reviewing projects using the framework.

Reframing our retros

It’s really useful to have this ongoing technical review. In lots of ways, it’s similar to a retrospective. Often we’re focused on delivering: doing the stuff and getting the features out there in the world and improving ways of working. But this review adds a regular cadence of looking at what we build from a technical, performance, operational or security or perspective and asking penetrating questions.

This retrospective is a practice you actually do over several sessions. And then you record it in the AWS app. You keep track of your notes and the days you made them. You can revisit at any point and say “we were going to do this” or “this was a risk – have we solved it?”.

We don’t always do this type of architecture retrospective, and that’s where AWS Well Architected Review nudges us in the right direction. Asking have we forgotten to do some things or do we need to do more? 

Knowledge sharing

There’s a bit of knowledge sharing in there as well. By doing these retrospectives and talking about what we’ve done and what we haven’t, people in the room can say “oh, I didn’t realise we did that”. Because people move around on projects a lot it’s good to do these check-ins. 

It helps us all think a little bit more through the lens of support, and particularly what operational aspects we may need in place to help the team. It helps us think beyond just building the thing and getting it working. It’s a good thing for our team to do regularly and helps our software engineers to learn best practices for any future projects. 

ROI is crucial

We’d be wrong if we didn’t mention return on investment. Taking on the well-architected review is great for organisations to help their design teams truly deliver a higher quality technical service. And bonus – it’s less likely to fail. Not only that, it also means having a service that’s easier to work on and much better understood by everyone involved. 

Best practice for all 

Ending on a high, what I really like about AWS Well-Architected is that more widely it can be described as best practice for all cloud operations. It takes the best parts of those good old-fashioned cloud ops practices that have been around for a very long time and gets rid of what’s not relevant anymore. 

It’s clear, easy to work through and provides a really great framework for helping us evaluate architectures and implement scalable designs in the public sector. 

If you want to learn more about how we can support you with AWS well-architected, please get in touch. Or if you’d like to learn more about the work we do here at Made Tech you can subscribe to our Made Tech Insights newsletter to get new blog posts straight to your inbox.

The post AWS Well-Architected: building digital services fit for the future appeared first on Made Tech.

Last month, we reached a huge milestone in our AWS journey by becoming an accredited AWS Government Competency Partner. Made Tech is now one of a handful of accredited partners in the UK specialising in the public sector. Here’s a closer look at how we got here, and how the accreditation will help us deliver increased value to the organisations we work with. 

Meeting the needs of the public sector 

Every day we work with brilliant public sector teams to help build modern services and accelerate digital deliveries. In time, we’ve increased our investments and focus on using AWS technology to help our clients. Securing the AWS Government Competency means we’re recognised as an AWS partner that can deliver projects at pace and scale, as well as provide increased assurance we’re following industry best practice.

This is very special for us. We wanted AWS to see us as a partner that can take difficult projects on board, and deliver them in the most appropriate way. We also wanted to show to public sector teams that we understand how they expect us to perform, and that we can help them deliver the best possible outcomes for their users. 

Reflecting, filling the gaps and shifting our mindset 

One part of the competency requirements is to show that we have the right tools, processes, culture and mindset to deliver our services to the public sector. We got a deeper insight into AWS best practice, so we can give public sector teams the best experience. 

During the audit process we were scrutinised at a level that gives us the confidence that the work we put in is fit for purpose. It was important for us to recognise the investments needed to make sure documentation and processes were at the level needed. 

Getting the right level of detail was challenging. It wasn’t a blocker, but a step change in our mindset on the importance of having detailed processes in place. These will help us continue to improve the way we deliver cloud services as we’ll have set standards and practices in place that we know work, and which we can continuously improve on. 

Taking learnings, and continuing to grow

We want to make sure we’re influencing future thinking around how the teams we partner with use cloud technology. We’re looking for new competencies to help us continue to grow, be it at an industry level, like healthcare, or through a technical lens like transforming legacy technology – which continues to be a massive focus for us. Our AWS partnerships also help us show what we can do for and in the wider world. 

Bringing the best of our teams together

I feel immensely proud of the Made Tech team and our approach on this journey. It’s a learning experience we’ve gone through together. There wasn’t much waste in the process. This competency brings the best of Made Tech and AWS to public sector organisations, so we can work better together.  

Find out more about our partnership with AWS and how we can help you.

The post How AWS Government Competency will help us deliver more value for public sector organisations appeared first on Made Tech.

The cloud’s become the de-facto deployment platform and with this transition has come a step-change in ways of working for IT service providers, software companies, their engineers, and clients. Most organisations at minimum expect suppliers to have the capabilities to run secure, resilient and scalable solutions in the cloud. It helps to release them from the overheads of managing on-premises data centres and associated servers, databases and other infrastructure. It also helps to manage costs while keeping the lights on.

Bridging the gap and making the most of the cloud 

With such a huge range of cloud services available, inexperienced teams may become overwhelmed by their options. With our experience, we can position ourselves to bridge the gap and help organisations make the most of the cloud. We can reduce their risk and help them to develop their own understanding of how to use cloud-based solutions. 

The AWS tech stack is one of the platforms we use to help organisations build services in the cloud. We’ve been AWS certified since 2011 and currently hold AWS Advanced Partner status. We’re also an AWS Government Competency Partner. It means we’ve shown we’re AWS technical experts with proven success on public sector projects. To get AWS Partner Network accreditations like this, organisations have to do strict technical assessments and show they follow industry best practices. 

Boost your career and help your organisation deliver better

Team members can also get AWS certifications. We have around 60 AWS certified engineers at Made Tech. The certifications can help with career progression. Being AWS certified shows you’ve got a deep understanding of AWS technology, and are a cloud expert that can help deliver projects quickly and efficiently. 

But it also benefits the organisation. It affects our ability to get AWS competencies and join other AWS programs. For some of these programs you need a minimum number of team members with certifications at different levels. This includes the partner network, and other programs. For example, the AWS Well-Architected Framework. An AWS partner with this capability can do well-architected reviews of organisations’ cloud workloads, and implement workloads following AWS best practices around things like security, scalability and resilience.

It’s strongly encouraged in our engineering community to get certified. We get given time for exam study and preparation. We also get training materials with our annual training budget. 

If you work in IT and are interested in getting AWS certifications then it’s worth having a basic understanding of the different pathways and levels…

AWS Certified Cloud Practitioner

At the foundation level is AWS Certified Cloud Practitioner. This one’s for anyone with a basic understanding of the AWS platform. Amazon recommends that you have:

• a minimum of 6 months using AWS Cloud
• a basic understanding of IT services and their uses in AWS 
• knowledge of core AWS services, use cases, billing and pricing models, and security concepts

You’d typically start your AWS certification journey with this one before moving onto one of the more specialised exams. To get it you need to sit a 90 minute exam with 65 questions. You need a score of at least 700/1,000 to pass. 

Associate 

The next level is associate. It takes team members down role-specific paths. You can earn AWS Certified Solutions Architect, AWS Certified Developer and AWS Certified SysOps Administrator. Each of these exams follow a similar format to the cloud practitioner exam but test your knowledge to greater depths in more focused areas. These include 65 questions and you get 130 minutes (180 for SysOps) to complete the exam. You’ll need to score at least 720/1,000 to pass.

Professional 

Beyond associate level you can earn AWS Certified DevOps Engineer and AWS Certified Solutions Architect certifications at a professional level. Again, exams for these go into even greater depth and thoroughly challenge your knowledge and time management. These include 75 questions which have to be completed within 180 minutes. To pass you need to get a score of at least 750/1,000.

Speciality

If you want to show your experience and competence in more specialised areas you could also get one of the specialty level certifications which include:

AWS Certified Database – shows you’re an expert in recommending, designing, and maintaining AWS database solutions.

AWS Certified Machine Learning – shows you’re an expert in building, training, tuning, and deploying machine learning models on AWS.

AWS Certified Security – shows you’re an expert in securing data and workloads in the AWS Cloud.

AWS Certified: SAP on AWS – shows you’re an expert in designing, implementing, migrating, and operating SAP workloads on AWS.

AWS Certified Data Analytics – shows you’re an expert in using AWS data lakes and analytics services to get data insights.

AWS Certified Advanced Networking – shows you’re an expert in designing and maintaining network architecture for AWS services. 

Depending on the exam, you’ll get either 170-180 minutes to finish it. There are 65 questions. You need a score of at least 750/1,000 to pass. 

For now, you can take any AWS Certification exam at either Pearson VUE or PSI testing centres, or you can sit them remotely from home via Pearson VUE’s online proctoring system. From 1 January 2023, Pearson VUE will be the only exam provider.

Useful resources

The AWS certifications page on its website is a good place to get started. 

Udemy

You can also find training material on learning platform Udemy, which I highly recommend. For example, you can do an AWS Cloud Practitioner course, created by online instructor Stephane Maarek. Stephane and others like Neal Davis are certified solutions architects and developers. They’ve produced many high quality training courses and practice exams for most of the available AWS certifications. The courses are definitely lengthy (30hrs plus for associate level and higher) but they do need to go into a lot of detail to cover the large syllabuses for each exam.

AWS learning materials

Take a look at AWS Whitepapers. They can help broaden your knowledge in specific areas beyond the material in the training courses. The reference architectures can be useful if you’re aiming for AWS Certified Solutions Architect at associate or professional levels. 

We also recommend making maximum use of the AWS free-tier. It allows you to deploy your own infrastructure and services in the cloud at minimal cost, so you can gain practical experience beyond all of the theory in the online training materials.

The hard work will pay off! 

It may seem daunting and there’s certainly a lot of material to cover – there are currently over 200 individual AWS services. From our experience, you’ll need to put in intense effort, especially when it comes to your time and focus to get any certification beyond foundational level. But developing your AWS cloud knowledge and expertise will be rewarding and hopefully open up new opportunities for you and your organisation.

Find out more about our work with AWS. Read our latest case studies, Streamlining data flows to improve insights in adult social care and Making NHS Gloucestershire’s mental health services more accessible to children and young people to find out how we’ve used AWS technology to help improve public services.

The post AWS certifications: what does it take to become a cloud expert?  appeared first on Made Tech.

In this post, we want to dive into a really interesting and challenging part of the project: the SMS text messaging interface. Though the main service is fully accessible online, the team wanted to make sure it was available to as many people as possible, so we also built an SMS text messaging interface for people who, for whatever reason, are unable to access a computer or smart device. In this post, we want to explore why we built this channel, and the challenges we faced along the way.

Making mental health services for children and young people as accessible as possible

Gloucestershire has a wide range of mental health services. The services help young people with depression, problems with food and eating, self-harm, abuse, violence or anger, and anxiety, among other difficulties. So it’s really important that people are able to get to the right support service as quickly and easily as possible. It’s this signposting that the service was designed to do.

As you’d expect, the team built a web service based on multiple-choice questions to make the service as easy to use as possible. The user research team also identified that an SMS text messaging interface was vitally important in making the service as accessible as possible. Though we don’t necessarily anticipate the text messaging interface being in high demand, it’s an important way to make sure the service is accessible to as many people as possible. 

This includes people who don’t have access to a computer or smart device – but also, crucially, people who may be prevented from accessing those devices. Given this context, we were keen to put time and effort into this channel to make sure that no one gets left behind.

Creating a fully-functional CMS 

A key part of the project was to create a new content management system to manage the information users engage with when they use the service. 

The questions posed to users were developed alongside clinicians, and were hard-coded for both the web and text service, which means it can’t be readily changed. So we had to make sure this information was 100% accurate, and get it signed off by the risk management team. Getting this to work for the text as well as the web service was probably our single biggest technical challenge on this delivery. 

Behind the scenes, both services rely on the same information, but it’s presented to the user in very different ways. On the web, multiple choice questions are a good option, but with a text service the user needs to reply to a series of questions with a word or a number. 

These different interfaces pose significant challenges for managing the underlying information and it took a lot of user research to get this right. Mace & Menter provided user research for the whole project, and derived which “tags” were attached to questions, forming the basis of the design of the question and answer algorithm which we went on to implement.

The combined work of Mace & Menter and NHS Gloucestershire helped us rapidly iterate through discovery, alpha and beta phases, and user research insights were indispensable for the text part of the service in particular.

SMS limitations

The text component was most difficult to implement. We were fundamentally limited to a total of 918 characters (6 text messages’ worth) in any one interaction, so we had to make sure all questions and instructions were under 918 characters at a time or they wouldn’t send. 

This presented a UX challenge. We had to meet the character count while making sure all information users would need is clear in each message. Web content was easier to edit because there was no word limit and a lot of the information was freely available on the NHS site.

We integrated with GOV.UK Notify to handle the messaging. This lets public sector organisations send emails, text messages and letters to their users. It solved so many problems for us right from the outset, but did present a few challenges when testing and demoing. 

For example, before going live, we were limited to sending a total of 50 messages a day, of 160 characters each. Again – some questions spanned multiple messages due to their content, so we’d often use up our allowance in the testing stage, and by the time we got to demos, the service wouldn’t actually work. This mainly meant we had to be a bit strategic on demo days, but wasn’t a limitation when the service went live. 

Though the service is called GOV.UK Notify, its ability to allow replies from end users was absolutely essential. Harnessing this functionality is a big reason we felt that we fully embraced the power of the service.

Throughout this work we fully embraced AWS Cloud Services and AWS Managed Services wherever possible (focusing on ECS, ECR, RDS Aurora, DynamoDB, Codepipeline, S3, AWS WAF V2). Using this tech across our hosting, integrations, release, and storage needs allowed us to create a truly reliable, scalable, and secure service that puts the needs of people first.

A template for future projects

This was the first time we’d worked on a mental health project for children and young people. On the whole we were able to work in the agile manner we strive for. We successfully responded and adapted to new requirements as they came in.

Making sure everyone was aligned on desired user-outcomes and specific technical requirements for content management in a clinical setting, and how it was set up, was challenging. The need for clinical safety is paramount, and we quickly learned that this means much extra time is needed to make sure the content is right the first time.

We now have a better idea of how much time we need to spend with the wider team to make decisions. For example, we’ll bring the developers in earlier to help us ask the right questions to identify user needs. 

We filled out loads of clinical governance forms throughout which expanded our knowledge of the clinical risk process, and helped us figure out people’s responsibilities. But there were governance layers that we didn’t anticipate, which did slow us down somewhat. 

Understanding the process for clinical governance was another learning point for us. We learned that working with the governance team in parallel on these approvals helped to speed up delivery. As partners, we needed to be aware of the clinical governance approvals that needed to be in place, and as a blended project team, we found it was most effective to get the ball rolling on governance approvals as early as possible, as these important checks can take a while to get right.

Involving governance partners and approvers from the start means there are no big surprises for anyone that might be showstoppers. We learned that it’s important to talk to your governance teams as early as possible so everyone is in the loop and ensuring what is built will meet all the checks.

We’re now in a better place to identify hurdles as early as possible, and make sure the right checks and balances are in place. We’ll draw on these past experiences to identify challenges earlier on so we can mitigate them, and use our work with the NHS in Gloucestershire as a template. This will free up time to focus on other challenges and build on our previous success. 

Our main takeaway from all this is that delivering projects that provide clinical services to the people that need them can be incredibly rewarding. But you need to plan things out carefully. 

Making the best possible version of technology

We’ll know more about the impact of the service when it’s been live for a while, but what we can say right now is the process itself was super-fulfilling. We had really good relationships with the stakeholders in Gloucestershire, who were fully engaged throughout so we could collaborate to build the best possible service. Being aligned on our goals and objectives helped to ease the strain on the challenges we faced.

Even though it was difficult at times, we kept reminding ourselves of its importance and how worthwhile it was to create something that can help so many young people get the help they need quicker and more efficiently.

Visit our health and care page if you’d like to read more about how Made Tech delivers technology projects in the health sector.

The post Creating a text-based SMS service to make mental health services for children and young people more accessible appeared first on Made Tech.