Light switches as a metaphor for digital transformation via APIs
APIs are programming interfaces—they abstract in a way that invites users to leverage underlying services. Confused? Well, light switches can help us illuminate what this means in practice.
Nowadays, a light switch is a common user interface that offers a simple control over a vast amount of power. But in 1891, when the White House was just 100 years old, the first electric lights were installed. President Benjamin Harrison and his wife, Caroline, were afraid of getting shocked, so they had their staff turn on and off the lights for them (a human proxy, if you will).
This is so common now that you probably used several switches already today. Each one was likely to have been installed by a professional electrician, because electricity is just as dangerous as it was in 1891. But that kind of work is expensive. And if you get it wrong (like realizing it should have been on another wall), it is hard to change.
Most modern rooms now have at least one built-in light fixture. Need more light? Just place a lamp wherever you need it and plug it into an electrical socket. (In North America, that’s likely a 2-prong or 3-prong interface, but those standards often vary by country.) The trade-off, of course, is that you now have a visible cord.
II.
If you were to walk by my house at night and it was dark, you might guess that no one was home. A vacant house is a higher risk than an occupied one! So when I am away on vacation, I plug a lamp into a light timer and the light timer into the socket. The timer then controls when power gets delivered to the lamp, turning on the light according to a schedule. Now the timer acts as a proxy—it is middle-ware that controls when power gets sent to the lamp. (Just remember to check that the lamp’s switch is set to on, since the local control takes precedence!)
What if you wanted to automate the light at your front door? That fixture is hard-wired to its power source, which means it is harder to schedule than a lamp. In this case, you can upgrade a physical switch to a smart switch to add a network-based interface to the physical one. This means you can send a signal over the network to control the flow of power to the fixture without having to touch the switch directly. This is a digital transformation. Now you could use the digital interface to schedule the lights to come on at sunset and off at sunrise or to simulate presence in your house.
But that’s not all! Now you can control your lights in ways that were not possible before! For example, you can:
Automate: set the on/off schedule around the sunrise in your location
Integrate: connect it to your Google Home or Alexa and use your voice to control it
Extend: add a second switch to the other side of the room without having to physically run a wire to that location (easier, cheaper, and more flexible)
Orchestrate: control multiple lights and/or other devices at once, such as preset scenes that set light levels for dinner or for watching a movie with one command
III.
You might be wondering, "How does this relate to API management and digital transformation?"
An API gateway is like a smart switch for smart switches. Just like Lutron manufactures light switches that an electrician (or moderately competent homeowner) can install, a gateway can standardize and manage the API requests to a service. You do not have to be an expert in APIs or networking to add them.
An electrician already has the skills to install a smart switch, but manufacturers adding “smarts” to switches brought a whole new set of engineering challenges. How can you secure access? Who can manage new business opportunities and partnerships this will bring? How do you improve reliability or responsiveness? How will you on-board developers and support them?
Beyond the technical implementation of managing the API traffic at runtime, how do API providers create API products that package up functionality to meet specific needs of developer-customers and have visibility and control over that on-going relationship?
This is where things get interesting… because while an API is a technical product, it also usually represents an on-going relationship between API consumers and API producers. APIs sit in this sociotechnical space. Technical work must be done to engineer any API—let’s call that the technical contract. Whenever you decide to offer that API to other people to use, that’s the beginning of the social contract. Wrapping the technical contract of an API with a social contract makes it an API product. It begins a relationship between different people in different roles, producer and consumer. (APIs as products will be a recurring theme of Sociotechnical, so watch this space.)
IV.
Epilogue: when an organization has many teams publishing APIs for many other teams to consume, it is likely scaling the impact of the investments it has made in services. Having a thriving internal APIs ecosystem makes it easier to offer external API products that leverage those internal services. Such an organization has thus made significant progress on their digital transformation journey. (Platforms and scaling API programs will be another recurring theme of Sociotechnical.)
This essay is adapted from an earlier version, and it was once published on Substack before things began falling apart there.
Did you enjoy this? If so, then you should subscribe to be sure you don't miss the next one (it is both free and low-traffic).
I love the analogy of everyday objects and APIs.
One that I've used: when I bought my first electric car, I thought about the fact that everything about the way the car produced motion was entirely different than every car I had ever driven. It was a far simpler implementation under the hood (literally). And I loved that.
But what I also loved is that...in many ways (other than the otherworldly quietness and shocking acceleration), it was...just like driving a "normal" car. And the reason: the "API" had remained the same. The interface between the driver and the car (ok, let's call it the DCI) was just like every other (automatic transmission) car I've ever driven. Two pedals, a steering wheel and a gear selector. The gear selector was on the steering column...but I'm old enough to have had one of those before.
It's part of what made it such a successful transition: the implementation had changed, but the API/DCI had remained the same.
One interesting thing is what's hitting Tesla today. They've moved the gear selector to the screen, and they've moved turn signals from a stalk to buttons...in essence, they've made an upgrade with an incompatible API. And they are facing a lot of backlash because of it!