DTO mandates APIs for Federal agencies

This article is by Craig Thomler, digital specialist and Government 2.0 advocate. Thomler is one of Australia’s foremost experts on eGovernment and Government 2.0 issues. It first appeared on Thomler’s popular blog, eGov AU, and is replicated here with his permission.

opinion/analysis Last week the Digital Transformation Office (DTO) released a draft of its API Design Guide for public review.

An API, or Application Programming Interface, is an approach that defines consistent methods of inputting and outputting data into a software system based on internet protocols. APIs are regularly used by Web 2.0 services as a standard way to connect to each other, share information and support seamless integrated functions (such as connecting your mailing list service with your survey tool).

The government already has a few APIs, generally around the edge of its services and functions – such as for the National Library’s Trove service and the Pharmaceuticals Benefit Scheme.

However what is suggested in the DTO’s post is that the DTO is looking to make it mandatory for government agencies to create APIs for all new services, and to consume their own APIs when delivering those services.

To people who know little about IT this might be a ‘so what’ moment. However if you think about the impact of this shift on how governments design services, who delivers them and how they are integrated with other services across agencies, this is a very big deal indeed.

AGIMO (Australian Government Information Management Office), as the former body established to guide federal technology use, always suffered from not having the ability to mandate certain techniques and approaches. It could cajole, suggest, recommend and advise agencies on good technology paths, and its position within Finance gave it a few teeth, however AGIMO never had the capability to mandate or enforce technology standards without the goodwill of every other major department’s CIO.

So for the DTO to have a mandate in this area means it can design and enforce the practice, providing more standardisation across agencies and opening the door to knowledge and expertise sharing within government and certainty on how to engage agencies from outside.

One of the potential outcomes of making APIs mandatory is that 3rd parties outside of government will be able to deliver any new government service, mash together services from different agencies into new service approaches, or even combine government and private services into a single unified offering.

Anyone with a website and a little expertise could become a front-end for people seeking to access government services or information.

Equally, government agencies (whether local, state or federal) could connect federal services to their own, likewise potentially in a seamless way.

Theoretically there could be a single system across government for changing your address, or you could register a company, your ABN, for GST and for a state license for your business in the same transaction.

The DTO’s draft design also says that agencies will have to consume their own APIs (‘eat their own dogfood’) when delivering their services.

This means agencies will have to build robust and effective APIs to support their service requirements, rather than build them as an afterthought (a very good thing) and it support the development of usable interfaces that aren’t limited by a particular IT back-end approach.

Of course all of this relies on how well the mandate is executed – which leaves Paul Shetler’s team with some challenges.

First they have to build recognition within government, as a mandate, agency CIOs can no longer go their own way, they need to work together with the DTO to establish appropriate standards that suit agency deliverables and services.

Secondly they will have to address any skills gaps. Few agencies have experience developing APIs – particularly where there’s complex services that require them, or there’s need for secure APOs.

Finally they’ll have to keep all the cats herded. Ministers have a tendency to ask for things at short notice – such as new services or changes to existing ones. When agencies face these requests they often are limited in time, money and the skills to achieve them. Developing APIs will hardly be on the top of their priority list, they will be hardpressed just to get a service in place in time to meet the Minister’s announcement deadline.

However despite all these challenges, the cause is a great one and could do more to transform how government IT operates than many more public steps.

If the DTO can pull this off, have agencies fall in line and have APIs start rolling off government IT ‘production lines’, it will have single-handedly justified its own existence and transformed how government works, even if it doesn’t achieve anything else in the next few years.