Showing posts with label api. Show all posts
Showing posts with label api. Show all posts

Monday, August 17, 2015

Digital Transition Office to make creating APIs mandatory for federal agencies

Last week the Digital Transition 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 APIs.

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.


Read full post...

Wednesday, August 18, 2010

UK redevelops legislative database to support and encourage reuse

Brought to my attention by Mia Garlick via Twitter, the UK has redeveloped its legislative database with a focus on reuse by external parties.

The recently released site legislation.gov.uk covers 800 years of legislation from England, Scotland, Wales and Northern Ireland.

According to an article from Cornell University Law School, Legislation.gov.uk, John Sheridan, Head of e-Services and Strategy at The National Archives says that the site was designed to meet two objectives,

to deliver a high quality public service for people who need to consult, cite, and use legislation on the Web; and to expose the UK’s Statute Book as data, for people to take, use, and re-use for whatever purpose or application they wish.
The Crown Copyright for the site specifies that,
You are encouraged to use and re-use the information that is available on this site freely and flexibly, with only a few conditions.

This type of approach makes legislation vastly more accessible to the public and, through an API provided by the site, supports the development of applications and services that assist the public, organisations and lawyers to understand and apply the law.

More information on why and how the site was designed is available in the article referenced above.

Australia isn't yet at the same point. Our legislation, detailed at Comlaw, is not yet supported through APIs or other machine-readable data formats and is covered under a more restrictive licensing regime,
This work is copyright. You may download, display, print and reproduce this material in unaltered form only (retaining this notice) for your personal, non-commercial use or use within your organisation. Apart from any use as permitted under the Copyright Act 1968, all other rights are reserved.

Read full post...

Wednesday, July 01, 2009

New York Senate opens up its data to the public

The New York State Senate has launched its Open Senate initiative with an API (Application Programming Interface) allowing the public direct access to its data.

The NY Senate is also making the code freely available as open source, stating that,

As a user of Open-Source software the New York Senate wants to help give back to the community that has given it so much - including this website. To meet its needs the Senate is constantly devleoping new code and fixing existing bugs. Not only does the Senate recognize that it has a responsibility to give back to the Open Source community, but public developments, made with public money should be public.
The Senate is also working towards making most NY State government data freely available on their open data site.

Read full post...

Bookmark and Share