API Governance Models in the Public and Private Sectors: Part 4
API Governance Models in the Public and Private Sectors: Part 4
Join us as the API Evangelist, Kin Lane, shares a detailed report concerning the U.S. Department of Veteran Affairs and its wish to understand API governance.
Join the DZone community and get the full member experience.Join For Free
Discover how you can get APIs and microservices to work at true enterprise scale.
This is part four (you can find part three here) of an eight-part series on the Department of Veterans Affairs microconsulting project, “Governance Models in Public and Private Sector.” Providing an overview of API governance to help the VA, “understand, with the intention to adopt, best practices from the private and public sector, specifically for prioritizing APIs to build, standards to which to build APIs, and making the APIs usable by external consumers.” Pulling together several years of research conducted by industry analyst API Evangelist, as well as phone interviews with API practitioners from large enterprise organizations who are implementing API governance on the ground across the public and private sector, conducted by Skylight Digital.
We’ve assembled this report to reflect the interview conversations we had with leaders from the space, helping provide a walkthrough of the types of roles and software architecture being employed to implement governance at large organizations. Then, we walk through governance as it pertains to identifying possible APIs, developing standards around the delivery of APIs, how organizations are moving APIs into production, as well as presenting them to their consumers. Wrapping up with an overview of formal API governance details, as well as an acknowledgment that most API governance is rarely ever a fully formed initiative at this point in time. Providing a narrative for API governance, with a wealth of bulleted elements that can be considered, and assembled in the service of helping govern the API efforts across any large enterprise.
Defining Data Models and Standards
To help realize and deliver upon governance at scale, it will take heavy investment in standardizing data models and incorporating existing patterns and standards throughout the API delivery lifecycle. Many enterprise API development groups are streamlining and standardizing the delivery of APIs through the adoption and development of standards across operations, which is something that is also contributing to adoption, integration, and removing friction for application developers.
The adoption of common data models, interfaces, media types, and web standards helps contribute to the delivery of consistent APIs at scale, but they can also prove to be a challenge for some teams, and even been seen as a threat by others. There are a number of ways in which teams are pushing for standardization across their operations, and helping achieve more consistency, reuse, and the desired results across operations. Reflecting one of the strengths of web APIs, in that they employ web standards to achieve wider adoption and delivery of valuable resources at web scale.
A suite of approaches have emerged in the last decade for designing, developing, evolving, and applying common API patterns across the API lifecycle. These standardized approaches to defining and delivering APIs, using common machine-readable specifications and widely used patterns, have become central to API governance discussions. Providing the fuel for the growth of the API sector to serve mobile applications as well as the growth of other emerging channels like voice, bot automation, and the connecting of everyday objects to the net. Helping the enterprise get more organized about how services are delivered across the organization at scale.
- Resource-Defined — RESTful design patterns have provided a simple approach to taking corporate resources and defining them as an intuitive, reusable, potentially web-scale stack of API resources that can be used across a variety of applications. REST provides a philosophy that can be adopted across the enterprise to help organize digital resources as a reusable stack of resources that can be discovered and put to use across many channels.
- Schema-Driven — JSON Schema is being used to take a variety of schema and standardize them for use in RESTful API resource delivery. Providing a reusable blueprint that can be used across the request and response model for all APIs. Deriving, and standardizing existing schema in use, and making available for usage in newly developed, and evolving APIs allows for teams to achieve many of the objectives set out as part of modern API strategies.
- Domain Driven — The business domain is used across the enterprise for guiding the identification, development, evolution, and standardization of a variety of API definitions in use across the enterprise. Lines of business, industry definitions, and a focus on the domain help establish areas of concern, and the separation of services, allowing for the decoupling of enterprise resources used across systems, but working in unison to deliver a single set of business objectives.
- Legacy Abstraction — Continue movements to decouple, redefine, and evolve legacy systems is pushing forward the identification of common patterns, and pushing to map, transform, and give them new life as newer web APIs. Taking legacy databases, system interfaces, and distilling the wisdom that exists across them to help drive the development of common standards.
- Vocabularies — API development teams are establishing common vocabularies based upon the standardized language already in use, but also essentially taking the slang that is used in bespoke systems and helping tame it, and add it to the common lexicon when it makes sense. Providing a standard language that can be used across the enterprise to talk about services, resources, and digital assets.
- Discovery — Many groups expressed challenges around standards not seeing the desired adoption because other teams could not find existing schema, definitions, and other existing standards. Emphasizing the importance of comprehensive, actively maintained, and evangelized catalog of core definitions across the enterprise. Providing a single or distributed location where everyone can find and publish their common definitions.
The definitions coming out of existing API development efforts are being organized into catalog, and discovery systems that can be used to guide governance efforts. Mapping out the known landscape across the enterprise, and turning it into the common patterns that can be reused across the design, development, and operation of the next generation of APIs. Distilling down the essence of the enterprise so that it can become the building blocks of an API program, while also allowing each stop along the lifecycle to be quantified, measured, and considered as part of a wider governance strategy.
Doing Business On The Web
APIs are built on the web. They use and benefit from over 25 years of evolution of the web. There are a number of elements to consider when working to identify and define common standards for use across the governance of any API program. While the API strategy should be rooted in definitions derived from the core of the enterprise, secondarily, it should be embracing the web and employing common patterns that make the web work to use as the foundation for delivering APIs.
- Web Standards — The web is the foundation for the delivery of APIs. Most APIs will use HTTP as a transport and employing URLs, HTTP verbs, headers, parameters, and other common web standards. Web standards should be part of any governance strategy to help establish common patterns and definitions for use across operations.
- Media Types — Media types are a fundamental part of the web and help establish message formats that will be widely recognized outside the enterprise, encouraging the reuse and adoption of APIs that employ common media types. Allowing consumers to negotiate the format that makes the most sense to their team and the types of applications they are looking to develop.
- Industry Schema — Industry level schema are emerging and maturing for use across API operations. Specifications like FHIR, PSD2, and other schema, along with API design patterns, are evolving to help support industry focused API operations while encouraging reuse and interoperability across disparate groups.
- Open Source — The usage of open source software, tooling, specifications, and processes are helping deliver on the API vision across the enterprise. Web APIs reflect the open source ethos and plays well with the delivery of web APIs. Encouraging reuse, adoption, and bringing the observability necessary to help APIs succeed.
APIs are all about doing business on the web. The web provides the platform in which any API program will operate. When it comes to defining schema, standards, and common patterns for use across API operations, the web is always the beginning of the conversation. While enterprise defined patterns will always be front and center, the standards used to operate the web should always trump localized definitions and be given priority whenever possible. Don’t reinvent the wheel when it comes to the web; always reuse and implement what is already known.
Under The Influence
When learning about new standards and considering which standards to adopt, it can be easy to find yourself under the influence of specific vendors, competing standards, programming communities, and other factors. Careful evaluation of standards is important, and an awareness of what some of the common elements are that may shift your opinions one way or another, or even obfuscate what is real and prevent you from achieving objectives.
- Caught in Trends — Avoid getting caught up in the trend cycles that can often make it difficult to understand the hype around specific specifications. Do your research, understand best practices and adoption levels, and make the sensible decisions around the impact to your own efforts.
- External Entities — While engaging with external entities, understand what their priorities are when it comes to standards and specifications. Consider what affinity may exist between enterprise objectives and any external entity that is engaged with, and makes sure there is the right alignment, and influences are pushing efforts in the right direction.
- Internal Demands — Similar to external entities, understand what the internal team's priorities are and don’t always assume internal requests will have the overall enterprise objectives in mind. Fully understanding what the awareness and motivation are around the implementation of specific standards, and how they fit into the overall strategy.
- Feedback Loops — Ensure that feedback looks are diverse, and provide a wealth of opinions around what types of standards and specifications should be supported, providing the widest possible view of the landscape when it comes to adoption and investment.
- Organic Change — Keeping an eye on vendor-induced standards adoption over a more organic approach to the growth of standards, internally, as well as the outside community. Working to understand when a standard is artificially inflated or amplified for alternative objectives beyond its core mission.
There are plenty of currents to get caught up in when it comes to identifying, defining, and evolving standards. Not all will bear fruit or realize the type of adoption they need to be successful. Establishing a balanced view of the landscape across internal and external actors, while keeping counsel with a diverse set of voices, can help ensure you understand which API specifications, standards, and definitions will help move the enterprise forward.
Taking The Lead
While there are a number of ready-to-use standards available for the web, and organically grown out of the API community, these standards won’t always find their way into the enterprise. Leading organizations demonstrate that it takes a structured effort to define, disseminate, educate, and evolve standards across large organizations, with a number of proven tactics for taking the lead when it comes to standardizing API infrastructure across the enterprise.
- Workshops — Organizing, conducting, and growing the number of workshops held to introduce individuals across many teams to a variety of common standards and specifications.
- Discussions — Formalizing discussions around emerging standards and those that are in use to help push forward awareness and adoption of standardized approaches across groups.
- Collaboration — Push teams to work together when it comes to sharing the standards in use, showcasing the investment they’ve made and working together to understand the tooling, services, and standards being used.
- Event Storming — Putting event storming, a rapid, lightweight group modeling technique to help accelerate the identification, evolution, and adoption of standards that meet specific team’s needs.
- Influencers — Identifying, investing in, and cultivating influencers who exist within current groups and encouraging them to evangelize and help spread the good word about standards across the enterprise.
- Ask Questions — Always be asking questions about the standards or lack of standards in use across the enterprise, pushing the conversation forward at all times when it comes to standards.
- Challenge Assumptions — Making sure teams don’t get complacent and that the status quo is always being challenged and that the internal domain should always be rising to a higher level of standardization whenever possible.
It takes standards bodies to move forward common standards at the web and industry levels, and it takes the same approach to push forward the adoption and usage of standards within the enterprise. Leading enterprise organizations are able to quantify, measure, and evolve the infrastructure in a more organized way through the adoption of common schemas, specifications, and standards. Providing a common vocabulary for all teams to use when designing, deploying, and managing services that can be used consistently across the enterprise and its public interests.
Stay tuned for part 5: Development to Production.
Opinions expressed by DZone contributors are their own.