Fork me on GitHub

/Developer Program

Your agency logo

Agency Maturity Model


This document attempts to provide a description of an agency API program at different stages of development. This can assist an agency in determining its current state and to clarify a vision for further progress.

Maturity Model


Governance: “How well the API lifecycle is governed in terms of:
* Responsibility and ownership
* Effectiveness measurement and metrics
* Enterprise policies and guidance
* Compliance and control mechanisms
* Formal communication channels”

Requirements Management:
Extent to which requirements for Mobile APIs are clearly articulated and managed
Quality Assurance/ V&V / Compliance/Audit:
Extent to which policies, requirements, standards and processes are reviewed and enforced
Product Management:
Extent to which the longer term evolution of Mobile APIs are being formally managed so they continue to support mission/business goals and support consumer needs
Developer Engagement:
Extent to which an organization actively engages the developer community in defining and using Mobile APIs

Dimension Name None Basic Intermediate Advanced
Governance Adhoc development and usage of APIs. Reuse of intellectual assets. Version Control of APIs and fix support Full lifecycle governance: planning, testing, activation, deprecation, sunsetting Establishment of a CoE and published SLAs
Requirements Management No requirements Ad hoc gathering and definition of requirements; Little or no requirements traceability Requirements are defined and reviewed prior to Mobile API implementation Requirements management process is defined; Requirements clearly defined and documented and under configuration mgmt; formal traceability to mission/business requirements and technical artifact;
Quality Assurance/ V&V / Compliance/Audit No QA/compliance/audit Ad hoc QA/V&V process; Testing of Mobile APIs performed before deployment but defects are not tracked and all severe defects are not tracked to resolution QA/IV&V includes design reviews, code reviews and testing; All severe defects are tracked to resolution before release QA/V&V process for Mobile APIs defined; Testing a resolution of all severe defects completed before release; Compliance against approved standards performed before release; Periodic compliance audits performed
Product Management No product management Individual application teams guide development of Mobile APIs with little or no coordination with other application teams or enterprise guidance Informal coordination and cooperation among application teams and agencies to evolve Mobile APIs to continue to support mission/business goals and support consumer needs Product Manager designated who is responsible for formally reviewing, managing and updating Enterprise Mobile API plan so they continue to support mission/business goals and support consumer needs
Developer Engagement Passive/Spectator Responsive: Feedback mechanism, some support Active: Engagement tools such as forums, blogs Engaged: Developer gallery, events like hackathons, advocates and developers supporting each other


Compliance with Standards:
Extent to which standards compliance is coordinated across the enterprise
“Richardson Maturity Model for building RESTful APIs ( you can google this. But here is a good description:”
Software Development Kit (SDK):
Extent to which software development kits are provided to consumers to simplify implementation and ensure complaince with policy and standards (also see “Sharing APIs”) below)
How well the API deployment is taking security into consideration (network level, data level, user identity level, process and policy level, etc)

Dimension Name None Basic Intermediate Advanced
Compliance with Standards No coordination and no agreed upon standards Individual application teams strive to define and enforce standards for their specific application Individual agencies or organizational components define and enforce Mobile API technology standards Enterprise-wide technology standards defined and enforced for Mobile APIs
Technology Level 0 - Service end point communication: The systems focus are service end point URI and one HTTP verb (likely POST verb) for communication. Level 1- Resource based communication: The systems focus on resources, introduces URIs per resource, but still one HTTP verb for communication Level 2- HTTP verbs based communication: The system relies on more HTTP verbs and HTTP response codes on each resource Level 3 - Hypermedia communication: The system leverages Hypermedia As The Engine Of Application State (HATEOAS). These are systems with complete Web characteristics.
Software Development Kit (SDK) No SDK Ad hoc SDK consisting of incomplete libraries, partial documentation and little in the way of examples and test cases SDKs for both providers and consumers accessible to all users including APIs, documentation, examples, test cases SDK is current and is under change and configuration control and updates are released in a timely manner; If appropriate, agency provides test instances for testing access to Mobile APIs
Security Open - Data encryption (in motion, at rest), - Network level security (Gateway, reverse proxy) - Trust/Authentication (Oauth), - Encryption/signing/multi factor, - Authorization (Privileges and access control) - Identity management, - Threat detection/ cybersecurity, - Risk management process- Compliance and enterprise policies


Service Level:
Level of enterprise commitment to the availability and performance of the APIs to the consumers
Incident and problem management:
Maturity of incident and problem mgmt wrt Mobile APIs
Change and configuration management:
Maturity of change and configuration mgmt wrt Mobile APIs
Capacity planning:
Extent to which usage of Mobile APIs is measured

Dimension Name None Basic Intermediate Advanced
Service Level Adhoc, siloed support, no dedicated budget or clear governance Best-effort service level; may be characterized by limited personnel and budget avaiable to managing service levels Published/formal Sevice Level Agreement (SLA) with documented with little or no track record of meeting the SLAs Published/formal Sevice Level Agreement (SLA) with historical metrics meeting or exceeding the SLA
Incident and problem management No incident or problem management Ad hoc incident management limited to trying to restore service after an outage; informal mechanism (eg email) for consumers to report defects Defined incident management process which logs and tracks all incidents to resolution; formal mechanism for consumers to report defects Defined incident and problem management processes that resolve incidents and perform root-cause analysis
Change and configuration management No change or configuration management Mobile APIs under configuration mgmt Changes to Mobile APIs formally approved by change control board Changes to Mobile APIs communicated to and coordinated with all stakeholders
Capacity planning No metrics being captured to support capacity planning No capacity planning; capacity only reviewed after failure due to unsufficent capacity Capacity planning performed on an ad hoc basis using fragmentary usage metrics Usage metrics formally captured and tracked, and used for guiding future development and capacity planning

Level of Adoption

Sharing of APIs:
Extent to which Mobile APIs are documented, shared and discoverable by potential consumers
Implementation maturity:
Level of maturity to support more demanding scenarios and greater levels of adoption
Scope of consumption:
How wide an audience is benefitting from services provided via APIs
Data sharing functionality:
Level of enterprise data sharing allowed via APIs

Dimension Name None Basic Intermediate Advanced
Sharing of APIs Mobile APIs are poorly documented and no effort is made to share them or make them discoverable Mobile APIs are well-documented but are shared in ad hoc ways (eg sending Word document when requested) Enterprise establishes a policy or procedure for publishing Mobile APIs along with establishing a web site or registry that is browseable Mobile APIs are documented, shared and discoverable and are maintained under a change/configuration management
Implementation maturity Mobile APIs have been designed, implemented, tested and secured for use among a small set of agency systems Mobile APIs support broad use across a single agency, component or department, or within a single LoB Mobile APIs are secure for use by external groups but may not operate at ‘web-scale’ Mobile APIs are secure and scaleable to support wide-spread use by numerous government and commercial groups
Scope of consumption Consumption limited to intra enterprise Consumption extends to other government agencies (G2G) Consumption extends to non-government organizations (G2C) Open data, mashups. mobile APIs, programmable web
Data sharing functionality APIs limited to read-only, pre-determined single result sets APIs limited to read-only, query-based result sets APIs support read-write, updatable data access APIs provide transactional, coarse-grained data services

A Project of 18F