5 Ways Your API C4E Can Engage and Enable Teams

When you think of an API Center for Enablement (API C4E), what comes to mind? Perhaps you think of API style guides, API design style selection, and design review processes. While this is a critical element of any API C4E, there is another important aspect that needs to be considered: What are the engagement models that the API C4E will use to enable API producer and consumer teams?”

The role of an API C4E isn’t just about enforcing the rules set forth in various API governance documents. It also includes a variety of engagement models that are necessary to meet teams where they are today and help them to deliver high-quality API designs that meet the needs of end users and API consumers.

Let’s look at five important engagement models that an API C4E can use to enable and empower teams to deliver high-quality, reusable APIs across the organization.

API C4E engagement model #1: Community support

One of the most impactful and least time-consuming engagement models is to engage in API community support. These engagements offer quick turnaround through a question and answer format. Some API programs implement this through Slack or Teams rooms that are open for anyone to join and ask questions. Answers might include directing the person to an example of how a particular design problem was solved by another team. The API C4E representatives can also provide links to standards and practices documents that set expectations and share examples of preferred approaches.

For organizations that have an internal Stack Overflow site, a more discussion-oriented approach to community support can be offered. In this case, not only may the API C4E answer questions but also the API community at large. In some cases, we’ve seen both chat rooms and Stack Overflow used to offer immediate interactions, combined with a frequently asked questions (FAQ) approach for a more self-service approach.

API C4E engagement model #2: Office hours

Not all API-related questions can be answered in a chat session. In those cases, a weekly recurring office hours is made available for people to bring their questions. The API C4E established a consistent day and time for people to join and raise questions, allowing for slightly longer engagements. This format supports screen sharing, allowing a guided walkthrough of the proposed solution and discussion of alternative approaches.

Because the number of attendees may vary week-to-week, interactions are typically limited to 10 or 15 minute discussions. If a single team is the only one raising questions that week, the API C4E may continue to extend the time allocated to the team during office hours. In some cases, more time may be required to dig into the challenge further. That is the purpose of our next engagement model.

API C4E engagement model #3: API design session

An API design session is a one-hour discussion focused on a specific area of a team’s API design challenges. These may be requested using a form-based approach, such as through a ServiceNow workflow, or simply scheduled during office hours as time runs out.

These design sessions may require more than one hour, especially when more context is required to fully understand the problem. In this case, consider booking 90 minutes for the first meeting and a follow-up hour meeting should the team request further discussion.

API C4E engagement model #4: API design review

An API design review is often a mandatory step prior to the release of an API into production. While some aspects of the review may be automated using an API linter, there will still be design elements that a machine cannot review and flag. This is where an API C4E design review engagement model is used to help ensure consistency and that future API consumers will have a good developer experience with the API design and documentation provided by the team.

Teams should be encouraged to create a sequence diagram demonstrating how the API will be used to deliver on the outcomes desired by the identified personas. A README mock-style document, demonstrating HTTP request and response pairs, may be used to provide greater fidelity and convey intent on how an API is meant to be used.

Performing an API design review often takes some up-front work, including the review of any documentation artifacts (e.g., OpenAPI Specification document) prior to the meeting. Therefore, time should be allocated prior to the review meeting, an hour for the review meeting, and another 30 minutes or so to write-up and share recommendations with the team afterward.

A word of caution about API design reviews: API design reviews can either be a positive experience for teams or a negative one. Focus on finding opportunities for improvement and be clear on your expectations of what must be changed prior to a production release. Avoid making the design review a negative experience that causes teams to circumvent processes or share their negative experiences with others in the organization.

API C4E engagement model #5: API design facilitation

The final engagement model we will discuss is API design facilitation. There may be circumstances where teams are either new to API design or perhaps are comprised of mostly offshore teams that lack a deeper understanding of business intent. In these situations, the API C4E may need to faciliate design sessions to guide the team through the process and ensure alignment with business goals.

These “white glove” engagements are demanding and are often applied to high-profile and/or high-priority initiatives that benefit from additional hands-on design guidance. The API C4E should not be expected to faciliate a series of design sessions for every team in the organization.

Investment of time for API C4E engagements

As you may have noticed, different engagement models demand different time investments. The diagram below shows the kind of time investment required for each engagement model:

Not every API C4E will be sufficiently staffed to support all of these engagement models. Start with engagement models that your API C4E can support with time available while offering the best impact to teams. If necessary, you may find that you need to scale your engagement model through the introduction of an API coach program.

Scaling the API C4E engagement model with API coaches

As previously mentioned, the more API C4E engagement models necessary to support your organization, the more time investment is required. Implementing a federated API coaching program offers many benefits for your API C4E:

• Coaches serve as advocate of an API first mindset by guiding teams in more strategic API designs
• API design issues are addressed earlier in the delivery process when the cost of change is lower
• Teams are directed toward API C4E standards, conventions, and guidelines thereby avoiding rework later
• Coaches are able to combine context of the domain area with standards to advise on where deviations to the standards should be applied
• Faster turn-around time for API design review and approval processes
• Institutional memory is better preserved for the domain as API coaches and delivery teams are aligned in understanding of the problem and solution
• API designs are higher quality without wasted time and effort, and over time the cohesion of the API platform and portfolio catalog is improved
• Encourage the creation of reusable APIs within and across domains for partner and internal developer support

If you are struggling to scale your API C4E, consider implementing a federated API coach program in your organization.

---

Need some additional insights into your API C4E engagement models and establishing an API coaching program? LaunchAny partners with organizations of all sizes to establish, scale, and mature their API program. Contact us to find out more.