Whether an organisation uses APIs to build partnerships with other firms, to break down a monolithic system into a component-based architecture (or even adopts a microservices architecture), they share some common governance challenges. The first is Conway’s Law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." APIs offer the opportunity to forge new communication paths inside and outside the organisation. But this can only happen if the governance structures and processes adapt to guide the firm’s activities towards these goals, while protecting the firm’s operations, assets, their partners and customers.
The Goals of API Governance
Governance should make it easy for people to do the things the right way and hard for people to do things the wrong way. But what is the “right way”? There are some things that are clearly right (e.g. applying a company standard or policy) or clearly wrong (e.g. exposing confidential information such as customer details, regulatory breaches). Others will depend on the organisation, its strategy, adherence to standards, the degree of autonomy it grants its developers, and tolerance for failure. The goals of API governance are to:
- Maximise the value of the partner ecosystem
- Provide guidance to partners and staff on the firm’s priorities
- State the degree of autonomy partners and staff have to innovate
- Protect the firm’s customers and assets (digital, physical and financial) and sensitive information
- Meet customer expectations for transparency, privacy and gaining consent before sharing information with third parties
- Comply with laws and regulations
Governance at the Team Level
Many firms are embracing lean-agile methods to accelerate delivery of new products and services, and foster a culture of customer-focused continuous improvement. The Agile Manifesto’s Principal #11 states: “The best architectures, requirements, and designs emerge from self-organizing teams.” A small, multi-disciplinary, cross-functional team is well placed to take ownership of the API(s) that expose the services they provide. The API is the contract between their service and the consumers of their service. A small team with few APIs can manage their own APIs and their dedicated API Gateway. These are the typical roles and interactions at the team level:
Mid-sized Organisation – Multiple Teams
Governance becomes more complex when an organisation has several teams, delivering different services for different functions or lines of business. They may also have specialised domain knowledge and use different technologies from each other. To promote discovery and re-use of APIs across the firm, a separate API team supporting the API Gateway/API Management Platform can be useful. The API team’s role should not be to create all APIs, as this would create a resource bottleneck, and less autonomy for the development teams, and increase the distance between the development team and their customers. Rather, the API team should act as a catalyst or centre of excellence, helping development teams understand how to expose their services through APIs in a consistent way, and to help other teams and partners discover and consume available APIs.
Roles within the API team include:
API Team Leader
- Engage sponsors, line of business executives, partners, technology team leaders, architects, vendors and other stakeholders, guiding strategy development to ensure that the APIs support and enable both internal and partner capabilities.
- Align the API strategy with the business strategy
- Set priorities for future API development
- Manage team members, helping them develop individual skills and the behaviours of a high-performing team
Engineering
- Lead the technology roadmap, design, development and operations of the API Gateway and API Management Platform
- Ensure the availability, maintenance and operational effectiveness of the API Gateway and API Management Platform
Documentation
- Ensure that API documentation is accurate and complete, and provides the information that API consumers need
- Guide API creators in the creation and maintenance of documentation
Community Manager
- Foster the internal and external developer community
- Co-ordinate both online and in-person information sharing sessions
Developer Evangelist
- The "customer" of a Developer Evangelist is a developer
- Assist developers in the technical aspects of both creating and consuming
- APIs and integrating them into their solutions
- Maintain a deep knowledge of API technologies and best practices
- Explain API technologies and concepts clearly to developers with varying skills and toolsets
In small organisations, API team members may perform several roles. In larger organisations, there may be more than one person performing each role. For API producers, the API team provides guidance in best practice design and development of APIs. They should also oversee the publishing of APIs, either acting as an approval stage-gate (in a centralised model), or (in a decentralised structure) actively monitoring development teams' publishing and updating activities.
To promote the consumption of APIs, the API team should be continually improving the developer experience, enabling self-registration of developers, aiding API discovery, providing a sandbox for developers to try calling APIs, and vetting partners and their cybersecurity capability before granting access to the firm's production APIs.
Large Enterprise
Governance processes in established firms have evolved over time to ensure the integrity and sustainability of a complex array of old and new systems. There may be multiple governance forums with oversight of the enterprise project portfolio, architecture, cybersecurity, and change control over mission-critical production systems. API governance must be compatible with these structures, and help to further evolve the operating model and culture of the organisation.
The trade-offs to consider in selecting the most appropriate governance framework include whether to centralise or decentralise decision-making. Also important is the degree to which teams have the autonomy to determine their own practices and technology tools, and which standards must be common to all teams across the organisation.
Some organisations are attempting to achieve a high degree of decentralisation by adopting a microservices architecture, of which APIs are an enabler. In “Microservices Governance: A Detailed Guide”, Dr. Gopala Krishna Behara compares: “Governance with monoliths are centralized. Decisions are made top-down, rigid control is maintained to ensure standards are in place across the organization and within the application stack. Over time, this model degenerates, creating a stagnant technological and architectural system, thus minimizing innovation……. The core theme of a decentralization governance is the concept of building and running it….. Benefits of a decentralized governance gives Microservices teams the freedom to develop software components using different stacks.”
In “Microservice vs Monolith: Which One to Choose?”, Shamik Mitra argues that, if your team members are experienced and multi-skilled, a microservice “you build it, you run it” approach can work well. If not, a monolithic/modular system may be more sustainable, enabling team members to gain proficiency in a narrower set of skills. Other factors to consider are how the firm’s infrastructure is organised, and the criticality of domain knowledge in a given function.
Lean/agile models such as the Scaled Agile Framework (SAFe) attempt to blend an iterative, build-test-learn approach with structures to ensure integrity across teams. Nevertheless, many organisations still apply a phase-gate waterfall life cycle model for activities impacting their established monolithic systems.
What goes into your API Governance Framework
In “API Governance: Risk and Control Consideration”, Sunil Kuchipudi outlines four categories:
- Strategy: Guidance on the firm’s strategy, objectives, and the principles by which decisions should be made.
- Organisation: Relating the organisational structure to who has decision rights over API prioritisation, creation and publishing, and the roles and responsibilities for API governance.
- Risk Management: How risks and compliance requirements are to be identified, mitigated, controlled or transferred, and how these controls are to be embedded in the firm’s API management practices.
- Sustainability: How the community of API producers and consumers is to be engaged, and how APIs are to be managed throughout their life cycle.
Devising the most appropriate API governance framework requires understanding of your firm’s business strategy, the current organisational structure and culture, and what the organisation wants to move to.