Agency Maturity Model
Background
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
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 |
Architecture
Compliance with Standards:
Extent to which standards compliance is coordinated across the enterprise
Technology:
“Richardson Maturity Model for building RESTful APIs ( you can google this. But here is a good description:
http://vpmouttou.wordpress.com/2012/02/08/richardson-maturity-model-rmm-distilled-notes-for-restful-design/)”
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)
Security:
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 |
Management
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 |