Our success is rooted in five core principles that guide every interaction and delivery phase:  1. Listen to the users We engage users at all stages of the development lifecycle. This ensures we understand their needs and motivations so we can develop services they want to use. 2. Design a coherent and holistic solution We focus on understanding strategic objectives. We then use design thinking to iterate towards a complete solution that solves a whole problem. 3. Build balanced, cohesive and empowered teams We deploy high-calibre teams who share our clients' goals. Our teams are collaborative, communicative and iterative. 4. Deploy the right technology We advocate reusability by using standard government components and patterns when possible. We publish to open repositories when it is safe to do so. 5. Build, measure, learn! We learn with each iteration. We use evidence-led, hypothesis-driven development to make product decisions. We leverage prototyping, continuous integration and continuous delivery (CI/CD) and data analytics to move quickly. Kick-off of a Scrum project Scrum is a framework for delivering complex digital services where requirements are subject to change. The focus is on achieving a high-quality, shippable increment of work within a fixed timebox. We often apply this methodology to the Discovery and Alpha phases of the Government Digital Service (GDS) service standard. Objectives, goals, and outcomes Category Description of kick-off focus Core principles applied Objective Establish a rhythmic, transparent, and outcome-focused  delivery cadence, ensuring alignment with the GDS Service Standard from day one. #3  (Build balanced, cohesive and empowered teams) Goal Create a prioritised, estimated Product Backlog  and establish a shared Definition of Done (DoD)  and Definition of Ready (DoR)  that meets the client’s quality and security criteria. #2  (Design a coherent and holistic solution), #5  (Build, measure, learn!) Outcome Successful completion of the first Sprint with a potentially shippable increment, leading to the necessary evidence and research artifacts  required to pass a formal Alpha or Beta GDS assessment. #1  (Listen to the users), #5  (Build, measure, learn!) How we collaborate with our client Our kick-off is a high-tempo, collaborative process designed to embed you into the heart of the delivery team: Product Owner (PO): The PO is empowered to drive the service vision, goals, and backlog prioritisation. By holding this decision-making power, the PO ensures we meet Service Standard  #2: designing a coherent, holistic solution that works for users across all touchpoints. We can either work with the client appointing a dedicated Product Owner to join our team - or we can provide one to act on behalf of our client and service users.  Co-creation of the backlog:  We conduct an intensive kick-off workshop over 2 to 3 days. This session defines the initial Minimum Viable Product (MVP), breaks it down into user stories, and groups them into Epics. This ensures that the focus is on #1: Listen to the users  by turning user needs into actionable development items. Establishing ceremonies:  We agree on the frequency and focus of all Scrum events (Sprint Planning, Daily Stand-up/Scrum, Sprint Review/Show & Tell, Retrospective). The Sprint Review is explicitly positioned as a client-facing event, ensuring transparency and providing the empirical data required for #5: Build, measure, learn! Benefits to the client in our approach Client Benefit Description Faster time-to-value By focusing on limiting WIP and optimising the flow, we drastically reduce the amount of time it takes for a user need (such as a small feature or bug fix) to get into the hands of the end-user. Improved operational stability The visual nature of Kanban and the focus on cycle time allows the client to predict delivery with greater accuracy and immediately spot and resolve recurring bottlenecks. User-driven optimisation We establish a clear process for incorporating findings from continuous user research (which aligns with #1: Listen to the users ) directly into the Kanban Ready  queue, ensuring that all work flowing through the system is high-value and user-centric. Kick-off of a Kanban project Kanban is a flow-based system ideal for continuous delivery or managing fluctuating demand. This is suited for clients managing services in Beta or Live phases that require continual improvement. Kanban project focus Category Description of kick-off focus Core principles applied Objective Establish a smooth, efficient workflow and optimise lead time from idea to delivery. #5  (Build, measure, learn!) Goal Map, visualise and limit work in progress (WIP) across the service pipeline. #2  (Design a coherent and holistic solution) Outcome A visible Kanban board that provides transparency on service flow and cycle time metrics. #5  (Build, measure, learn!) How we collaborate with clients Our collaboration model focuses on process mapping and operational excellence: value stream mapping (VSM):  the kick-off starts with a collaborative VSM session with your operational and business leads to map the current process for a work item, such as a bug fix or a feature request. This supports our second principle: design a coherent and holistic solution visualising the flow:  we design the digital Kanban board with columns derived from the VSM, such as 'ready', 'analysis' and 'live'. We jointly agree on the WIP Limits for each column, empowering the team ( #3 ) to prioritise and focus. continuous feedback loops:  we establish service delivery and operations reviews to focus on flow metrics, such as cycle time and throughput. This evidence-led focus is the foundation of #5: Build, measure, learn! Benefits of the Kanban approach faster time-to-value:  limiting WIP and optimising flow reduces the time it takes for a user need to reach the end-user improved operational stability:  visual boards and cycle time data allow you to predict delivery and resolve bottlenecks user-driven optimisation:  findings from continuous user research go directly into the 'ready' queue to ensure work is high-value

It was a typical gloomy day in January when a group of our consultants visited Newham Collegiate Sixth Form Centre in East Ham. We ran a workshop for students eager to explore careers in tech. We offered a genuine look at working in the sector by sharing advice on: how to get into tech the diverse roles available how our work contributes to designing and developing digital products The students showed an impressive level of awareness and knowledge of the sector. The detailed nature of their questions truly highlighted their curiosity and ambition.  Mentoring the next generation But that is not all. Nineteen of our consultants have signed up to mentor the Year 12 students. We are excited to offer bespoke guidance as you navigate choosing your future path, such as: upskilling for a degree apprenticeships internships graduate roles in your chosen field At Solirius, we are passionate about nurturing talent and look forward to mentoring the next generation of tech professionals. A huge thank you to Anita Lomax and Newham Collegiate Sixth Form Centre for having us. We are excited about working with you in the future. Nine Solirius consultants participating in a technology career workshop at Newham Collegiate Sixth Form Centre, all smiles and thumbs up, showcasing their enthusiasm and expertise.

As we slide into the Christmas season, the team at Solirius Reply is channelling a bit of holiday spirit into things that really matter. Sure, we love the day job, but giving our people the chance to support the community around us is something we’re genuinely proud of.  This year, our brilliant staff are getting stuck into a range of initiatives that bring a bit of warmth, safety and hope to people across London. Sharing a bit of festive joy We have taken part in Dunelm’s ‘Delivering Joy’ initiative, where our staff receive a tag with a personalised wish on it and buy a gift for someone in need. It’s a small act of kindness that can make the holidays feel a little more special, especially for those who might otherwise go without. Supporting the homeless community We laced up our shoes and lent our time to Hackney Night Shelter. Our team volunteered at their fundraising quiz event and raffle, helping to raise essential funds that allow the shelter to provide critical overnight accommodation and support services to those experiencing homelessness. We also had staff conducting bucket collections in Dalston on December 11th — every donation helped keep the shelter running. Aiding women and children escaping domestic abuse Solirius Reply has also opened an opportunity for our team to donate to Refuge, a charity providing life-saving safety, support, and hope to women and children escaping domestic abuse. This is an essential cause, and we are honoured to support their tireless work in providing secure futures. Keeping the momentum going into the new year And because the community doesn't pause between the holidays and the new year, we’re offering staff the chance to volunteer during this quieter period too. It’s a small way of making sure support keeps flowing when many other services take a breather. All of this is driven by our people, their enthusiasm, their compassion, and their willingness to step up. It’s one of the many reasons Solirius is such a great place to work. Keep an eye on our page for updates on what the team gets up to, and here’s to a season filled with kindness.

Newcomers Kayenat and Arabella share their experiences of the Solirius Graduate Academy Arabella After completing a Modern Languages degree, followed by an intensive UX design course, I joined Solirius as a Graduate Digital Consultant this September. I'm excited to be working within a user-centred design (UCD) team that is motivated to make services more inclusive and ethical in the public sector. Kayenat Coming from a non-technical background, I was pleasantly surprised by the seamless transition Solirius has enabled for me to join the team as a Graduate Digital Consultant. I’m looking forward to learning and developing my skills in the UCD team and contributing to meaningful digital solutions. Overview of the Reply Group Solirius is part of the Reply Group, a decentralised network of specialist companies around the world focused on designing and implementing innovative solutions in the Digital Services, Technology and Consulting fields. Its global scale creates an impressive culture of knowledge sharing: I’m currently taking a Gen AI for Digital Experiences  course run by Reply experts, which has offered fascinating insights into using AI tools effectively. The social side is equally vibrant, with events running throughout the week, from pottery and sports sessions to foodie meetups - a brilliant opportunity to meet colleagues from other companies and enjoy some delicious food. Arabella Initial Thoughts Beginning my first full-time role was both exciting and a little overwhelming. Stepping into a huge corporate office for the first time brought a mix of nerves and anticipation, but joining the Graduate Academy made the transition much smoother. Being surrounded by others at a similar stage created an immediate sense of community that grew as the weeks went on. On our first day, the founder of Solirius, Hemel Popat, spoke about the company's origins, values, and vision for the future. This set the tone for the rest of our training, helping us understand how employees find purpose in their work, particularly given that many of Solirius' projects serve the public sector. Kayenat The Graduate Academy The Graduate Academy introduced us to life at Solirius through structured, hands-on training led by senior staff. Each session included practical tasks that mirrored the team’s day-to-day work. The sessions covered a wide range of topics across various practices, including workshops on design ideation, QA testing, cloud and DevOps, as well as informative sessions on neurodiversity awareness and agile delivery methodologies. Becoming a T-shaped Consultant Although we would soon join different practices within Solirius, the Graduate Academy brought everyone together to tackle technical, design, and business challenges as one group. This reflected the company’s focus on developing T-shaped  consultants, people who have deep expertise in their primary discipline and a broad understanding of others. The Academy helped us start building that breadth by introducing us to the language and methods of adjacent disciplines. For those of us joining the design team, this meant stepping into unfamiliar areas like GitHub workflows, DevOps, and automation testing. Gaining exposure to these tools helped us develop empathy for the demands of other disciplines, enabling us to collaborate effectively in multidisciplinary teams. The Case Study Challenge We were pleasantly surprised by how involved senior leadership were: leading and participating in workshops, sharing insights into Solirius' foundations and future, and making us feel comfortable contributing to discussions.  I found the workshops simulating real team structures, such as the session on Stakeholder Management led by the business consulting practice, really insightful. The task mimicked a real-life project team gathering stakeholder requirements (with members of senior leadership acting as tricky stakeholders), developing a presentation, and a minimum viable product (MVP), to demonstrate our understanding of the scope.  We had the opportunity to organise ourselves and our ideas, as well as implementing best practices we had learnt, such as sprint management and creating tickets. This not only strengthened my technical skills but also fostered a sense of team work and innovation from the very beginning. Kayenat The Debugging Challenge In brief, debugging involves finding and fixing errors in code. After an overview from a senior software developer, we were assigned the task of fixing a “broken” Ruby on Rails app in teams of three, guided only by a clue document. We weren’t allowed to use AI, which pushed us to explore the file structure and gain a deeper understanding of how the app worked. Each group included someone with a background in software development, which meant they often had to explain their thought process and decisions to the rest of the team. This encouraged collaboration as we relied on each other to establish a shared understanding. By the end, the challenge gave me a clearer understanding of how code is structured, which helped hugely when it came to creating our own apps. Particularly, it enabled me to develop greater empathy for the demands of a developer role. Arabella Final Project- The Journal App The journal app was our only individual challenge, which we spent a week tackling. Our challenge was to create apps using Ruby on Rails, putting into practice everything we had learned during the past five weeks of the Graduate Academy. It was fascinating to see how personal and professional interests shaped the apps we built. This resulted in a wide range of engaging and technically impressive ideas, which were insightful to listen to during the presentations. Mini Projects, Major Learning: I developed a recipe scaling calculator app based on my personal interest in baking (and eating baked goods). While the technical elements of coding the app seemed daunting at first, the consultants supporting our journey made it much less intimidating by guiding us through the building blocks, then leaving us with the creative freedom to express our skills and ideas. We had the autonomy to prioritise our workload, which led to a variety of apps showcasing a range of expertise from software development to user research. I found the journal app project strongly paralleled the Software Development Life Cycle (SDLC). This is the process of planning, designing, developing, testing, and maintaining software systems. In particular, I enjoyed the iterative stages of adapting designs, accessibility testing and debugging my app, shown in these examples below. A key takeaway from this was ensuring the user research informed my decisions throughout the journey. By working through the phases of the SDLC on a smaller scale, I could visualise how team members would collaborate in a real working environment. Design Process Scaled recipe feature Accessibility testing with WAVE Kayenat Fast but Flawed: What I Learned from Using AI-Generated Users With the aim of creating an app to improve the teacher recruitment process, finding real participants in just a few days proved to be difficult. To keep the project moving, I decided to experiment with AI-generated participants. After defining my research goals, I asked ChatGPT to review public forums and teacher community discussions. As requested, it rapidly generated five user examples and fifteen key insights. Despite the speed of this exercise, the limitations quickly became clear: I couldn’t verify the insights nor ask more probing questions to uncover underlying problems. For example, when the AI users mentioned specific frustrations with the Teaching vacancies service (like missing job view analytics), it lacked the means and the real teachers to confirm if these were accurate pain points. This experiment showed that while AI can be a powerful rapid discovery tool for identifying likely challenges and broader trends, the uncertainty around its data sources means AI-generated user research isn’t yet reliable enough for high-stakes projects. Arabella AI Prototyping: The Risk of Visual Sameness When brainstorming ideas, I used Figma Make to quickly build a working prototype with my planned features. Visualising the concept helped me spot missing elements and evaluate which features were truly necessary. The tool’s main limitation, however, is that it often produces visually similar results, offering little variation regardless of the prompt you enter. This became especially clear when comparing early prototypes amongst our graduate group: for those of us using AI design tools, the results looked strikingly similar. Figma Make: Different Briefs, Similar Design. 1st prototype. Figma Make: Different Briefs, Similar Design. 2nd prototype. The two examples above illustrate this issue. The first example is my teacher recruitment app prototype and the second example is a prototype I generated for individuals looking to improve their physical strength. Repeating the experiment with Lovable (another popular AI prototyping tool) produced similar results. This highlighted the risk of generic design outcomes when relying on AI tools. Arabella Reflections Upon reflection, we appreciate the thorough training we received during the Grad Academy. The experience allowed us to learn new skills, understand agile ways of working in theory and practice, and identify areas of improvement in our personal and professional development. The graduate academy gave us a holistic understanding of how the company operates and how different practices connect, a view that will be invaluable as we move on to client projects. Life after Graduation Beyond the Graduate Academy, we also completed a week of focused UCD training. The hands-on sessions covered areas I hadn’t explored in depth before, such as content design and ethical data handling on public sector projects. This specialist training shows the design team’s commitment to helping us develop as growing experts within our disciplines. Arabella Having now joined my first project, one stand-out benefit I gained was the ability to spend time with not only my fellow graduates, but also with colleagues ranging in experience and practice. It equipped me with the confidence to reach out and build relationships with people in Solirius, and now in my project team, which has made my experience at Solirius very enjoyable.                                                                                                                       Kayenat

This article explores the evolution of data storage, from the early days of punch cards to the rise of data warehouses, lakes, and the modern lakehouse. Ara traces how each stage shaped today’s data landscape and explains how the lakehouse unites flexibility, governance, and trust in a single architecture. The evolution of data storage The explosion of data has demanded continuous evolution of how the data is stored. Starting as early back as we can go, in the “prehistoric” times data was stored in manual records, punch cards and magnetic tapes. Then came the 1980’s, when Bill Inmon formally founded the data warehouse concept, giving structure to chaos. Bill wrote the script and then IBM built the stage. Data warehousing centralised data from different systems in a standard format, allowing business to connect insight from their data which were previously disconnected and siloed.  But data warehousing came with its own limitations. The data needed to behave like a  polished gentleman - it had to fit neatly in predefined schemas, making them expensive for handling unstructured and semi structured data like logs, images and JSON.  As organisations began to collect more and more data this limitation was exacerbated. Organisations demanded cheaper storage and more flexible storage solutions. In the early 2010s companies like Hadoop and Amazon popularised the data lake concept, which involved centralised repositories of data in its native format stored cheaply until it is needed. The rise of the data lakehouse Thus, we enter the next chapter of storage technologies. Organisations needed the flexibility of a data lake but the reliability and structure of a data warehouse. This is where the data lakehouse enters the scene. The data lakehouse pioneered by Databricks, combined the best of both worlds. It allows raw and structured data to live side by side, whilst ensuring governance, schema enforcement and transactional consistency. It is worth noting the data lakehouse is more of a data architecture than a stand alone microservice like Amazon S3. It utilises file format technologies like Delta Lake, Apache Iceberg and Hudi.  Let's run through a quick example by empowering a life science organisation with the data lakehouse architecture. The organisation has siloed genome data in a S3 data lake, clinical trial data in a SQL server and lab experiments in CSVs. Scientists struggle to join these data sets, and machine learning teams face long waits to prepare consistent inputs, leading to slower analytics, low trust in the data, and ultimately, delayed time to market. With the data lakehouse, the organisation now ingests the raw files as they are but converts them into a Delta file format. Instantly adding ACID (atomicity, consistency, isolation & durability) compliance to the data, adding reliability for scientists publishing results to the same folder. The delta format also maintains a transaction log, which allows teams to audit changed or even rollback data to previous versions.  The shift from ETL to ELT and the medallion architecture Another major shift that came with the cloud was in how data is moved and transformed — the shift from ETL to ELT. Traditionally, in ETL (Extract → Transform → Load), data was cleaned and reshaped before being loaded into a warehouse. This worked well when compute power was expensive and storage limited. In the modern cloud world, we first bring all the raw data into the lakehouse, then transform it inside scalable cloud compute engines. This not only simplifies the process but allows you to also preserve the raw data for future use. If an organisation has a governance layer like Microsoft Purview or Unity Catalog, you can discover all of your data assets easily in a centralised catalog.  Tools like Azure Data Factory, Databricks jobs and data build tools (DBT) have made it easier than ever to orchestrate these data pipelines. You can set up your orchestrated pipelines simply to follow the medallion architecture. You start off in your bronze layer  where your raw unfiltered data resides exactly as it is with perhaps the addition of audit columns. In your silver layer  you can do some data cleaning and apply filtering. Finally the gold layer  is your final polish data with all of the aggregations, purpose built for your use case. In our life science example all experiment data is collected as it is in the bronze layer.  Suppose the experiment produced invalid results due to incorrect equipment calibration. In the silver layer, business logic adds a flag - is_valid_experiment  = False. These records remain stored and traceable but are excluded from the gold layer, where only valid experiments are aggregated and used to train machine-learning models. This approach maintains full lineage and auditability so that nothing is lost and only trusted, high-quality data informs critical decisions. That’s the real power of the modern data lakehouse: uniting flexibility, governance, and trust in a single architecture built for today’s data-driven world. Contact information If you have any questions about our Data Engineering services, or you want to find out more about other services we provide at Solirius Reply, please get in touch (opens in a new tab) .

Quantum computing is seen as a game changer in technology - but it’s not just a scientific breakthrough. It has the potential to reshape power structures, amplify inequality, and further solidify monopolies in our global politics. In the UK, the National Quantum Strategy (NQS) (2023) offers a hopeful roadmap: investing in talent, boosting national security, and driving innovation. Behind this optimism lies urgent ethical and political questions. In this article, we explore three critical challenges that must be addressed before quantum technologies are unleashed at scale. POLITICAL:  The race to quantum-secure communication Who will we trust, and who will we share our secrets with? As quantum computers advance, so does the threat to our current encryption systems. Classical encryption methods like RSA rely on the difficulty of factoring large numbers - a problem that quantum computers can solve efficiently using Shor’s algorithm. Here’s the risk - RSA doesn’t tell you when it’s been cracked. If an attacker uses a quantum computer to break your encryption, you may never know - at least not until it’s too late. They could decrypt sensitive data, monitor communications, or impersonate others without detection. To defend against this, we look to Quantum Key Distribution (QKD). This technology leverages quantum mechanics to detect eavesdropping and secure communication channels. This is the foundation of Quantum-Secure Communication, and it's why nations are now racing to develop and deploy QKD networks. It’s the modern day race to the moon! There’s many factors to consider here: These networks don’t just secure communication, they control who can talk securely with whom. If another nation doesn’t have a quantum secure information system, we cannot share information with them this way. New alliances and exclusions will form - so when we develop this technology, who will we share it with? And who would share it with us? National Quantum Strategy - global agreements: Building on the two-way agreement with the US on quantum collaboration, the NQS aims to have bilateral arrangements with 5 further leading quantum nations by 2033. Thought: What does global trust look like in a world of quantum-secured elites? ETHICAL:  Monopolisation of drug discovery Are we creating faster cures or stronger monopolies? Quantum computers are expensive to build, maintain, and operate. This puts them within reach of only the most powerful companies, often those who already dominate sectors like pharmaceuticals. One of the most discussed applications of quantum computing is using the computational  power to design drugs and medicine. While this offers enormous potential to speed up discovery, it raises ethical concerns when placed in the hands of profit-driven monopolies. The pharmaceutical industry already faces major criticisms: Profit over access , life-saving drugs are often priced beyond reach. Lack of transparency  in clinical trials and development pipelines. Political lobbying  that shapes regulation in favour of corporate interests. Access inequality , especially in low-income countries. National Quantum Strategy - NHS services: Mission 3: By 2030, every NHS Trust will benefit from quantum sensing-enabled solutions, helping those with chronic illness live healthier, longer lives through early diagnosis and treatment. Thought:  Could quantum computing worsen healthcare inequality more than already? SOCIAL:  Increased global and national inequality Who will benefit and who will be left behind? Quantum technologies demand rare expertise and expensive infrastructure - both concentrated in elite institutions and wealthy nations. This risks deepening global and social divides: Geopolitical gaps:  Countries without quantum infrastructure may be locked out of future innovation ecosystems. Workforce inequality:  Quantum jobs require advanced, often exclusive education - creating a two-tier tech economy. Diversity risks: Physics and computing already lack representation. Without intervention, quantum may repeat and worsen these patterns. Thought: If we fail to address these imbalances now, could quantum computing widen the same divides it has the potential to help solve? National Quantum Strategy - education: The UK has pledged to fund over 1,000 PhD studentships in quantum-related disciplines between 2024 and 2034. Additionally, the Quantum Technology Hubs received £3 million from EPSRC in April 2025 to run a coordinated skills and training programme over four years. Final Thought: Technology Is Not Neutral Quantum computing will change the world - but how it changes depends on who controls it, who gets access to it, and who benefits. The future of quantum computing must be designed not only for what’s possible, but for what’s fair. National Quantum Strategy - outlook: “We will work internationally to share and increase knowledge, build secure supply chains and collaborate on the most pro-innovation and ethical global governance and regulation of quantum technologies.” The quantum revolution demands proactive, not reactive, governance and policies. It’s difficult to govern a technology that we barely understand, but the UKs National Quantum Strategy is a great start. Contact information If you have any questions about Quantum computing or our Data Engineering  services, or you want to find out more about other services we provide at Solirius Reply,   please get in touch (opens in a new tab) .

The evolution from simple prompts to agent instructions Prompt engineering has undergone a significant transformation in the rapidly evolving landscape of artificial intelligence. What began as simple text inputs to generate specific outputs has evolved into sophisticated instruction sets that guide autonomous AI agents through complex, multi-step processes with minimal human intervention. Traditional prompt engineering focused on crafting the perfect input to get a desired output in a single interaction. In contrast, agent prompting requires designing comprehensive instructions that guide an AI through extended, multi-step processes while maintaining context, handling errors, and achieving specific objectives. This shift represents a fundamental change in how we interact with AI systems, moving from transactional exchanges to collaborative partnerships. As we progress through 2025, agentic AI has emerged as one of the most transformative technologies. It enables systems to accomplish specific goals with limited supervision through machine learning models that mimic human decision-making processes in real-time environments. Industry analysts project that by 2028, approximately 15% of day-to-day work decisions will be made autonomously through agentic AI systems, representing a dramatic increase from essentially zero in 2024. Strategic Prompt Engineering Workflow for Autonomous Agents - showing the progression from problem definition to solution generation with feedback loops to anticipate failure modes. Key components of effective agent prompts 1. Clear objective definition The foundation of any effective agent prompt is a crystal-clear definition of the goal state and evaluation criteria. Without this clarity, AI agents can drift off course or produce results that technically meet requirements but miss the intended purpose. Example for software development: OBJECTIVE: Create a React component that displays user analytics data. SUCCESS CRITERIA: - Component renders without errors - Handles empty states gracefully - Formats numbers according to locale - Maintains responsive design across device sizes - Includes appropriate loading states  Example for business analysis: OBJECTIVE: Analyse Q1 sales data and identify actionable insights. SUCCESS CRITERIA: - Identify the top 3 performing products and the bottom three underperforming products - Calculate year-over-year growth rates by region - Determine key factors influencing sales performance - Provide specific, actionable recommendations for Q2 - Present findings in a format suitable for executive review  By explicitly defining success, you provide the agent with a clear target and enable it to self-evaluate its progress. This approach reduces the need for human intervention and increases the likelihood of achieving desired outcomes on the first attempt. 2. Contextual awareness mechanisms Effective agent prompts include mechanisms for the AI to maintain and update its understanding of the current state. This contextual awareness is crucial for long-running tasks where the agent needs to track progress, remember previous decisions, and adapt to changing conditions. Example for software engineering: CONTEXTUAL TRACKING: Before implementing each feature, summarise: 1. What you've accomplished so far 2. What remains to be done 3. Any potential issues you've identified 4. How current decisions might impact future steps 5. Any technical debt being created that will need addressing  Example for project management: CONTEXTUAL TRACKING: After each project milestone, document: 1. Current project status against timeline and budget 2. Resources utilised and remaining resource allocation 3. Risks identified and mitigation strategies 4. Stakeholder communications needed 5. Dependencies that may affect upcoming milestones  This approach creates a “working memory” for the agent, allowing it to maintain coherence across complex tasks and make decisions that account for past actions and future implications. In 2025, advanced agentic systems have demonstrated significant improvements in maintaining context across extended operations when explicitly prompted to track and summarise their progress. 3. Deliberate planning instructions One of the most potent techniques for autonomous workflows is directing the agent to create a plan before execution. This planning phase allows the AI to think through the entire process, identify potential challenges, and establish a logical sequence of operations. Example for software development: PLANNING PHASE: Before writing any code, outline your implementation strategy: 1. List the key functions needed and their purposes 2. Identify data structures and state management approach 3. Note potential edge cases and how they'll be handled 4. Establish error-handling strategies 5. Determine the testing approach for each component 6. Consider CI/CD integration requirements  Example for a marketing campaign: PLANNING PHASE: Before creating campaign assets, develop a comprehensive strategy: 1. Define target audience segments and their characteristics 2. Outline key messaging for each segment 3. Identify required content assets and their specifications 4. Establish success metrics and tracking mechanisms 5. Create a timeline with dependencies and critical paths 6. Determine budget allocation across channels  Research has shown that agents that engage in explicit planning before execution demonstrate up to 37% higher success rates on complex tasks than those that immediately begin implementation. This planning stage also provides a valuable opportunity for human review before significant resources are committed to execution. 4. Failure recovery protocols Even the most advanced AI systems encounter failures. What distinguishes effective agent prompts is the inclusion of specific instructions for handling errors and recovering from failures. This resilience is essential for autonomous workflows where human intervention should be minimised. Example for software engineering: ERROR HANDLING PROTOCOL: If you encounter an error: 1. Log the specific issue and context in which it occurred 2. Attempt to diagnose the root cause 3. Try an alternative approach based on the diagnosis 4. If the alternative fails, implement a graceful fallback 5. Request human assistance only if you remain stuck after two attempts 6. Document the error and solution for future reference  Example for financial analysis: ERROR HANDLING PROTOCOL: If you encounter data inconsistencies: 1. Document the specific inconsistency and affected data points 2. Check for data transformation errors or missing values 3. Apply statistical methods to identify outliers or anomalies 4. Attempt reconciliation using alternative data sources 5. Flag any assumptions made to address inconsistencies 6. Assess the impact on confidence intervals for your analysis  By building in explicit recovery mechanisms, you enable the agent to navigate around obstacles rather than halting at the first sign of trouble. This significantly increases the completion rate of autonomous workflows and reduces the need for human intervention. 5. Self-verification steps Incorporating validation checkpoints throughout the process ensures that the agent regularly verifies its work against the defined objectives. This self-verification is crucial for maintaining quality and preventing errors from cascading through the workflow. Example for software development: VERIFICATION CHECKPOINTS: After implementing each function: 1. Write at least one test case to verify it works as expected 2. Check edge cases (empty inputs, maximum values, etc.) 3. Verify that the implementation meets all requirements 4. Confirm that it integrates properly with existing components 5. Validate performance against established benchmarks  Example for business strategy: VERIFICATION CHECKPOINTS: For each strategic recommendation: 1. Validate alignment with company objectives and values 2. Verify that it's supported by data and analysis 3. Assess resource requirements and feasibility 4. Consider potential unintended consequences 5. Evaluate competitive response scenarios  These verification steps create a feedback loop within the agent’s workflow, allowing it to catch and correct issues before they compound. Studies of agentic systems in 2025 have shown that incorporating explicit self-verification reduces error rates by up to 42% compared to systems without such mechanisms. Implementation example: database query optimisation agent Here’s how you might structure a prompt for an agent that helps optimise database queries in an enterprise environment: AGENT OBJECTIVE: Analyse and optimise the SQL query provided by the user for improved performance in our production environment. CONTEXT: - We use Postgresql 16.2 in a high-transaction environment - Our database contains approximately 50 million records in the main tables - Query performance is critical for user experience and system stability WORKFLOW: 1. Parse the input query and identify its purpose 2. Check for common performance issues (missing indexes, inefficient joins, etc.) 3. Analyse the execution plan to identify bottlenecks 4. Generate an optimised version of the query 5. Explain your changes and their expected impact 6. Provide recommendations for schema improvements if applicable CONSTRAINTS: - Maintain exact semantic equivalence - the optimised query must return identical results - Prioritise readability alongside performance - Consider both immediate execution time and scalability with data growth - Avoid solutions that would require significant schema changes VERIFICATION: Before finalising your recommendation, compare the original and optimised queries for: 1. Logical equivalence 2. Edge cases (empty tables, NULL values) 3. Potential unintended consequences (like lock contention) 4. Impact on other queries that might use the same tables UNCERTAINTY HANDLING: If multiple optimisation approaches exist with different tradeoffs, present the top 2-3 options with their advantages and disadvantages. DOCUMENTATION: For each optimisation, document: 1. The specific issue identified 2. The change made to address it 3. The expected performance improvement 4. Any monitoring recommendations to verify the improvement  This prompt structure guides the agent through a complete workflow while establishing clear boundaries, verification steps, and protocols for handling uncertainty. The result is an autonomous process that delivers high-quality results with minimal human oversight, directly addressing a common challenge in enterprise software environments. Advanced agent prompting techniques Chain-of-thought orchestration Beyond basic chain-of-thought prompting, effective agent prompts orchestrate multiple reasoning chains with dependencies. This approach prevents premature commitment to solutions before fully understanding available resources and constraints. Example for product development: TASK DECOMPOSITION: 1. First, identify all stakeholder requirements for this product feature 2. For each requirement, evaluate: a. Priority level (must-have vs. nice-to-have) b. Technical feasibility within the current architecture c. Potential conflicts with other requirements 3. Only after completing steps 1-2, formulate your implementation approach 4. For each implementation decision, document: a. Which requirements does it address b. Any requirements it partially satisfies c. Trade-offs made and their justification  This staged approach ensures that the agent builds a comprehensive understanding before committing to a solution path, resulting in more robust and well-founded outcomes that align with business objectives. Memory management instructions Long-running agents need explicit memory management protocols to maintain coherence across extended operations: Example for enterprise system integration: MEMORY PROTOCOL: - Maintain a running summary of key information in JSON format - After each significant step, update your summary with: { "key_facts": [], "decisions_made": [], "open_questions": [], "system_dependencies": [], "integration_points": [] } - Before making conclusions, review your complete memory store - Flag any inconsistencies or gaps in your knowledge base  This structured approach to memory management helps agents maintain consistency across complex tasks. It reduces the likelihood of contradictions or forgotten information, which is particularly critical in enterprise software development with multiple systems and stakeholders. Environmental awareness directives Effective agents need contextual awareness of their operational environment to adapt their approach based on available resources and constraints: Example for cloud infrastructure management: ENVIRONMENT ASSESSMENT: Before beginning, assess: 1. Available computational resources (CPU, memory, storage) 2. Current system load and performance metrics 3. Service level agreements and compliance requirements 4. Maintenance windows and change management policies 5. Cost implications of resource allocation decisions 6. Potential impact on dependent systems Adapt your approach based on these constraints and document any assumptions made.  This environmental awareness enables agents to tailor their strategies to the specific context in which they operate, leading to more realistic and achievable workflows that respect business constraints. Case study: Financial analysis agent A financial services firm implemented an agent system for quarterly earnings analysis with this prompt structure: You are Financegpt, a specialised financial analyst assistant. OBJECTIVE: Analyse the attached quarterly earnings report and prepare a summary highlighting: - Key performance indicators vs. expectations - Significant changes from previous quarters - Forward-looking statements and their implications - Potential impacts on investment strategy BUSINESS CONTEXT: - This analysis will inform investment decisions for a $500M portfolio - Our investment strategy focuses on long-term growth in the technology sector - We are particularly interested in AI, cloud infrastructure, and cybersecurity trends - Regulatory compliance with SEC guidelines is mandatory EXECUTION CONSTRAINTS: - Complete analysis within 20 minutes - Prioritise accuracy over comprehensiveness - Consider regulatory disclosure requirements in your analysis - Flag any potential material information that requires further investigation PROCESS: 1. Scan the document to identify the structure and key sections 2. Extract and verify numerical data first 3. Compare with previous quarters and analyst expectations 4. Identify management commentary on results and future outlook 5. Analyse sector-specific trends and competitive positioning 6. Before finalising, verify all numerical claims against source data REFLECTION QUESTIONS: - What might I be missing from this analysis? - What alternative interpretations exist for these results? - What information is conspicuously absent from this report? - How might this information affect our current investment thesis? ERROR HANDLING: If you encounter inconsistent numerical data, flag it explicitly and attempt to resolve it through contextual information before proceeding. OUTPUT FORMAT: Provide your analysis in a structured format with: 1. Executive Summary (250 words max) 2. Key Performance Metrics (with YoY and Qoq comparisons) 3. Strategic Insights and Implications 4. Risk Factors and Concerns 5. Recommended Actions  This structured prompt resulted in 92% accuracy (compared to human analysts) versus 76% with simpler prompting approaches. Including reflection questions and explicit error-handling protocols was particularly effective in improving the quality of analysis. The firm estimated that this system saved approximately 120 analyst hours per quarter while improving the consistency and comprehensiveness of their financial reviews. Implementation challenges 1. Prompt size limitations Complex workflows require extensive instructions that may exceed model context windows. To address this challenge, implement hierarchical prompting where high-level instructions activate specific sub-prompts as needed. This modular approach allows for comprehensive guidance while managing context limitations. Enterprise solution:   Several organisations have implemented prompt management systems that dynamically load relevant instruction modules based on the current task phase, extending the functional context window through strategic prompt segmentation. 2. Instruction conflicts Detailed prompts may contain contradictory directives. To mitigate this risk, explicitly prioritise directives and include conflict resolution protocols. For example: PRIORITY ORDER: 1. Security and data integrity requirements 2. Functional correctness 3. Performance optimisation 4. Code readability and maintainability 5. Development velocity When conflicts arise between directives, always prioritise according to this hierarchy and document the trade-off decision.  This explicit prioritisation framework has proven valuable in enterprise software development, where competing objectives often create ambiguity about the optimal approach. 3. Prompt maintenance As agent capabilities and requirements evolve, prompts become organisational assets requiring version control and governance. Implement prompt management systems with testing frameworks to evaluate performance across examples and ensure consistent quality over time. Enterprise approach:   Leading organisations have established “prompt engineering centres of excellence” that maintain libraries of tested, version-controlled prompts for standard business processes. These teams continuously refine prompts based on performance metrics and evolving business requirements, treating prompt engineering as a critical organisational capability. Future directions: Self-improving agent prompts Research is advancing toward prompts that evolve through experience. These adaptive systems analyse their performance history to identify patterns of success and failure, then modify their instructions to improve outcomes. While still emerging, this approach represents the next frontier in autonomous workflows, where agents follow instructions and help refine them based on operational experience. Several enterprise software vendors now offer “prompt optimisation platforms” that automatically analyse agent performance across thousands of interactions to identify instruction patterns that correlate with successful outcomes. These systems can suggest prompt modifications that improve performance for specific use cases, creating a continuous improvement cycle. Best practices for strategic prompt engineering in enterprise environments Iterative refinement : Test prompts with diverse inputs and refine based on where the agent struggles. The most effective prompts are rarely created in a single attempt but evolve through systematic testing and improvement. Establish a formal testing protocol with representative scenarios from your business domain. Domain-specific knowledge : Include relevant technical concepts and terminology for your use case. Agents perform significantly better when provided with domain-specific frameworks and vocabulary. Consider creating a domain glossary for complex business areas that can be included in prompts. Scalable complexity : Design prompts for simple and complex scenarios. Effective agent prompts should degrade gracefully rather than fail when faced with unexpected challenges. Test with both typical and edge cases to ensure robustness. Meta-cognitive guidance : Instruct the agent on  how  to think, not just what to do. Providing reasoning frameworks and decision criteria leads to more consistent and high-quality outcomes than simply listing tasks. Include industry-standard methodologies where applicable. Feedback ntegration : Include mechanisms for the agent to incorporate feedback from previous attempts. This creates a learning loop that improves performance over time without prompt modifications. Document successful patterns and standard failure modes to inform future prompt development. Cross-functional collaboration : Involve technical and business stakeholders in prompt development. The most effective prompts combine deep domain expertise with understanding AI capabilities and limitations. Create multidisciplinary teams for prompt engineering in critical business processes. As we continue through 2025, strategic prompt engineering for autonomous workflows has emerged as a critical skill for organisations seeking to leverage the full potential of agentic AI. By designing comprehensive instruction sets that guide AI through complex processes with appropriate guardrails and verification mechanisms, we can achieve unprecedented levels of automation while maintaining quality and reliability. The most successful implementations treat prompt engineering not as a one-time task but as an ongoing process of refinement and adaptation. As AI capabilities advance, our ability to effectively direct these systems through well-crafted prompts will remain a key differentiator in realising their full potential for business value creation. Contact information If you have any questions about our AI initiatives, software engineering service, or you want to find out more about other services we provide at Solirius Reply, please get in touch (opens in a new tab) .

In today's digital landscape, where security breaches can cost organisations millions and erode customer trust, building high-performing DevSecOps teams isn't just an operational choice - it's a strategic imperative. As a Lead DevSecOps Engineer who has orchestrated digital transformations across healthcare technology and financial services sectors, I've seen firsthand how the right approach can deliver exceptional results: 99.9% system uptime, 40% faster deployments, and 95% improvement in security compliance. This comprehensive guide shares practical insights from real-world implementations. The Evolution of DevSecOps The journey from traditional development practices to mature DevSecOps represents a fundamental shift in how organisations approach software delivery and security. This evolution can be visualised as follows: Flowchart showing three stages of software development evolution. First stage, red background: Traditional Approach with steps - Development, Security Review, Operations Deploy. Second stage, yellow background: Transition Phase with steps - Automated Testing, Security Automation, Continuous Deployment. Third stage, green background: Mature DevSecOps with interconnected steps - Continuous Integration, Automated Security, Continuous Delivery, Monitoring and Feedback. Arrows indicate progression and interconnections, emphasizing automation, security integration, and continuous feedback. This transformation journey at a primary healthcare technology provider yielded remarkable results: Reduced security incident response time from 3 hours to 15 minutes Decreased deployment failures by 75% Improved team velocity by 40% The Three Pillars of Excellence 1. Shared Responsibility: Beyond Traditional Boundaries Traditional approaches often treat security as a checkpoint. We revolutionised this by implementing: Automated Security Gates # Example Pre-commit Hook Configuration repos: - repo: rev: v4.4.0 hooks: - id: detect-private-key - id: detect-aws-credentials  This configuration, implemented across our development teams, caught 95% of security issues before they reached production. 2. Continuous Learning: Building Expertise Our learning framework focused on three key areas: Flowchart of a DevSecOps pipeline with four stages: Development, Build, Deploy, and Monitor. Development stage includes Code Commit, Pre-commit Hooks, Static Application Security Testing, and Unit Tests. Build stage includes Container Scan, Dependency Check, and Image Sign. Deploy stage includes Dynamic Application Security Testing, Compliance Check, and Deploy. Monitor stage includes Runtime Security, Threat Detection, and Automated Response. Arrows show sequential flow and emphasize integrated security throughout the software lifecycle. Real-world implementation included: Weekly security champions program Monthly capture-the-flag security exercises Quarterly security architecture reviews 3. Automation-First Mindset: From Manual to Automatic We implemented comprehensive security automation: # Pre-commit Security Hook Configuration repos: - repo: rev: v4.4.0 hooks: - id: detect-private-key - id: detect-aws-credentials - id: check-yaml - id: check-json - repo: rev: v8.16.1 hooks: - id: gitleaks - repo: rev: v1.77.1 hooks: - id: terraform_fmt - id: terraform_docs - id: terraform_tflint - id: terraform_tfsec # Terraform Security Configuration resource "aws_security_group" "app_sg" { name = "application-security-group" description = "Security group for application servers" vpc_id = var.vpc_id # Inbound rules ingress { from_port = 443 to_port = 443 protocol = "tcp" cidr_blocks = ["10.0.0.0/8"] description = "HTTPS from internal network" } # Outbound rules egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] description = "Allow all outbound traffic" } tags = { Environment = var.environment ManagedBy = "Terraform" Security = "High" } } # Container Security Policy apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted spec: privileged: false seLinux: rule: RunAsAny runAsUser: rule: MustRunAsNonRoot fsGroup: rule: RunAsAny volumes: - 'configMap' - 'emptyDir' - 'persistentVolumeClaim' - 'secret'  Flowchart of a DevSecOps CI/CD pipeline divided into three phases: Pre-Commit, CI, and CD. Pre-Commit includes Code Changes, Pre-commit Hooks, Git Push, and Fix Issues. CI includes SAST, Dependencies, Container Scan, and Build. CD includes DAST, Compliance, and Deploy. Arrows show the flow from code changes to deployment, with loops indicating failed checks return to Fix Issues. This policy, part of our larger automation strategy, ensured consistent security controls across our Kubernetes clusters. Measuring Success: The Metrics That Matter Flowchart showing Security, Technical, and Business Metrics. Security Metrics: 95% compliance rate, 70% earlier detection, 85% automated response. Technical Metrics: 99.9% uptime, 40% faster deployments, 60% reduced incidents. Business Metrics: 25% cost reduction, 30% faster time to market, 95% customer satisfaction. Our metrics framework tracked three key areas: Business Impact 25% reduction in operational costs 30% faster time to market 95% customer satisfaction rate Technical Excellence 99.9% system uptime 40% faster deployment cycles 60% reduction in incidents Security Posture 95% compliance rate 70% earlier threat detection 85% automated security responses Implementation Strategy: A Practical Guide The successful implementation of these principles requires a structured approach: Assessment Phase (Week 1-2) Security posture evaluation Team capability assessment Tool stack analysis Foundation Building (Month 1) Infrastructure as Code implementation Automated security scanning integration Team training initiation Culture Development (Month 2-3) Security champions program launch Cross-functional team formation Metrics dashboard implementation Optimisation (Month 4+) Continuous feedback loops Process refinement Advanced automation implementation Real-World Example: Healthcare Technology Transformation When implementing this framework at a healthcare technology provider, we faced specific challenges: Initial State: Manual security reviews taking 5+ days Compliance reporting requiring 20+ hours monthly Limited visibility into security posture Implementation: Automated compliance checks using AWS GuardDuty Implemented real-time security monitoring Established automated incident response Results: Security review time reduced to 4 hours Compliance reporting automated to 1 hour monthly Real-time security visibility achieved # AWS Lambda function for automated incident response import boto3 import json def lambda_handler(event, context): """Automated response to security incidents""" try: finding_type = event['detail']['type'] severity = event['detail']['severity'] if severity >= 7: # High severity # Isolate affected resources isolate_resources(event['detail']['resource']) # Create incident ticket create_incident_ticket(event['detail']) # Alert security team alert_security_team(event['detail']) return { 'statusCode': 200, 'body': json.dumps('Incident handled successfully') } except Exception as e: print(f"Error handling incident: {str(e)}") raise def isolate_resources(resource_details): """Isolate affected resources""" ec2 = boto3.client('ec2') # Create isolation security group response = ec2.create_security_group( GroupName=f'QUARANTINE-{resource_details["instanceId"]}', Description='Quarantine security group' ) # Block all inbound/outbound traffic ec2.authorize_security_group_ingress( GroupId=response['GroupId'], IpPermissions=[{ 'IpProtocol': '-1', 'FromPort': -1, 'ToPort': -1, 'IpRanges': [{'CidrIp': '0.0.0.0/0'}] }] )  Looking Ahead: The Future of DevSecOps The evolution of DevSecOps continues with emerging trends: AI-driven security automation Zero Trust architecture implementation Quantum-safe security preparation Diagram titled Team Evolution showing a shift from Traditional Teams to DevSecOps Teams. Traditional Teams have siloed responsibilities, separate operations, manual processes, and treat security as an afterthought. DevSecOps Teams focus on shared ownership, automation, continuous learning, and collaboration, with elements like CI/CD pipelines, security gates, compliance checks, and cross-functional skills Your Next Steps Consider these questions for your organisation: How mature is your current security automation? What manual processes could benefit from automation? How do you measure DevSecOps success? Share your thoughts and experiences in the comments. Let's learn from each other as we build more resilient, secure, and efficient engineering teams.

The lost art of data engineering 2: The origin of a data engineer To understand what a data engineer does,  it is important to know that a data engineer is fundamentally a specialist software engineer. They are primarily responsible for the data systems, but they also venture out into other non-data, software engineering principles. For example, data engineers follow similar continuous integration and continuous development (CI/CD) processes when creating data pipelines as software engineers do when creating API endpoints. Data systems come in two flavours: Online Analytical Processing (OLAP) and Online Transaction Processing (OLTP). OLTP systems manage high volumes of real time data. Think of a website like IKEA. Customers place an order, payments are taken and items are fulfilled. All of this happens  quickly and smoothly for hundreds of thousands of customers. Each stage of this process creates or moves data: an order has an entry in an orders table, with details like value and items. The payments system  validates the customer has the funds and then puts the required amount on hold, before batching and settling thousands of customer orders at the end of the day. Finally, an entry in the fulfilment table is entered to assign the order for delivery, whilst the inventory table has quantity reduced by the order quantity. OLTP needs single digit micro second process time. All of these processes usually need to be complete by the time the customer has finished blinking.  OLAP systems on the other hand handle large volumes of data. All the data created from the OLTP systems need to be analysed. The data needs to be prepared for reporting in a Business Intelligence (BI) dashboard, or to be used in a Machine Learning (ML) Model. Back to our IKEA example, executives need to see what the sales trend is after they introduce a new marketing strategy. All the information they need to answer this question with quantitative explanation should be found in their BI reports. The executives may then want to implement a ML recommender model. This model needs to be trained on customers' existing purchasing habits, then be fed their behaviour in real time. The model will recommend items to customers, which should increase sales. The OLAP side of data engineering is where this series will spend most of its attention. With the boom of the AI revolution since Nov 2023, data engineers are becoming the backbone for organisations that want to now power their company on AI technologies. Whether you want to build a RAG (random augmented generation) model or use an MCP (Model Context Protocol) framework, your data needs to be prepped and served. That is what data engineers do. Diagram comparing OLTP and OLAP. OLTP connects to Banking, E-Commerce, Reservation Systems. OLAP links to AI/ML, BI. Data engineers will primarily focus on extracting  data from the source system, transforming  it and then loading  it to the target system. This process is known as ETL . The counterpart to ETL is ELT, in which case you load it into your target system and then do your transformation and cleaning. No matter the use case, data will need to be prepared before use. Think of it like cooking, with data being the ingredients. The meal you are trying to cook will determine how you prepare your ingredients. Data engineers will often be the invisible person in the middle, enabling the features for customers in OLTP or supporting executives with their decision making. Contact information If you have any questions about our Data Engineering services, or you want to find out more about other services we provide at Solirius Reply, please get in touch (opens in a new tab) .

How we used T-shirt sizing to scope a complex multi-service Justice platform by Caity Kelly How do you scope and estimate 170+ features across seven work packages, involving multiple delivery teams, disciplines, and stakeholder groups? In our work with HMCTS on the Housing Disputes programme (more commonly known as Renters Reform), we ran an extensive T-shirt sizing exercise that became a shared planning language across service, product, architecture, design, and technical delivery. Here’s how we did it, and what we learned. What is the ‘Renters Reform’ Programme? His Majesty’s Courts and Tribunals Service (HMCTS) is responsible for administering the criminal, civil and family courts and tribunals in England and Wales. It plays a central role in delivering justice in a fair, efficient, and modern way. One of HMCTS’s flagship programmes is the Housing Disputes Policy Infrastructure Project (HDPIP) - more commonly known as Renters Reform. This major policy and digital transformation initiative aims to streamline how real property disputes (such as those between landlords and tenants) are resolved in England and Wales, and aligns it with upcoming legislation currently progressing through Parliament. The service will support users through a fully digital process (which is currently largely paper based) from initial case creation and submission through to tribunal decision and enforcement, with an emphasis on fairness, transparency, and accessibility for all users - both citizens and courts staff alike. The aim is to launch the service within 18 months of Royal Assent (which is when the Bill has been passed by Parliament), aligning with the new legal framework for property disputes once enacted. Background Our team at Solirius Reply, alongside a blended team of other suppliers, is helping HMCTS deliver three digital interfaces which will exist as one joined up service on GOV.UK : Citizen Interface (C-UI) : For renters, landlords, managing agents, and other citizens to initiate or respond to disputes. Expert Interface (Ex-UI) : For court staff, tribunal clerks, and judges to manage and resolve cases. Enforcement Interface : For bailiffs and enforcement agents to view and act on court-ordered outcomes. Each interface supports different roles, access levels, workflows, and data integrations. Together, they form a single digital ecosystem designed to support our service vision of a fairer, faster, and more accessible housing disputes resolution system.  Given the cross-cutting nature of many features (e.g. impacting more than one interface), as well as the involvement of multiple delivery partners (technical, design, architecture, and policy), we needed a collaborative and time-efficient way to estimate effort across the board. With such breadth and complexity, it became clear that scoping the effort required to deliver the interfaces required us to turn to a commonly used Agile framework - T-Shirt sizing - both to plan effectively and to set delivery expectations. What we did As the service, product, architecture, and design teams moved through an analysis of the ‘as system’ they identified seven major work packages (WPs) comprising over 170 features that would form the foundation of an MVP release and beyond. These included everything from case intake, document submission, and identity verification to evidence review, tribunal hearing preparation, enforcement workflows and much more. Each work package varied in complexity, technical dependencies, and level of design maturity. With multiple suppliers and HMCTS teams involved (technical, UCD, architecture, policy, service, product), we needed a shared and efficient way to: Understand the relative complexity of each feature Identify dependencies Support delivery planning and MVP scoping The T-shirt sizing exercise proved to be an excellent tool for developing a shared language and understanding of the scope of work across teams. Tools and methods Why T-shirt sizing? T-shirt sizing is an Agile estimation method that uses intuitive size categories (e.g., Small, Medium, Large) instead of fixed hours or story points. We used the following standard: Size Meaning Sprint equivalence S (Small) Simple/straight forward feature Half a sprint (up to 5 days) M (Medium) Self-contained but non-trivial 1 sprint (10 days) L (Large) Moderately complex, possibly cross-functional 1–2 sprints XL (Extra Large) High-complexity or unknowns 2–3 sprints XXL (Extra Extra Large) Too big; must be broken down 3+ sprints By standardising these definitions across teams, we could have more productive conversations — even when working remotely or across disciplines. We also chose T-shirt sizing because it helps avoid the law of diminishing returns . While it might seem logical that the more time we spend estimating, the more accurate we’ll be, this isn’t the case. In practice, spending too long on estimation often yields only marginal gains in accuracy, and can become a wasteful exercise. By keeping things light and collaborative, we were able to agree quickly on relative effort, without overthinking it. The goal wasn’t to get the “perfect” number, but to reach a shared, good-enough understanding that the team could act on. Estimating as a group also helped reduce the illusion of certainty and reminded us that estimates are just estimates and are likely to change when more information becomes available. The law of diminishing returns. Graph of accuracy versus effort showing a curved line peaking at medium effort, illustrating diminishing returns. Running the workshops Due to the scale of the service, we ran a series of online workshops via Microsoft Teams, each focused on a single work package. Our approach: Timeboxing - each workshop was time-boxed to 45 minutes Discussion time - each feature discussion was capped at 10 minutes, to keep us moving Solirius Delivery Manager facilitation  gathering input from product and service teams, architecture, user centred design, HMCTS subject matter experts (SMEs), and our technical leads Use of Figma - this was used to gain shared understanding of the features, reviewing draft service and screen designs live on the calls Use of Excel on Sharepoint - this was used to log the estimated t-shirt sizes and record blockers and dependencies (and that spreadsheet was later transformed into our draft delivery gantt chart) Use of Jira - this was used to connect estimates to our epics in the technical delivery backlog Wherever conversations ran long or diverged, we captured a note on the t-shirt sizing spreadsheet and moved on - enabling velocity without sacrificing key stakeholder input. What we learnt Cross-discipline collaboration One of the most valuable aspects of this process was the diversity of perspectives in the room and the cross-discipline dialogue it enabled. Attendees included: HMCTS product owners clarifying feature intent and priority Technical architects identifying systems integration and security considerations Service and content designers flagging potential usability or accessibility implications Delivery leads from multiple partner teams managing dependencies and timelines HMCTS business analysts and subject matter experts, policy advisors Solirius developers, testers and architects This cross-functional collaboration helped surface hidden complexity. For example: Technical features that seemed simple from the outside as they could reuse existing code from other GOV.UK services (e.g., email notifications) ended up being sized as “large” when accounting for the significant new content, design, and accessibility work, and considering multiple delivery channels (SMS, email, in-app), templates, and translation needs. Integration with legacy systems or GOV.UK services added layers of complexity. Features affecting two or more interfaces required discussion around ownership and sequencing. Some “XXL” features highlighted areas where requirements were still too vague — prompting further discovery before delivery could be planned. Our results This exercise delivered far more than just a set of estimates. It helped anchor planning, align stakeholders, and build a shared understanding of complexity across the Renters Reform programme. ✅ S hared understanding: Everyone left the workshops with a clearer view of what needed to be built, why, and how much effort it might take. This helped reduce assumptions and build a shared understanding across disciplines. ✅ Planning confidence: We could group features by estimated effort, identify critical paths, and flag areas requiring further discovery. This gave us greater certainty around sequencing of work. This resulted in: 173 features sized across 7 work packages Early identification of blockers, dependencies, and discovery gaps Shared delivery language adopted across technical, UCD, and policy teams ✅ Clearer MVP definition: “XL” and “XXL” features often sparked discussion about scope - helping us prioritise must-haves vs. nice-to-haves, and making it easier to define a realistic MVP. This resulted in the development of alignment across teams on MVP scope, and supported realistic roadmap conversations with programme leadership. ✅ Delivery velocity baseline: By estimating using sprint equivalents, we could model different delivery scenarios e.g. what two technical pods could deliver in six sprints vs what four could deliver, which enabled more informed forecasting. This enabled delivery teams to map estimates against real capacity and helped shape sequencing for the Citizen, Expert, and Enforcement interfaces. ✅ Improved stakeholder engagement: The structured, time-boxed format made it easier for stakeholders to participate meaningfully without being overwhelmed. It also ensured we covered all 173 features efficiently. We captured decisions and rationale, alongside red flags raised by stakeholders for transparency The estimation model is now being reused across the programme as a best-practice approach Outputs now serve as a baseline for backlog refinement and prioritisation We captured decisions and rationale, alongside red flags raised by stakeholders for transparency The estimation model is now being reused across the programme as a best-practice approach Outputs now serve as a baseline for backlog refinement and prioritisation ✅ Shared ownership of estimates: One of the most valuable outcomes was the sense of shared ownership that emerged through the process. Rather than handing down estimates from a single team or role, we sized features together as a cross-functional group. Everyone’s perspective from delivery, design, architecture, and product was heard and considered. This helped build trust and alignment, and ensured that the estimates reflected the collective understanding of the team. Because the group had worked through the complexity together, the final estimates weren’t just accepted, they were owned  by the entire team. That ownership has helped sustain momentum and buy-in during ongoing planning and prioritisation. Navigating team challenges Of course, there were challenges: Time constraints  meant we couldn’t deep-dive into every feature. We mitigated this by capturing flags in the sizing document for follow-up. Feature overlap  across interfaces occasionally led to confusion; we tackled this by defining which team “owned” the feature for estimation purposes. Remote working  can limit engagement, but the use of collaboration tools, strong facilitation, and clear pre-reads helped keep everyone aligned and involved. Outcomes and next steps As a result of the exercise, we now have: A fully sized feature set across all seven work packages Clearer MVP priorities and sequencing Early identification of   technical risks and design gaps A foundation for delivery planning across interfaces and suppliers This work has already influenced sprint planning, architecture decisions, and roadmap alignment. Reflections In multi-interface services, early alignment of scope and expectations is crucial. Our experience showed that T-shirt sizing, a lightweight yet effective estimation method, can achieve this without heavy documentation or lengthy planning. This approach helped us understand scope, uncover hidden complexities, and plan collaboratively, avoiding over-analysis and the law of diminishing returns by focusing just enough effort for a shared, useful estimate. Ultimately, it fostered trust, clarity, and shared ownership across teams, which are vital for successful delivery. Our key factors for success included: A clear process Shared definitions Strong facilitation Shared ownership Crucially, collaboration across roles While seemingly simple, T-shirt sizing, when executed correctly, cultivates a deeper shared understanding - an essential element for programs of this scale. About the author Caity Kelly is a Senior Delivery Consultant at Solirius Reply, currently supporting HMCTS on the Renters Reform programme. She works at the intersection of agile delivery, digital transformation, and service design in Government. If you have any questions about our Delivery services or you want to find out more about other services we provide at Solirius Reply, please get in touch (opens in a new tab) .

The lost art of data engineering 1: a data engineer's chronicles by Ara Islam This series is aimed to help you take a step back and ground yourself on the core principles that every data team must understand. We will focus on the data engineering process, which is the art of preparing the most valuable ingredient your company has at its disposal: your data. In today's fast-paced world of data, companies are racing to leverage the latest trends and innovations to gain a competitive edge. With AI most recently taking centre stage as the key buzzword and topic of every C-suite board meeting. It's no wonder if you are new to the data space, you might struggle to see past the spider webs of fancy terms and exotic ideas that seem to appear almost on a daily basis. For any company to use the latest and greatest instruments of competitive edge like AI chat bots or Business Intelligence (BI) Reports, is to have a sophisticated backend structure. One that allows your data to bend to your needs while staying organised, accurate and governed.  But before we can get into some of the topics of data engineering, it's important to first define what a data engineer is. A Data Engineer is a person who designs , builds , and maintains data systems. This definition can overlap with responsibilities of the other roles within a data team like Data Architects who also work on part of the design. A Data Architect may join a project before a data engineer and master the process and infrastructure. However, a Data Engineer's input is essential to the designing of how data transforms and moves across systems.  A Business Analyst may be asked to build a report to aid in commercial decision making. But, as the demand for reports increases and they become more critical, an analyst alone isn't enough. They would have to sacrifice on accuracy or time to deliver. Both of which can affect a business trust in data and the effectiveness of decisions. That is why a Data Engineer is essential in data driven transformations. They enable Data Analysts, Data Scientists and ML Engineers to focus on building reports and models quickly  with great certainty. Throughout this series, we will touch on core principles of Data Engineering. Whether you are a Data Engineer yourself or member of a data team, the aim is to  gain a deeper appreciation for the craft, and understand why it's so important. Contact information If you have any questions about our Data Engineering services, or you want to find out more about other services we provide at Solirius Reply, please get in touch (opens in a new tab) .

AI in action 4: Supporting service teams through the Service Standard technology decisions by Matt Hobbs In this final article of our AI in action series, we turn our attention to the technological foundations that underpin modern government services and consider how these foundations must evolve to meet emerging opportunities and challenges. Throughout this series, we have explored each of the 14 points of the government Service Standard to examine how artificial intelligence (AI) can support service teams and shape the future of public services.  If you’re joining partway through, you may want to read the introduction , which outlines how AI can support government service delivery and sets the context for this discussion. We then explored Service Standard points 1 to 5 , focusing on user needs, accessibility, and joined-up experiences, followed by points 6 to 10 , which examined how AI can support multidisciplinary teams, agile working, continuous improvement, and secure delivery. Now, we’ll explore points 11 to 14 of the Service Standard - areas that are less about interfaces and workflows, and more about the underlying systems, infrastructure, and culture that enable services to be sustainable, open, and resilient. Standards 11–14 include choosing the right tools and technology, making new source code open, using open standards, and operating a reliable service may not always be visible to the public. However, these principles are what ensure that digital services are trustworthy, cost-effective, and fit for the long term. AI can now assist with everything from technology selection and licensing, to automated testing and deployment, to maintaining live services in real-time. And as AI tooling becomes more sophisticated, it’s increasingly capable of helping teams uphold these standards not just at launch, but throughout the service lifecycle. Let’s explore how AI is supporting these back-end foundations, and where future innovation might unlock even more potential for collaboration, openness, and reliability across government. Point 11. Choose the right tools and technology Service Standard summary : Point 11 of the GOV.UK Service Standard advises teams to choose tools and technologies that support building high-quality, cost-effective services while staying adaptable for the future. It emphasises using automation, making smart build-or-buy decisions, leveraging common platforms, avoiding vendor lock-in through open standards, and managing legacy systems effectively. Existing AI tooling : AI-Powered Code Analysis  Tools: Tools like GitHub Copilot , SonarQube , or DeepCode assist  in reviewing code quality, suggesting improvements, and flagging technical debt early, helping teams choose better implementation paths. Automated Cloud Cost Optimisers : Services like AWS Cost Explorer  with AI-powered recommendations help optimise infrastructure choices, right-size services, and avoid over provisioning. Chatbots  for Vendor Research : AI chat interfaces help teams quickly compare tools, read documentation, and analyse trade-offs between technologies or vendors. AI-Driven Testing and Monitoring: Tools like Testim  or Mabl automate  and enhance test coverage  using AI, which ensures that the chosen tech stack is reliable and scalable. Natural Language to Query/Data Tools: Tools like OpenAI’s Codex  or Microsoft Copilot  allow non-technical users to interrogate systems or suggest tools via plain language, democratising decision-making on tools. Future AI innovations: AI Architects / Decision Advisors: Smart assistants that could suggest entire architecture stacks  based on your business context, team skill level, and legacy dependencies. Predictive Tech Debt Modelling : Tools that could forecast the long-term implications (cost, maintainability) of tech choices using historical data and project-specific inputs. Autonomous Procurement Bots: AI systems that could handle early-stage vendor outreach , price negotiation, and integration feasibility analysis to streamline procurement. Context-Aware Build-vs-Buy Recommenders: AI that could analyse organisational data, time constraints, and cost to recommend the best mix of bespoke development  vs. off-the-shelf  tools. Self-Adaptive Infrastructure Planning: AI systems that could not only recommend, but automatically adapt and refactor infrastructure  as service needs evolve or usage spikes . Point 12. Make new source code open Service Standard summary : "Make new source code open", advises that all new government service source code should be openly accessible and reusable under appropriate licences to promote transparency, reduce duplication, and lower costs. Teams are encouraged to develop code publicly from the outset, ensuring sensitive information is excluded, and retain intellectual property rights to facilitate reuse. Exceptions will apply for code tied to unannounced sensitive policies. Existing AI tooling: Automated Code Review for Sensitive Data: Tools like GitHub Copilot  and DeepCode  can flag hardcoded secrets, credentials, or personal data before code goes public. AI-Powered Documentation Generation: Tools like Mintlify , Tabnine , or even ChatGPT  can generate clear, developer-friendly documentation to make open-source code easier to understand and reuse. Open-Source Licence Selection Support: AI chatbots  and tools can guide developers in choosing appropriate open-source licences  (e.g., MIT  vs GPL ), making compliance simpler. Code Quality and Security Scanning: AI-enhanced tools like Snyk  or SonarQube  help ensure open code is clean, consistent, and secure before being published. Automated Issue Triage: NLP models  can help maintainers tag and sort GitHub issues or pull requests, speeding up community collaboration. Future AI innovations: Autonomous Redaction Bots: AI agents could scan and redact sensitive data , environment variables , or internal logic automatically before code is pushed to a public repo. Intelligent Open-Source Readiness  Advisors: AI tools could assess a private codebase’s readiness for open sourcing, providing a checklist or roadmap  for teams to completely open-source their service code. Adaptive Licensing Engines: AI could analyse dependencies  and business goals to suggest or automatically apply the most appropriate open-source licence  dynamically. Multi-language Documentation Bots: Future AI could generate documentation in multiple languages  to expand accessibility and global reuse of government code. AI Legal Assistants: AI tools could review legal implications  of publishing specific code, highlighting potential compliance or intellectual property  issues. Point 13. Use and contribute to open standards, common components and patterns Service Standard summary : Point 13 emphasises the importance for service teams to utilise and contribute to open standards, common components, and patterns. This approach allows teams to leverage existing solutions, enhancing user experience and cost efficiency. Teams are encouraged to use standard government technology components, maximise technological flexibility through APIs and authoritative data sources, and share any new components or patterns they develop, such as by contributing to the GOV.UK Design System . Additionally, when creating potentially useful data, services should publish it in an open, machine-readable  format under an Open Government Licence , ensuring sensitive or personal information is appropriately protected. Existing AI tooling: AI Code Review and Refactoring Tools: Tools like GitHub Copilot  or Amazon CodeWhisperer  can help teams identify non-standard code and refactor it to align with open standards or existing component libraries. Automated Documentation Generation: AI tools like GitHub Copilot , Swimm , Mintlify , Documatic , and Codex  can help government teams generate and maintain clear, up-to-date documentation for APIs, services, and components, improving transparency, reuse, and onboarding across departments. Design Pattern Recognition: AI can scan repositories and identify reusable UI  or service patterns  across services, helping teams understand where standard components are being used (or could be). Component Matching  Tools: AI can suggest existing GOV.UK Design System components  when a developer starts building something similar, reducing duplication and encouraging reuse. Open Data Quality Checks: AI can validate open data  for formatting issues, accessibility , or privacy risks, ensuring it's published in compliant and useful formats . Future AI innovations: AI-Driven Pattern Libraries : Imagine a tool that could automatically create and evolve a design/component library by learning from thousands of public services and interfaces across government. Conversational Component Builders: Voice/chat interfaces  that could let developers or designers describe a need in plain English, and the AI returns a standard component or generates one, ready for review and inclusion. Predictive Contribution Suggestions: AI tools that could analyse what a team is working on and proactively suggest which components , standards , or patterns  they could contribute back to central libraries, with boilerplate documentation  and tests. AI Code Compliance Enforcement: Advanced AI linters  that could not only point out code issues but teach the team how to align their work with government standards  interactively, like a smart mentor . Semantic Data Publishing Assistants: Tools that help teams model, tag, and publish new datasets in machine-readable , standard-compliant formats , using semantic web technologies  and natural language interfaces . Point 14. Operate a reliable service Service Standard summary : The GOV.UK Service Manual advises that online government services must be reliable, available, and responsive at all times. This involves maximising uptime, enabling frequent deployments without disruption, regularly testing in live-like environments, implementing robust monitoring and response plans, and addressing any organisational or contractual barriers to service reliability. Existing AI tooling: Anomaly Detection and Alerting: AI models can monitor system metrics and logs in real-time to detect unusual patterns like latency spikes or error rates. Tools like Datadog Watchdog  use machine learning to surface these anomalies automatically, helping teams act before users are impacted. Predictive Maintenance: By analysing historical performance data, AI can predict potential failures in infrastructure or applications. Platforms such as Amazon DevOps Guru  and Azure Monitor  leverage machine learning to forecast issues and recommend proactive fixes, reducing unplanned downtime. Automated Incident Triage: AI can automatically categorise and prioritise incidents, and even route them to the appropriate teams. PagerDuty’s Intelligent Triage  uses machine learning to consolidate related alerts and assess severity, enabling faster, more accurate responses. Load Forecasting: Machine learning can predict traffic patterns based on usage history, helping systems scale resources dynamically. Google Cloud’s AI Forecasting  tools support infrastructure teams in anticipating demand and adjusting capacity before bottlenecks occur. Intelligent Log Analysis: AI-powered tools can scan and summarise vast amounts of log data to highlight root causes and potential solutions. Platforms like Logz.io  and Elastic’s machine learning features  apply anomaly detection and natural language processing to make logs more actionable. Test Automation with AI: AI can improve software quality by generating and prioritising test cases based on real user behaviour. Tools like Testim  and Mabl  use machine learning to create adaptive, resilient automated tests that evolve alongside the application. Future AI innovations: Self-Healing Systems : Services that could automatically detect, diagnose, and correct issues in real-time with minimal human intervention, like restarting components or rolling back code. Autonomous Release Pipelines: AI systems that could decide the safest deployment windows and run dynamic risk assessments , pausing or altering deployments if anomalies are predicted. AI-Driven UX Monitoring : Tools that could interpret user sentiment or behavioural cues to detect subtle experience degradation before technical metrics reflect an issue. Cognitive Load  Prediction for Engineers - Future AI might help balance incident response load across teams, considering stress, alert fatigue , or previous workloads. Cross-Service Correlation Engines : AI could automatically correlate incidents across microservices or departments to pinpoint systemic failures more accurately and quickly. Proactive Compliance Monitoring : Smart systems could monitor changes in regulations and scan services to detect potential compliance issues before they impact service reliability. Conclusion Throughout this series, we’ve looked at how AI can support each of the 14 points in the UK Government Service Standard. From improving user research and simplifying journeys, to enhancing security and maintaining reliable infrastructure, AI is already beginning to transform how service teams operate. We’ve explored how current tools, across disciplines, can reduce repetitive work, improve decision-making, and help teams focus on what matters most: delivering accessible, effective, and inclusive public services. We’ve also considered what might be possible in the near future, where AI acts as a co-pilot across design, delivery, operations, and beyond. Crucially, we’ve acknowledged that AI is not a silver bullet. It must be applied thoughtfully, safely, and ethically. The UK Government’s AI Playbook  provides a clear foundation for doing just that, giving teams the frameworks, training, and principles needed to explore AI without compromising public trust or accountability. To further support implementation, the government has introduced a series of AI training courses through Civil Service Learning  and Government Campus , developed in partnership with leading technology providers and the Government Skills unit. These learning resources are designed to equip civil servants with the confidence and expertise to apply AI effectively in their roles. As AI capabilities mature, so too must our approach to delivery. The opportunity is not just to use AI for efficiency, but to use it as a force multiplier for a better, more human-centred government. If you work on digital services in the public sector, now is the time to start evaluating where AI might make your work more focused, inclusive, or sustainable. Not by replacing expertise, but by extending it. Thank you for following along with this series. I hope it has sparked ideas, opened questions, and helped you see AI as a practical and responsible enabler of better public service delivery. As always, I’d welcome your feedback and perspectives, especially as this space continues to evolve. Open collaboration and ongoing dialogue will be essential as we navigate this emerging, AI-enhanced landscape together. Contact information If you have any questions about our AI initiatives, Software Engineering Service, or you want to find out more about other services we provide at Solirius Reply, please get in touch (opens in a new tab) .