Application Programming Interfaces, or APIs, have become a popular collaborative technology tool in recent years, allowing users to easily build helpful elements into their applications that overall improve the user experience. And as with a lot of leading private sector technologies these days, the public sector is working towards applying these protocols across federal agencies.
Recently, several public sector thought leaders gathered at the Marriott Marquee in Washington, D.C. to discuss the value of APIs for government agencies. Param Soni, Deputy Administrator and Director, ETA OIST at the Department of Labor, James Punteney, Director of Digital Services’ Travel Component at the Department of Homeland Security, Joe Paiva, CIO at the International Trade Administration, Rajesh Vasisht, Principal Consultant at Software AG Government Solutions, took part in a discussion about APIs and what they mean for federal agencies moving forward.
The discussion was sponsored by Software AG Government Solutions and hosted by Francis Rose of the Government Matters Thought Leadership Network. The discussion covered the following:
- How federal agencies are using APIs today
- The implications for citizen responsiveness and operational effectiveness
- How agencies can execute API strategies
How Federal Agencies are Using APIs Today
When asked about their current uses for APIs, Paiva explained that at the International Trade Administration, everything, both internally and externally, is done through platforms now, not system integration. He stated, “Externally, we use them [APIs] for what we call our wholesale distribution channel, where we enable partners to help U.S. companies using our information via APIs.”
At the Department of Homeland Security (DHS), Punteney delved into the usefulness of APIs across such a large agency. For a long time, it has served as more of an internal tool to connect the difference components of the agency, but it is now gradually becoming a more externally-facing tool.
APIs have actually posed a bit of a struggle for the Department of Labor (DoL), but it’s had positive effects. Soni discussed how the push for APIs is driving the agency’s need to innovate. “We have a lot of legacy application and we wanted to move them, organize them into a more web-based system,” said Soni. “So the approach we took was to first develop a platform…From a platform, we define the services. And from the services, we went to APIs…Going forward, all the new projects have a standard platform, we have services we have defined which are going to be the common, shared services. And as the new applications come in based on their business requirements, we have new services.”
Paiva was very clear that federal agencies do not create APIs (and he thinks they shouldn’t), but solicit services from SaaS companies to do so for them. “The real discussion is not about how you build the API. It’s about how you figure out what it is that…U.S. companies need,” he noted. “And once we know what the companies need, it’s about making sure that we build out the process by which that data is generated.”
Soni affirmed Paiva’s thoughts when applied to the DoL in that SaaS platforms support these new processes, but he did note that not all the unique services needed by federal agencies are always available with COTS solutions, authentication requirements for example, so the agencies are tasked with building more tailored services to meet end user needs, but who builds it doesn’t make much difference to the partner or customer.
“They [partners] want to be able to meet a legislative requirement to report on something or to get some data,” Soni explained. “So we are trying to meet their business need by shared services and then API how that information can be extracted in a seamless way.”
This brought the discussion to an important point: the intersection of APIs and shared services. Vasisht spoke to the value of APIs for federal agencies moving forward particularly due to their usefulness in shared services and the ability to tailor them as needed with sensitive information.
Vasisht said, “You can start out with something that’s out of the box, but then you need to extend it. So yeah, shared services are certainly available as both something you can buy out of the box as a SaaS or, in most cases, there’s going to be a hybrid situation where you extend it to do the thing you need it to do.”
How APIs Impact Customer Experience
Soni started off the discussion about the customer experience explaining what many already know, but might struggle applying: the fact that customers want more intuitive, faster, more aesthetically appealing interfaces. They also need an interface that meets their individual service requirements, and that’s where APIs come into play more heavily – creating a need for firm, organized IT approaches.
“The power of APIs is now we sit down and we think about the customer journey from the customer’s eyes,” stated Paiva. “The power of APIs is if that information [customer need] is with DHS, if that information is with Census, if that information is in private industry…then we’ll pull their API. It gets us out of this old, monolithic government thinking of ‘I’m always going to build everything in-house.’”
Paiva added, “No we’re actually building what our customers need instead of building around what our organization does.” This mentality hinges on the sentiment that providing a customer-centric user experience is not necessarily something that departments are pressured to create out of thin air. They can leverage insights and data that already exist and create a better, less expensive solution for their customers.
After Vasisht explained the importance of utilizing demos and mockups to really get to the root of customer goals, Punteney built on that and challenged federal agency leaders to think more critically about what the customer says they want and translate that into the program they actually need; many times they are not the same thing. “Initially when they say, ‘I want this’ as the why. ‘Why do you want that? What are you trying to accomplish?’ If you can get to that level of fidelity where they are using a prototype, you’ll learn a lot very quickly.”
How Agencies Measure the Success of APIs
When looking at how to constantly be improving the API implementation process, Soni explained that at the DoL, they look at commonalities among agency applications and see what can be consolidated or applied across agencies through a proof of concept. “Let’s take a big agency and a small agency and see if we can replicate their processes into a new SaaS-based solution, maybe use common processes, and cloud-based [solutions].”
The process of updating legacy processes is always daunting for federal agencies, but the first step in tackling a new approach like API integration is starting with the business goal according to Punteney. With that at the center of the entire decision making process, agencies are able to continue building on API structures that accomplish their goals.
“As a government person, you have to say ‘Is this really something the government has to do?’” added Paiva. Leaning on the strength of the private sector will be key in pushing forward the successful use of APIs in government settings.
From a commercial perspective, Vasisht offered that federal agencies need to think about whether they’d like to do a top-down approach or a bottom-up approach with implementation. “How much work has already been done at this organization in the API layer?” From there, the most sensible and cost-effective API strategy can start to take shape.