If, like me, you’re old school when it comes to books, new bookshops can be confusing. Every layout is similar-but-different. Are all the best sellers together, or separated by fiction and non-fiction? Travel writing by author, or mixed with maps and guidebooks and ordered by geography? Back home, do you sort by the physical (size, weight), the referenceable (topic, author, age), the aesthetic (colour) or the priority (read or unread)? Of course it’s highly personal, but depends on the questions. What fits on the shelf? What to read next? Where can find it again?
When one's environment has changed, and the way ahead looks different, it may be time to think differently about visualising the order of things, and knowing where you are in that order. If you’re feeling your API agenda needs more traction, maybe it’s time to re-frame your role as you update your API priorities and plans.
Interpretation at the business/IT interface: hand-hold or hand-off?
Typically, we focus on getting attention and support from the people who we view will commit to investment. Inevitably, business cases are often still the way most people think about justifying and mobilising IT-related projects. This project-based approach is often pervasive in early-stage API maturity at organisations where progress relies on roles we can think of as interpreters. They may include analysts, project managers or sponsor delegates: people who rely on their proficiency in the traditional languages of business and IT.
Early on, they may treat APIs as "just a different kind of interface"; as components within broader IT project delivery as opposed to underpinning an enterprise shift in thinking. At best they hand-hold the interpretation with written translation: clarifying points and providing additional context for both sponsors and technologists. At worst, they unintentionally become delivery bottlenecks; creating unnecessary hand-offs or add risk to API thinking getting lost in translation.
Interpreters can create unintended hand-offs during delivery.
Interpreters can find themselves burdened with the hard work of getting APIs understood. However, they lack the sponsor’s clout and resources, and the technologist’s design and delivery capabilities. Interpreters risk having their time taken up trying to influence other parts of the organisation to support investment, or micro-managing tasks to IT-as-order-takers instead of fostering creativity and continuous learning.
Meanwhile, both sponsors and technologists can feel they lack visibility of real progress. On the one hand they’re looking to realise an ecosystem or platform play, on the other they're wanting to accelerate API take-up internally to make it easier to get IT change done.
So how can one reframe key actors in this space, to have better conversations and take clearer actions around APIs? Actions that will accelerate API-enabled outcomes while bedding down more of the cultural behaviours and delivery disciplines that will complement broader digital transformation.
Re-thinking API stakeholders
Firstly, reclassifying API stakeholders is not about organisational restructuring. Certainly effective API strategies can call for different ways of working, different funding and operating models, and different skills and capabilities. However, much can be done with the right mindset and the right priorities.
One can consider three types of people who need to work together to get an API strategy executed successfully: sponsors, transformers and technologists.
Sponsors are effectively the elders of the API community: they represent the group we typically recognise as executives and transformation leaders. They understand the organisation’s culture and heritage and collectively set strategy and overall direction. They have the resources (finances, human capital and facilities) together with the standing and influence beyond their immediate teams, to remove roadblocks while setting realistic settings for delivery risk appetite.
API-related sponsors are not necessarily defined by role title or seniority. They can come from product line or customer group leadership; from functions with traditionally heavy packaged-based system reliance such as HR, procurement or finance; or from areas of growing data needs such as marketing or supply chain optimisation. Most importantly, they understand the potential for APIs as part of their future business model and can articulate this to their peers and teams.
Transformers are more like API explorers who hold, say, innovation or change enablement roles transforming the business. They might include API product managers and associated teams, looking ahead and outward at emerging business models and customer opportunities. They typically lead experiments in new ways of doing things and prove them with customer testing and new design experiences; with new products and use of analytics.
Transformers have deep understanding of the strategic potential from API-enabled change and understand their key technical characteristics and behaviours and the propositions they offer developer communities, including those beyond their organisation. They don’t necessarily have a set level of seniority within the organisation’s structure or hierarchy, but they typically deeply understand--or at least can tap into and quickly synthesise--the business day-to-day operations and customer expectations.
Technologists act as API navigators within and beyond the enterprise. They provide sponsors with trusted guidance for ways through difficult technical seas and terrains and can explain the consequence of new and emerging risks. They have access to, and detailed understanding of, historical and current API-related explorations and discoveries. They keep maps and charts up-to-date and usable--as API developer portals and lifecycle management systems--for both themselves and future explorers who come from both within and beyond the current realm of reference.
At the risk of over-simplification, sponsors are mostly involved in articulating the why for APIs such as enabling a platform or ecosystem strategy. Transformers are most active in what APIs are the highest priority to build and what they will look like for external and internal developers, while technologists mostly work on how APIs will be accessed, curated, executed, maintained and governed.
Common goals, local objectives
If your primary role includes propagating an organisational API mindset, first ask yourself where you spend most of your time: as an elder, exploring or navigating. How about your other stakeholders? When you (re)evaluate the value APIs brings to each group, you build up a picture of your organisation's maturity. With understanding of what else is going on for these stakeholders, you can then work on what will best help and influence each group and where they align.
The continuous flow of resources and quality of dialogue between each group as they build API strength and experience sets the tone for broader digital transformation agenda items. Answering these questions for APIs shines a light on other key technology enablers for transformation such as cross-functional teams, new engineering disciplines or scaled agile delivery practices.
The key is how each group recognises the API goals, strengths and challenges for the other two, and how they solve problems at the intersections to move the collective organisation forward as one.
All three groups expect to share a common API mindset; to be aligned around overall API direction/strategies; and to adopt pervasive common API design and delivery practices.
Balancing healthy tension
This way of looking at API actors in an organisation also questions how balanced your API efforts and attention are across each of the three groups. Moreover, what level of conversation is going on at the intersection between each of them?
As an example, you may be a technologist with API lifecycle management tooling and a functional developer portal in place. However, a lot of API design and development work is happening outside your gateway risking unnecessary API duplication and future maintenance problems from technical debt. Rather than focusing your efforts on putting in place a wide mandate for future projects to adopt your solutions, you could pivot focus to tracking developer adoption metrics. You could work with transformers to showcase the speed of new developer onboarding with facts and stories demonstrating how much easier it is for them than “going alone”.
Or perhaps, your burgeoning portfolio of APIs is now at risk of creating its own legacy technology problems as consistency and design quality falls off and you can’t keep pace with the demand for designers. You might reprioritise your asks of help from sponsors towards upskilling and mentoring teams with the right blend of customer/business knowhow and technical discipline; and lower the priority for funding into new API tooling.
Know your community
In summary, the way forward will be specific to the situation in each organisation. Rethinking the underlying assumptions behind your API strategy may be high on your agenda at the moment. Meanwhile, reframing the roles of your own team and other key API stakeholders, and how their roles balance and interact could be today's change management and communication exercise that gives you and your teams fresh momentum and energy. So, during a period of reflection and regrouping, it may be time to clean out and rearrange your bookshelves for a fresh perspective.
Claire is based in the UK helping organisations with making their IT- and API-enabled strategies happen. All opinions provided in this article are her own.