Successfully applying Application Programming Interfaces (APIs) to support your firm’s business strategy requires a governance framework that balances flexibility with control, in tune with the firm’s culture, processes and risk appetite.
Successfully applying Application Programming Interfaces (APIs) to support your firm’s business strategy requires a governance framework that balances flexibility with control, in tune with the firm’s culture, processes and risk appetite. 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.
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:
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:
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
Engineering
Documentation
Community Manager
Developer Evangelist
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.
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.
In “API Governance: Risk and Control Consideration”, Sunil Kuchipudi outlines four categories:
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.
Jon Scheele formed blue connector with the sole purpose of leveraging digital technologies such as APIs to fast track and enable medium sized and growing businesses to meet their strategic objectives. He helps companies build customer value propositions and streamline processes using Application Programming Interfaces (APIs). Jon's experience spans the Financial Services, Fintech, and Telecommunications industries. He has an MBA, a Bachelor’s degree in Electronic Engineering, and Graduate Diplomas in Applied Finance and Digital Communications.