Why SaaS and On-Prem Software Providers Should Think API-First

Software is great — you write it once, and it just keeps on working forever with no changes. Except, of course, this is not true. It's always evolving, getting new features, and serving new audiences. The promise of software and the reason there are so many businesses built around it is that you can continue to solve your problems in the right way, by upgrading. Upgrade your software a couple times, though, and all of a sudden you have a legacy product.

Complicating things is the looming realization that "the right way" is a moving target. Build it right today, and in a year, or maybe even just months, it's not quite the right way any more. Imagine you're in that spot, looking back. Perhaps a familiar spot for those of you who have participated in a pre-mortem brainstorming session. What changes should you consider right now that will make getting to the new right way of doing things a bit easier?

Here are a few key API strategies for on-prem and SaaS software providers that, thoughtfully executed, will enable your API users to be creative, empower them to customize their own experience, and maybe even encourage them to engage and share their experiences with you.

Creativity Enabled Through APIs

The world of on-premises software is a very flexible place. Customers buy your software, install it on their hardware, and then pay someone, probably also you, to make everything behave exactly how they've imagined it should. This assumes the software is configurable and extensible enough so its behavior can be thoroughly customized. In this scenario, each and every client can have their own environment that operates exactly the way they want it to since they control every detail.

On-premises software products tend to have lower-level APIs, such as a module system, which allows customers to plug their own code directly into hook points that modify the runtime behavior of the software. They may also have remotely accessible APIs to ease integration with other systems. In many cases, just the fact that some sort of API exists makes the system flexible enough to meet customers' needs.

A successful Software-as-a-Service (SaaS) business looks very different from a successful on-premises software business. Instead of each one of your customers managing their own environment individually, suddenly you're responsible for building and maintaining healthy environments that each and every one of your customers can use. At that scale, managing, let alone keeping track of the sorts of customizations described above becomes a mountain of work. And we haven't mentioned testing or upgrading at all.

Thankfully, there is a better way to herd those cats than pulling customizations into your product and opening up remote access to a module API. Remotely accessible APIs are the norm for services — no surprise there. However, making sure the API is structured so it leaves enough room for customers to be creative is important too. One good way to do this is by making the components of your API composable, similar to building blocks.

With this approach, many of the same sorts of customizations available with individually managed environments are also available in the SaaS model. Does each customer want dynamically adjusting rules based on their favorite combination of system metrics? They can achieve that by hitting a metrics API endpoint and using custom logic in their client to decide, based on the metrics result, which action they'd like to take. These sorts of dynamic customizations — examples to get your customers' creative juices flowing, at least — could even be built into a client library as a proof of concept. Stay tuned for more ideas about client libraries.

Customer Empowerment Using APIs

Software businesses and services exist because they want to scale successfully, which usually means "get lots of paying customers." As mentioned, doing custom things on the server, or even doing small support tasks for every customer, eats a lot of time as the total number of accounts increases. Time is expensive, so empowering your users isn't just an idealistic goal, it's good for the bottom line.

The usual approach is to customize each user's experience with account settings, user-level settings, or both. This is a good way to go for a couple of reasons. The first is that it empowers customers to control their own destiny. Each time one of your customers is able to customize her own experience without having to file a support ticket or call you up on the phone, you've achieved a resounding success that should not be downplayed. If you can figure out how to quantify and measure those sorts of events, they can help put things like support ticket volume in context.

However, your users can't change settings if they aren't user-modifiable. API-driven development is a relevant concept here, which basically means that your API should have at least as many features as your UI, and if something is editable in the UI, it should also be editable via API.

Not every user will want to use your API to change their time zone or their notification preferences. Having that capability makes things possible that would otherwise be more difficult, like supporting service providers who want to automate getting their own customers set up on your service, or creating standalone applications that run outside of the browser, whether targeted at desktop or mobile. In the extreme case, resellers or particularly picky customers could build their own user interface. And all of these things are possibilities because APIs increase your agility as a business.

Community Engagement Around APIs

The flip side of empowerment means your customers won't need to talk to you as much. While that's certainly less expensive when measured in some ways and more efficient in others, having ways to engage with your customers is important. How else will you figure out what they want? It's not as useful to say "Our users love us!" if you're actually just guessing.

One very effective, although still indirect way to get information about what your users want is via open source client libraries. Adding a custom user agent to each client library you make available will help determine which programming languages are the most popular with your customers. This information helps in several areas. It indicates which library should receive the most attention, and it can give insight into the types of events or meetups that may be ripe for sponsorship opportunities. Meetups, events, and client libraries have also doubled as recruiting tools.

Don't be afraid to ask for feedback. Events are an easy way to do this, although not the only way, or even the easiest. Many services are out there that enable anonymous surveys, and you can ask users to include their contact information if they're interested in having a conversation instead of only sharing their comments.

Use your own API. If you and your co-workers don't engage with it, you won't be able to identify with customers as well or help them fix issues quite as effectively. Switching things up and using your service like a customer is a great exercise in empathy. The feedback you get from your co-workers will likely come from multiple perspectives and from those with diverse work backgrounds. It can help to improve documentation, as long as that feedback is captured. Engineers learning how to explain complex problems more simply is good for everyone, whether it's to educate their co-workers or customers.

Lastly, "API First"

Building on all of that, I hope you have some new ideas for how to use and perhaps improve your APIs. Think about how to end up with a system that will allow doing things you haven't thought of yet, because that's how your customers will want to use it. The general pattern will likely be that configuration should migrate from global settings to tenant-level ones, and custom code for each account won't run on the servers you operate. With an API that's designed to be composable, custom code can move into the client. Avoid the trap of the echo chamber, solicit feedback from your users in any way you can. And don't forget to have fun.

David Gray Dave Gray is a Principal Software Engineer at SparkPost (www.sparkpost.com). Throughout his 18-year career, he has had roles in Engineering and Professional Services, working directly with customers, and is currently assisting the Growth team on initiatives to impact and increase interaction with customers. Dave came to SparkPost from the automated publishing industry, where he helped customers increase their agility, since delays could end up grounding fleets of aircraft, until manuals could be updated. Making customers and co-workers more efficient is Dave's focus and passion, and enabling them to be proactive through tools and APIs is a key part of that. You can follow Dave on Twitter @yargevad and via SparkPost @sparkpost or connect with him on LinkedIn https://www.linkedin.com/in/yargevad

Comments