{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "news",
    "type" : "single",
    "title" : "Q&A With Ryan Day About GSA’s API Strategy |Digital.gov",
    "description": "Q&A With Ryan Day About GSA’s API Strategy",
    "home_page_url" : "/preview/gsa/digitalgov.gov/cm-topics-button-component/","feed_url" : "/preview/gsa/digitalgov.gov/cm-topics-button-component/2019/03/27/qa-with-ryan-day-about-gsas-api-strategy/index.json","item" : [
    {"title" :"Q\u0026amp;A With Ryan Day About GSA’s API Strategy","deck" : "These new API standards will make it easier for GSA staff to launch and maintain good APIs.","summary" : "These new API standards will make it easier for GSA staff to launch and maintain good APIs.","date" : "2019-03-27T13:00:00-05:00","date_modified" : "2024-04-02T09:45:13-04:00","authors" : {"gray-brooks" : "Gray Brooks","ryan-day" : "Ryan Day"},"topics" : {
        
            "application-programming-interface" : "Application programming interface",
            "open-source" : "Open Source",
            "product-and-project-management" : "Product and project management",
            "software-engineering" : "Software Engineering"
            },"featured_image" : { "uid" :
  "q-and-a", "alt" :
  "" },"branch" : "cm-topics-button-component",
      "filename" :"2019-03-27-qa-with-ryan-day-about-gsas-api-strategy.md",
      
      "filepath" :"news/2019/03/2019-03-27-qa-with-ryan-day-about-gsas-api-strategy.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/cm-topics-button-component/content/news/2019/03/2019-03-27-qa-with-ryan-day-about-gsas-api-strategy.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/cm-topics-button-component/content/news/2019/03/2019-03-27-qa-with-ryan-day-about-gsas-api-strategy.md","slug" : "qa-with-ryan-day-about-gsas-api-strategy","url" : "/preview/gsa/digitalgov.gov/cm-topics-button-component/2019/03/27/qa-with-ryan-day-about-gsas-api-strategy/","content" :"\u003cp\u003eDavid Shive, chief information officer at The U.S. General Services Administration (GSA) recently published \u003ca href=\"https://gsablogs.gsa.gov/innovation/2019/02/26/gsa-rolls-out-agency-api-standards/\"\u003ean update about our agency’s adoption of an API standards\u003c/a\u003e which seeks to improve the developer experience for those who use our agency’s APIs, and save time and money by making it easier for GSA staff to launch and maintain good APIs. This initiative is the culmination of a good bit of work that we hope will be a model for other agencies to follow.\u003c/p\u003e\n\u003cp\u003eGray Brooks recently chatted with Ryan Day, who leads \u003ca href=\"https://tech.gsa.gov/guides/API_strategy/\"\u003eGSA’s API Strategy\u003c/a\u003e, to discuss the background to this effort.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e\u003cstrong\u003eGray Brooks:\u003c/strong\u003e To start, tell me at a high level what problem you were solving for with this initiative?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRyan Day:\u003c/strong\u003e We wanted to define what a high quality API is, and provide a clear path for GSA’s API programs to implement one.\u003c/p\u003e\n\u003cp\u003eAPIs are important to GSA, and we have been developing and operating them for many years. We have fantastic programs and teams inside GSA that produce high quality work. But since we didn’t have a consistent set of \u003ca href=\"https://github.com/GSA/api-standards\"\u003eAPI standards\u003c/a\u003e, each new project team had to make design decisions in a vacuum instead of using a consistent pattern. And outside users of our APIs could tell: the APIs were not always consistent.\u003c/p\u003e\n\u003cp\u003eThese new API standards streamline the process for GSA teams to design, develop, and operate their APIs. We have made some of the most common decisions ahead of time, so GSA teams don’t have to.\u003c/p\u003e\n\u003cp\u003eGSA teams have begun the process of applying these standards to their existing and new APIs. We are focusing at first on our public APIs, but much of the information is relevant for non-public ones as well.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eGray:\u003c/strong\u003e At GSA, this effort has the direct support of the agency CTO and CIO. What advice would you give to someone at another agency who is trying to implement API standards and wants to get that same type of buy-in and support?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRyan:\u003c/strong\u003e That’s true — our previous CTO actually developed the API strategy and the CIO has supported the work all along the way.\u003c/p\u003e\n\u003cp\u003eTo get to that point in another agency, I would start by reinforcing the value of APIs to the agency’s mission, to show why they deserve the attention. A good way to do this is by showcasing the work that other agencies are doing in the federal government. There are a lot of great examples of API programs, but two off the top of my head are the \u003ca href=\"https://bluebutton.cms.gov/\"\u003eBlue Button API at Centers for Medicare and Medicaid Services\u003c/a\u003e and \u003ca href=\"https://govmatters.tv/veterans-affairs-launches-new-health-api-to-support-applications/\"\u003eDepartment of Veterans Affairs\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eThen I would explain that standards can save time and money up front and long term. They save time and money in the development, modernization, and enhancement phases (DM\u0026amp;E) by streamlining the decisions that project teams make for new APIs. If every development team has to make all of the decisions independently without following standards, that causes a lot of waste. They also save time and money in operations and maintenance phase (O\u0026amp;M) because the agency’s APIs will be consistent across programs, and IT teams can more easily support them.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eGray:\u003c/strong\u003e There are two constituencies for this effort—the API program owners at GSA, and the third party developers who are consuming these APIs. How have you balanced both of their needs?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRyan:\u003c/strong\u003e You’re right that both of those groups are key in an agency’s entire API strategy. Two of the three pillars in our \u003ca href=\"https://tech.gsa.gov/guides/API_strategy/\"\u003eAPI Strategy Implementation\u003c/a\u003e address those groups: “Internal Engagement” is our work with the GSA programs and “External Customer Experience” is our focus on the people using our APIs.\u003c/p\u003e\n\u003cp\u003eThe APIs that are produced using these standards will provide a fantastic experience for those third party developers through consistent design, useful documentation, clear and monitored support mechanisms, and more. So those third party developers will gain a lot as API programs implement the standards.\u003c/p\u003e\n\u003cp\u003eAnd the truth is the API program owners and their IT teams want to provide that fantastic experience, but there are a lot of different ways to accomplish that. These standards provide a shared vocabulary between the API program owners and their IT teams. By referencing the API standards, both will have a clear definition of what a “quality” API means in GSA.\u003c/p\u003e\n\u003cp\u003eThose program owners and IT teams worked closely with us as we drafted the standards and assessed the level of effort to implement them. We made several adjustments based on their feedback so that the standards would be workable for them.\u003c/p\u003e\n\u003cp\u003eWe also continue to provide them with tools and assistance to help them be successful. Our motto for this effort is “Making The Right Thing The Easy Thing.”\u003c/p\u003e\n\u003cdiv\n  class=\"image\"\n\u003e\u003cimg\n      src=\"https://s3.amazonaws.com/digitalgov/api-pillars_w800.png\"\n      \n        alt=\"Illustration of GSA’s 3-pillar approach for implementing the API strategy — external customer experience, internal engagement, and technical architecture\"\n        srcset=\"https://s3.amazonaws.com/digitalgov/api-pillars_bu.jpg 48w,https://s3.amazonaws.com/digitalgov/api-pillars_w800.png 800w,https://s3.amazonaws.com/digitalgov/api-pillars_w600.png 600w,https://s3.amazonaws.com/digitalgov/api-pillars_w400.png 400w,https://s3.amazonaws.com/digitalgov/api-pillars_w200.png 200w\"\n\n      sizes=\"(max-width: 800px) 100vw, 800px\"\n    /\u003e\u003cp\u003eGSA’s 3-pillar approach for implementing the API strategy\u003c/p\u003e\u003c/div\u003e\n\n\n\u003cp\u003e\u003cstrong\u003eGray:\u003c/strong\u003e What resources from GSA’s API standards and your work are reusable by other agencies.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRyan:\u003c/strong\u003e The standards themselves might be a good starting point for an agency that hasn’t developed their own standards or API style guide. Agencies are welcome to fork them or otherwise reference them. We certainly benefited from the \u003ca href=\"https://github.com/WhiteHouse/api-standards\"\u003ework done previously by the White House\u003c/a\u003e and \u003ca href=\"https://github.com/18F/api-standards\"\u003eour own 18F organization\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eAnd if a federal agency is not already using the \u003ca href=\"https://api.data.gov\"\u003eapi.data.gov\u003c/a\u003e API management platform, they should check that out immediately. That platform is kind of a cheat code for implementing standards such as these, because standards can be applied to the customer-facing view without changing the existing back-end implementation.\u003c/p\u003e\n\u003cp\u003eIn addition, our developer portal is hosted on the \u003ca href=\"https://federalist.18f.gov/\"\u003eFederalist platform\u003c/a\u003e and the source code of our portal resides in \u003ca href=\"https://github.com/GSA/open-gsa-redesign\"\u003ean open source code repository\u003c/a\u003e. It might be a useful starting point for an agency developing their own API documentation or developer portal.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eGray:\u003c/strong\u003e How do you see open source methods enabling this work with GSA API programs?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRyan:\u003c/strong\u003e We definitely benefit from a lot of open source work in our API program. The api.data.gov platform I mentioned before is built around the API Umbrella, which is an open source project. Our \u003ca href=\"https://open.gsa.gov/api/\"\u003eDeveloper Portal\u003c/a\u003e is built using the \u003ca href=\"https://designsystem.digital.gov/\"\u003eU.S. Web Design System\u003c/a\u003e, which is also open source. Our standards also require that public APIs provide an \u003ca href=\"https://github.com/OAI/OpenAPI-Specification\"\u003eOpenAPI specification\u003c/a\u003e file in their documentation, so that API users can import that file into their tooling and save a lot of manual effort.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eGray:\u003c/strong\u003e What are your next goals?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRyan:\u003c/strong\u003e Overall, we will continue to drive our work in the three pillars of our API strategy implementation: External Customer Experience, Internal Engagement, and Technical Architecture.\u003c/p\u003e\n\u003cp\u003eWe recently rolled out to GSA teams the ability to host their API documentation directly on our developer portal via self-service.\u003c/p\u003e\n\u003cp\u003eWe are working closely with our security organization to develop several guides and playbooks to ensure that APIs are developed in a secure manner and properly authorized.\u003c/p\u003e\n\u003cp\u003eWe also will be turning our focus to the non-public APIs that are used for system integration. We hope to use many of the same techniques to streamline the way we use APIs to connect systems internally. We see this as key to delivering an architecture where systems are easier to maintain, deploy, and enhance.\u003c/p\u003e\n\u003cp\u003eAnd we hope to use human centered design techniques to become more familiar with the developers and citizens who are using our public APIs. We want to understand their needs and goals and improve our onboarding process and developer portal to serve them better.\u003c/p\u003e\n\u003ch2 id=\"key-resources\"\u003eKey Resources:\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eGSA’s Developer Portal: \u003ca href=\"https://open.gsa.gov/api\"\u003ehttps://open.gsa.gov/api\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eSource code for GSA’s Developer Portal: \u003ca href=\"https://github.com/GSA/open-gsa-redesign\"\u003ehttps://github.com/GSA/open-gsa-redesign\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eGSA’s API Standards: \u003ca href=\"https://github.com/GSA/api-standards\"\u003ehttps://github.com/GSA/api-standards\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eThe API.DATA.GOV platform: \u003ca href=\"https://api.data.gov/about/\"\u003ehttps://api.data.gov/about/\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eThe Federalist platform: \u003ca href=\"https://federalist.18f.gov/\"\u003ehttps://federalist.18f.gov/\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eGSA’s open source policy: \u003ca href=\"https://open.gsa.gov/oss-policy/\"\u003ehttps://open.gsa.gov/oss-policy/\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eGSA’s API Strategy: \u003ca href=\"https://tech.gsa.gov/guides/API_strategy/\"\u003ehttps://tech.gsa.gov/guides/API_strategy/\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n"}
  ]
}