It can be tough to know where to start with APIs at your large organization. Everyone is already in motion, in a variety of groups, geographic regions, serving different lines of business. The API conversation is already occurring across your organization, it is just happening in a distributed and fragmented way, without any coherent orchestration, and strategy moving it forward in unison. I’d like to sit down with your team(s), and understand what APIs look like across your organization, and help work through a first draft of your API strategy, and define how we can better orchestrate existing efforts, and begin establishing an API governance framework for bringing the API vision into focus.
Let’s put together a schedule for me to sit down with a variety of teams in a partial day, full day, or multi-day series of workshops. Where we can work to define a more comprehensive, and coherent strategy for APIs. One that is rooted in what is already happening, but works to brig together the disparate voices from each team into a single conversation about how APIs can make change across your organization in a more consistent, and meaningful way. Let’s sit down and begin to define what APIs mean at your organization and map of what is already occurring, and develop framework that will allow us to begin to move things forward.
Define Objectives
I’d like to learn more about the objectives behind your investment in an organization-wide API strategy, and understand more around the motivations, vision behind what you are looking to achieve. I’d like to cut through the hype, and get to the real reasons you want to be doing APIs.
- Internal - What benefits should APIs bring to internal teams within the organization?
- Partner - How will APIs be used to further partner engagements, and maximize their deliverables?
- Public - What can be achieved by performing APIs in the public sphere, and engaging 3rd party developers, and media?
I’d like everyone to bring their stories of how APIs are currently being done within their groups, and how each team sees the future of ther API programs. As well as learning from leadership about what they’d like to achieve by doing APIs in a more coordinated fashion across the organizations and lines of business.
Define Organization
To help move forward the conversation, I’d like to learn more about your organizational structure, and understand the cultural makeup of all groups, individuals, the leadership structures in place–all of which will impact how APIs are realized (or not).
- Groups - What groups will be involved with defining, deploying, managing, and consuming APIs?
- Actors - Who are the different types of actors involved in shaping what APIs look like within your organization.
- Partners - What external partners will immediately impact how APIs are done, and the value they can bring to the table?
Your organizational map will have everything to do with why APIs are working or not working. Your organizational DNA will help define the impact APIs can have internally, as well as externally with partners and the wider public.
Define Architecture
Next, I’d like to get a handle on the architecture that is currently in place across your organization. Understand the current technological makeup of how your organization gets business done on a day to day basis. Learning about how technology is being leveraged to deliver services today, and will continue as part of a wider API strategy.
- Platforms - Which of the major cloud platforms are you operating on?
- Systems - What major systems are in place that drive services today?
- Services - What external services do you currently put to use across operations?
- Tools - What are the open source tools in use across your organization?
I’m looking to understand how web services, APIs, and applications are delivered (and consumed) today. I’d like to learn more about the technical makeup of your organization so that I can better understand the current state of things, and how existing technology can be leveraged to deliver the next generation of APIs.
Define Services
Then, I’d like to paint a landscape picture of APIs across your organization, starting with the past, understanding how you have gotten to where you are today. Identify existing, successful APIs that are in place, while also getting to work on what the future will bring.
- Legacy - What web services are already in place to make things work across organizations?
- Existing - What are the existing APIs already in place which we can use as a blueprint for how APIs should be done?
- Future - I’d like to learn about what the future will hold when it comes to APIs across the organization.
This process can be as high level, or as technical as needed, depending on the different actors we assemble at the table. I’d like to learn about the services in terms of business leadership, as well as the finer technical views–of course, being respectful of the time we have.
Define Lifecycle
With an understanding of the organization, and the existing architecture and services in play, let’s start defining the lifecycle(s) that exists for moving each individual APIs forward, understanding all the stops they’ll pass through from design to deprecation.
- Defining - How are APIs currently defined, from interface to schema?
- Designing - What does API design look like across the organization?
- Mocking - Is virtualization of APIs and data a common practice?
- Documenting - How are APIs documented and detailed for wider usage?
- Clients - What interfaces, SDKs, IDEs, and client tooling are used for API development?
- Deploying - What does the current API build and deploy process look like?
- Managing - What management and gateway layers exist as part of API operations?
- Planning - How are costs and value generation quantified and measured involving APIs?
- Testing - What are the current API monitoring, testing, and performance practices look like?
- Security - How is security defined, evaluated, and responded to across API operations?
- Legal - How do terms of service, privacy policies, licensing, and other regulations get addressed?
- Discovery - How are APIs and services catalogued and discovered throughout operations?
- Support - What does support look like when it comes to the API lifecycle?
- Communications - What is expected around communications across teams for each API?
- Evangelism - How are APIs evangelized internally, and externally amongst partners?
I’m looking to develop an understanding of how the API lifecycle is currently approached, while also discussing what the first draft of the future organizational wide API lifecycle will look like. Something we can put put into action immediately, and begin measuring as part of an overall governance strategy.
Define Governance
We should now have enough to begin talking about how a comprehensive API strategy can be put into place. How individual APIs will be developed and managed, as well as the organizations and actors who will be responsible for their existence. I’d like to talk about how we’ll establish a wider understanding of API operations, measure what is happening, and begin orchestrating its movement in a organized way:
- Mapping - Let’s take the map of the organization, architecture, and lifecycle, and talk about how we’ll turn it into a living map of API operations.
- Measuring - What metrics will we use to measure our progress, and understand how APIs are moving forward throughout the lifecycle in a consistent way.
- Maturity - How do we define maturity throughout API operations, understanding not all APIs will be production ready, and always allowing for innovation.
- Reporting - Let’s discuss how we’ll be reporting on API operations, and communicating with leadership, and across teams about the progress being made.
- Incentives - What are the incentives we can use to help make sure everyone is a team player, and working towards a common goal across the organization?
- Coaching - I’d like to better understand how we can implement an evangelism and coaching strategy as part of the wider API governance execution.
- Auditing - How will we be auditing the API governance strategy, as well as the wider API operations, and understanding where the gaps are?
- Refining - Let’s make sure everyone understands that API governance will require constance refining, and evolving to make it work as expected.
I’d like to understand what API governance means to your organization. Is it more carrot, or more stick. I’d like to understand how a draft governance plan can be put into place immediately, but fully knowing that it will be a living, evolving, and maturing approach to ensuring quality and consistency of delivering APIs at scale across your organization.
Initial, As Well As Ongoing Engagement
Let’s get to work setting up an initial engagement. I’ll leave to you to decide whether it should be a partial, full, or multi day affair. This work to define an API strategy can be invested in at multiple scopes (high level, or in detail), and should continue to live on, expand, and evolve with each engagement. Ideally, it is is something that is worked through with as many teams possible, then repeated as part of a recurring schedule, as time allows. As the map of the organization, the existing architecture and service landscape, lifecycle and governance comes into focus, these working sessions will become even more important, and productive.
I’d like to ask anyone joining the conversation to bring any answers, thoughts, concerns, and questions they have regarding this outline with them. They are welcome to be as high level, or down in the technical weeds as they like–I’ll absorb it all. Ideally, there is a mix of business and technical folks present, with varying levels of leadership in attendance reflecting how API decision making occurs, or will occur across your organization. I’m looking forward to learning more about APIs across your organization, and learning from everyone at the table, while also sharing my knowledge and experience from studying the API sector for the last eight years.
