API series - Axway: The 'API Guild' operationalises us towards API-first
This is a guest post for the Computer Weekly Developer Network written by Brian Otten in his role as VP of the digital transformation catalysts division at Axway – a company known for its enterprise software capabilities spanning API management, mobile application development and enterprise application integration functions.
Developers have of course heard of API lifecycle management – okay then, so now, how do you (we, or they) operationalise it?
Axway knows a thing or two about this process.
Reminding us that by now APIs are becoming prolific, Otten says that most organisations have now caught the wave of using APIs to provide flexible connectivity between systems making it easy for developers to get started and build digital products.
So what happens next on the road to API operationalisation?
Otten writes as follows…
Over and above the content noted above, as developers and software engineers of all disciplines, your organisation may even have discovered (perhaps through experimentation) that API delivery has a distinct lifecycle that includes but is not limited to: unified monitoring of APIs from a security, availability and performance perspective – plus also, capabilities focused on cataloguing and managing APIs on a day-to-day basis alongside controls related to standards, governance and testing.
Think about the total API management lifecycle as a set of realistic pipelines of operational activity that can be split into the following groups – Business Operations – Product Operations – Platform Operations (including DevOps and InfraSecOps).
But even with an understanding of the full API management lifecycle, how can your organisation go further and operationalise API delivery to sustain success?
Local leaders & a federated team
You need local leaders and a federated team dedicated to the adoption of APIs at scale
Utilising an API strategy at an enterprise scale needs more than a Community of Practice (CoP). A CoP is effective in introducing transformational technologies like API management but, they do not have a way to ensure they’re ‘operationalised’, especially with a ‘full lifecycle’ approach that starts from the stages of Demand and Ideation all the way to Promotion and Adoption.
Enter the API guild. An API guild is formed of API lead team representatives from all capability areas of the business. This acts as a springboard to embedding the practices of API as a product leading to true API product managers. Having this system in place ensures ownership, accountability, and the reuse of composable building blocks, helping organisations deliver more in less time.
The API guild has a charter that helps to address the challenges of API adoption:
a) The ownership of APIs is moved as close to the business as possible to alleviate the bottleneck of DAI owning all APIs.
Axway’s Otten: An ‘API guild’ can be the flag-bearer of an API-first cultural change,
b) The implementation of education and alignment to prove the benefits of going ‘beyond integration’ and getting teams to treat APIs as business capability assets rather than just integration components. This works to prevent duplication of effort and ‘point-to-point’ solutions which are difficult to reuse and take advantage of by citizen integrators who rely on specific data and capabilities.
The API guild together with the lead team model provides a framework for initiatives requiring shared budgets enabling them to tactically deliver whilst linking to the wider enterprise strategy for API enablement.
Are APIs products, code or both?
There are many questions to ask here. Should APIs be viewed as products or code? Should APIs be chargeable (similar to the way a payment processor works to charge every transaction)? How would this work long-term in terms of maintainability? How will programmers handle dependencies downstream?
In order to answer these questions, it’s essential to mention the strategic move to API-first. This is an approach that allows both business and technology collaborators to reimagine their business and envision the digital assets supporting key initiatives as sets of working APIs. This is a cultural shift from the traditional focus on features and functions in applications and data management.
The API guild (as described above) can be the flag-bearer of an API-first cultural change, fostering collaboration between those defining the value propositions of what digital products are to be built. Great products are all about creating a design that addresses consumer needs, and encouraging communication can help businesses work with this in mind.
This is where the integration of an API design-first approach into the API lifecycle can mitigate the risks of a code-first approach. The code-first approach runs the risk of missing key business documentation, not taking a consumer-focused design and the inevitable time-intensive translation layers teams encounter.
By encouraging better management and communication, teams can work with a common understanding of the product needing to be delivered and ensure that the consumer’s needs are addressed.