API-First [Business]

I am working my way through defining a more precise definition of what API-first means which I can use across my API storytelling and conversations. I workshopped the widest definition possible of what API-First means to me yesterday, and be the end of the day I posted another more precise definition of what API-First means to a more technical crowd which I dubbed API-First [Design || Code]. Today, I’m once again thinking more about the business side of the conversation, and focusing on what I would like to eventually be a more precise definition of what API-First means to business stakeholders, which I am dubbing as API-First [Business].

As I said in my broader definition of API-First, if these conversations aren’t including business stakeholders we are doing it wrong. These people are making many of the decisions around the why and how of the desktop, web, mobile, device, and network applications we are delivering on top of our API infrastructure, so we can’t argue that API-First is a developer or technical only concept. We need business stakeholders also thinking API-First, otherwise our projects will never have the resources they need, and are more likely to fall short in meeting real world business objectives. API-First is not a developer concept, it is a concept that business and developer audiences should both be aware of, and then there are separate inner cores to the definition of API-First, one API-First[Design || Code], and the other API-First[Business], which can help bring a more precise definition to the table for each dimension of our operations.

Some Common Business Productivity APIs

To help make this definition a little more real I wanted to actually apply it against a handful of services I am currently working with business stakeholders at Postman. I am working with some very smart technically savvy folks who aren’t programmers to understand how I can help them be more effective and efficient in their daily work. Working together, we’ve come up with a short list of applications in use which also have APIs (cause we don’t adopt services that have APIs, right? right?). 

  • Iterable - Defining marketing automation.
  • Eventbrite - Working across multiple events.
  • JIRA - Staying in tune with engineering.
  • WordPress - Making a bigger impact with blog.
  • Zero Bounce - Being more effective with email.
  • Hunter - Profiling of our customers and audience.
  • Clearbit - Profiling of our customers and audience.
  • FullContact - Profiling of our customers and audience.
  • Google Sheets - Ubiquious data storage and management.

Each of these services have APIs. Each of them are being used in different ways internally at Postman. There are other services in use that also have APIs, but this provides me with a nice sampling of services to think through as part of my API-First [Business] definition. They bring a suite of resources with varying business objectives to help me better understand how I can incentivize business stakeholders to better understand what APIs are, how they can be applied to their work, and of course how Postman can help them do all of this.

The API-First [Business] Definition Dimensions

Next, I want to think about the different dimensions how business users can think about not just APIs, but how they work with each of these services. I am not expecting people to always do APIs, but I am expecting people consider the existence of an API, and have a discussion about how it might be used—first. Here is how I feel like the dimensions of this conversation should be approached, offering up four distinct ways that business users can be thinking about API-First [Business].

Application - When should a business user be using the web or desktop application for a platform?

  • Need to manage account, billing, and core features.
  • Need to accomplish individual tasks without friction.
  • Need to consume existing data, content, and visuals.
  • When functionality only exists within the user interface.
  • When technical or developer resources aren’t available.
  • The application does everything you need it to.

No-Code - When should a business user be looking for a no-code option like IFTTT or Zapier?

  • When a no-code option from a service provider exists.
  • When authorization for an API is available for use by a user.
  • When a feature exists in API, but not in the user interface (UI).
  • When data needs to be accessed from another service.
  • When data needs to be synced from another service.
  • When data needs to be backed up from a service.
  • When bulk data needs to be updated from a service.
  • When orchestration needs be conducted across many services.
  • When actions need to happen on a designated schedule.
  • When actions need to run in response to an event or change.

Low-Code - When should a business user be looking for a low-code option like Postman?

  • When a low-code option from service provider exists.
  • When technical skills are available to implement.
  • When a feature exists in API, but not in the user interface (UI).
  • When authorization for an API is available for use by a user.
  • When data needs to be accessed from another service.
  • When data needs to be synced from another service.
  • When data needs to be backed up from a service.
  • When bulk data needs to be updated from a service.
  • When orchestration needs be conducted across many services.
  • When actions need to happen on a designated schedule.
  • When actions need to run in response to an event or change.

API - When should a business user be looking to use the API for a platform?

  • When an API is available from service being used.
  • When programming skills are available to implement.
  • When feature exists in API, but may not in the user interface (UI).
  • When authorization for an API is available for use by user.
  • When data needs to be accessed from another service.
  • When data needs to be synced from another service.
  • When data needs to be backed up from a service.
  • When bulk data needs to be updated from a service.
  • When orchestration needs be conducted across many services.
  • When actions need to happen on a designated schedule.
  • When actions need to run in response to an event or change.
  • When the complexity of tasks becomes much more complex.

I am sure there are other elements to consider here, but this provides me with a base definition of what API-First [Business] might mean to a business user. Helping folks think about why and when you should be using an application, an API, or other low code or no code opportunities that may exist in the cracks. I wanted to highlight that this isn't just about API vs App, and that the low code / no code movement is building up a pretty strong middle ground for brave tech savvy business users to consider. Crafting a definition of API-First [Business] is fraught with challenges, because as many API developers understand, not all APIs are created equal, and there are plenty of business and political elements at play when it comes to the opportunities that exist between any platforms application and API.

The Business and Politics of APIs

When to use an application or an API is rarely straightforward and consistent. Why a platform has an API, and what features are available in the application or API are usually business and political in nature. Some APIs are more read only, where others allow you to add, update, and delete data. What features are made exclusively available within the application or it's API will vary from platform to platform. All of these characteristics will influence the decisions that a business user will have to make. Developers and business users both will have to navigate these differences between APIs, and have to learn to live with a certain amount of uncertainty, while also working to make informed tactical decisions with confidence when it comes to whether you should use an application, API, or low-code and no-code alternative for your situation.

Including Business Users in the API-First Conversation

I am adamant that API-first isn’t something that should just roll of the lips of technically inclined folks. If business users aren’t equipped to understand why APIs matter, and that they should have a role in their development, then we should just give up on this whole API thing. I am not saying that business users should understand the nuts and bolts of everything that is occurring throughout the API life cycle, but we shouldn’t be hiding things from them, and we should be working hard to regularly educate and equip them with the ability to ask.

  • Before any service or software solution is used or purchased, ask if it has an API first.
  • Before developing a web application, develop an API first.
  • Before developing a mobile application, develop an API first.
  • Before developing a device application, develop an API first.
  • Before you open a ticket with a service provider that the UI can’t do something, look for an API first.
  • Before custom programming a migration between systems, look for an API first.
  • Before manually attempting a bulk process, look for an API first.

If someone at a company, organization, institution, or government agency is going to be in a leadership position involving the development, delivery, operation, sustainment, and support around any desktop, web, mobile, device, or network application, then they should be equipped to ask these questions. They should not be require to understand all the technical details of what is happening, but they should have a seat at the table, be able to ask questions, and be equipped always ask if an effort has considered being API-first.

Why API-First for Business Folks?

It is natural for folks to ask why. APIs are not the solution to every problem, and there are pros and cons to doing APIs, so asking why is essential. There are numerous reasons why business folks should be asking about API-first when starting a new project, or looking to evolve upon an existing application. I’ll keep iterating upon these reasons, but here are a few of the reasons why business should be learning about API-first and injecting it into conversations with other business and technical groups.

  • APIs allow all stakeholders to communicate about what is needed before applications are actually build.
  • APIs will reduce redundancy across multiple types of applications and integrations.
  • APIs will allow for reuse across multiple types of applications and integrations.
  • APIs will allow for increased efficiency across multiple types of applications and integrations.
  • APIs will allow for centralization of observability across applications and integrations.
  • APIs will allow for meeting needs of the known knowns, known unknowns, and help address unknown unknowns.
  • APIs the same reasons as for technical folks, but a few more things to consider.
  • APIs in some cases will allow you to bypass the need for more technical stakeholders.
  • User interfaces are meant for narrow audiences and APIs cater to as wide as possible audience.
  • The more eyeballs on the pipes behind the applications we depend on the better.
  • Help demystify API technology, and force technical stakeholders to simply and make more accessible.

As you can see, this really isn’t about API. It is about people, communication, and planning. APIs are just a convenient vehicle for introducing healthier approaches to these areas, and better define the human-machine relationship that exists throughout our personal and professional lives. APIs aren’t purely technical. They also have the human meaning and behavioral outcomes coded into their endpoints. APIs are both human and machine readable when they are designed well. This reflects the API-first mandate. APIs aren’t new. Really, the most recent innovation in the development and delivery of APIs that has made a significant impact in how business gets done using APIs, is that they have become simpler, and more accessible to non-developers. Invoking more conversations around the business value of doing APIs, which honestly is the primary driver of why we are not just doing APIs, but also the desktop, web, mobile, device, and network applications that use them.

API-First Needs To Be More Inclusive

API-first is important. Not because of some un-defined, superficial way of thinking about technology. API-first is important because it causes us to pause for a moment and think about the bigger picture. Who should be involved. What types of applications are going to need access to this data, content, and algorithms in the near or longer term future. API-first forces us technologists to tap the breaks before diving in, which is one of the reasons us developers are resisting API-first so much. We just want to dive in and get coding, without much thought to the long term consequences, or the unintended side effects. Someone else will have to deal with those consequences. API-first won’t solve all of the challenges we face in the technology sector, and the business sectors who find themselves delivering more technology, but they can help us be more thoughtful and inclusive in how we deliver technology, while also allowing us to move faster, be more agile, nimble, and flexible when it comes to operating in a digital world.

This post helps me further round off my big tent definition for API-First, but it also allows me to address the more precise API-First [Design || Code], and API-First [Business] dimensions of the conversation. I don’t think I’ve answered everything about what API-First means, but I do feel like I’ve put myself on firmer ground when it comes to implementing API-First in a more meaningful way across projects, and speak more precisely in my online and offline storytelling. I’d say that my definitions are still pretty verbose and need a lot more refinement to make it more accessible by developer and business users. Ultimately I am looking to establish a one pager that anyone can look at and use to help them make more informed decisions about engaging in an API-First conversation within their organization. Helping set the ground rules for what people are talking about when they say API-First, helping bring more alignment to teams when it comes to moving the conversation forward.