Making The Case for API

A Tangled Web of Tech

Let’s face it. We live in an age of constantly changing, ever expanding technologies. The underlying infrastructure of those technologies only adds to the complexity. It’s a heterogeneous mixture of old tech and new tech held together, and in some cases, made better by future tech. More simply put, it’s a tangled web of tech.

It’s no secret that the federal government tends to hold on to old tech for a variety of reasons. For example, some web authoring tools (WAT) use Java plugins to execute interface applications within the what-you-see-is-what-you-get (WYSIWYG), web-based editor.

Unfortunately, many agencies will choose one technology and build other components around that single platform which can quickly become a single point of failure. I’ve experienced that scenario firsthand at a previous post. Most of the applications used at that agency were built using older versions of Java that are now obsolete and unsupported. Every time a new version of Java was pushed to users’ machines, a ticket needed to be logged with the local help desk to revert the install and roll the new version back to what was. If that wasn’t accomplished, we were all “dead in the water,” so to speak. It was incredibly inefficient and stifled innovation.

Bridging The Gap

The good news is that there’s a solution to help breathe new life back into old tech. Application programming interfaces (APIs) can help by tethering multiple, disparate pieces of hardware or software to achieve a single output or objective. Taking the mumbo jumbo out of the definition, APIs work by culling information from different data sets, rearranging it, and putting it together in a visually complete way.

Here’s a good video that outlines how an API works for those that might be new to the concept. The information contained in the video posted below represents the views and opinions of the original creators of such video content and does not necessarily represent the views or opinions of myself or any federal entity. Please note that no endorsement is expressed or implied.

Figuring out how APIs would integrate with existing systems might be puzzling in and of itself, but the ROI on API applications can be tremendous – and cost savings too. While some agencies have been using APIs for quite some time, at the Veterans Health Administration, we’re actively surveying our technological landscape and identifying new applications for API integration potential.

Recent API Efforts

In VHA, we’re developing a prototype API that integrates with our department’s content management system (CMS). It assesses every document for Section 508 accessibility compliance before it can be uploaded and published in the production environment. This API uses data from an open source accessibility checker to validate a number of checkpoints based on the WCAG 2.0 guidelines. It will then generate a report of the findings and send an email to workflow operators/approvers of the intent to publish and status of that file from a compliance standpoint. If you read my last post, you’ll note it focused on the importance of web accessibility and designing with the user of assistive technology in mind. We’re excited about the potential of this API to help us stay on the right side of the law and avoid future, costly and time consuming remediation efforts.

Similarly, I’m the business owner for a complex API integration effort using our department’s existing cloud-based email communications client. This project involves more than 70 vested stakeholders from our OIT department as it creates an authenticated bridge between the communications cloud and our active directory (AD) client. The long-term vision is to reduce multiple, redundant email distribution lists in a move toward cloud-based messaging with both internal employees and external customers. This model will streamline and enhance internal employee communications by way of platform analytics and metrics collected on every message sent. VA leadership can use this data to measure the effectiveness of internal communications.

Tips for Successful API Integration

With reference to the two cases above, I’ve learned a great deal navigating the ebb and flow of inquiries from our OIT department. If you’re about to make the case for API usage at your agency or department, here are some tips that may help:

1. Find a committed SES or equivalent sponsor, preferably someone who knows tech well.
2. They will try and expose vulnerabilities of the API. Make sure you have done your research in terms of cybersecurity – is the API’s hosting platform FedRAMP compliant and is a valid ATO (authority to operate) in place?
3. Make sure any anticipated risk mitigation strategies, fail over, or contingency plan equivalents are clearly communicated to bypass structural/network integrity concerns.
4. If there’s a cost involved for OIT, you may face an uphill battle of obtaining those funds for the development effort. Don’t expect your local OIT group to foot the bill for development. Instead, build that in as a requirement in the SOW (statement of work) or PWS (performance work statement) for your contract.
5. Network with an insider. By knowing someone internal to your OIT group, you have a better chance of getting the right folks’ attention early on.
6. Tie your request to strategic goals for your agency or department to help support the justification.
7. Back it up with metrics. Show how you can measure the ROI with actionable results.
8. Document everything and keep your materials in a secure, but accessible location.

Blake Scates  is part of the GovLoop Featured Contributor program, where we feature articles by government voices from all across the country (and world!). To see more Featured Contributor posts, click here.