Guest blogger: James Stewart is Tech Lead for the Government Digital Service (GDS), a new central government business unit working on delivering government services online and digitally by default. After many years freelancing and running a small web development agency (Ket Lai) he joined GDS to build the prototype, and is now pulling together a team of in-house developers to work as part of inter-disciplinary teams on government projects. James will be discussing the topic below in more depth at Huddle’s government cloud computing conference on 12 October. Read more and register here.

Chances are we’ve all been hearing a lot about Agile lately. Agile approaches to software development have been around for a while now, but for a variety of reasons have been slow to catch on in government work. Having worked on, one of the higher profile examples of Agile in government, I’m very glad to see it beginning to take hold.

Agile’s a great way to approach development – tight but flexible development cycles with clear deliverables from each sprint give a clear indication of progress for all involved and allow trust to be established quickly. Iterative design means you expect to refine how your product should work once there’s something to really play with. But an often overlooked development that goes with it is the possibility of “agile operations”.

When building any software system, whether it’s a back-office accounting tool or a public facing website, it’s almost impossible to know exactly how it will perform until some way into the development process. An experienced architect will be able to identify potential bottlenecks some way off, but as the software and the requirements are iterated that will change, and with the current pace of progress, new technologies may well appear that open up new frontiers and opportunities.

A good example is the emerging range of “NoSQL” database systems. These are a new generation of database servers that operate on a very different set of assumptions from the likes of Oracle, SQL Server or MySQL. They have a very different set of strengths and weaknesses, and require a slightly different approach to hosting and deployment. We’re using one of these – a database called MongoDB which is tuned for storing documents – very extensively in building the Single Domain beta, but we only came to it after a few weeks of trying out some more traditional systems. In a traditional process, that change could well have landed us in all sorts of contractual wrangling as we specified a rather different set of servers.

That’s where the “Infrastructure as a Service” layer of cloud services can be a real boon. Where once you would have to commit to significant capital expense to buy up a set of servers tuned to a specific system architecture, it’s now trivial to set up an Amazon EC2 virtual server (or several), try out a network configuration, an alternative database, or a particular caching strategy, and then easily switch it all back off once you understand the issues or make a different decision.

Request a Demo

© 2006 - 2021. All Rights Reserved.