Just before I decided to go out on my own as a consultant, I worked for PSDI, maker of the popular Maximo software product. For the uninitiated, Maximo is the gold standard for enterprises asset management. Sexy right? No? Yeah, I get it, but it is one of those things you may never know about that helps keep your lights on at night.
The dawning of the age of mobile computing
Previous tech companies I worked for valued their customers, but working on the Maximo team was a joy because they practically insisted we talk to customers and seek their feedback for new features and improvements.
For some reason, the head of R&D took a liking to me, and we did some bleeding-edge work that would seem mundane in today’s world. For example, we saw the Palm Pilot (look it up) as the spark that would light the fire for a mobile-first workforce. We envisioned a world where crews could complete their work and get new work orders without placing phone calls or large hotels getting real-time updates when rooms have been serviced and ready for occupancy.
PSDI was on the bleeding edge of client-server computing. That is, the software had a Java-based frontend (client), and a database backend (server). In my previous tech jobs, databases were closed and usually stored right on the computer running the software.
Back to the Palm Pilot, we learned that writing mobile applications was harder than it looked. For example, it was black and white (well, more green and gray), had a small amount of space to work with, and was difficult to use when searching for information or writing up long notes. Many of our customers used color coding to show critical jobs, or display large images, so we had to figure out new and unique ways to visualize this information. Color coding was replaced with icons; full-size images were preprocessed as scaled grayscale images, and long text boxes were replaced with pre-written items in a pick list.
We had other challenges too, like the Palm Pilot accessing the database. There was no guarantee the Palm Pilot would always be connected to a network. That meant we often re-created mini versions of the screens and business logic that would work on the Palm Pilot. Of course, that same business logic would also exist in the full-screen client. As we continued to play around with this technology, developers and product managers realized we had to maintain two sets of screens and business logic, making it more difficult to create and test code.
Get the logic out of those screens
Some product features overlapped. For example, two different modules might create purchase orders to, say, replace equipment or purchase supplies. Since all our business logic was locked up in screens, one module might create an invoice following a set of business rules, and another screen would follow a slightly different set of business rules. Our product managers and developers tried to make sure all the code and business logic matched, but we are humans and mistakes were made. They also knew things were going to get worse with new screens for mobile and the growing number of product features.
The product team had the foresight to recognize that we had to stop writing business logic in the screens. We decided to begin the process of quite literally rewriting the application to create reusable, object-oriented code (later, we would call it 3-tier or n-tier computing).
I was not there for the whole process, but I remember sitting in the room with the product manager leading the effort. He handed us all worksheet templates that we had to fill out for our respective modules. The worksheet would quite literally have us write up the minimum inputs and outputs for each action a user would take (create a work order, process an invoice, etc.) We would then write down the business logic so the developers could build a shared code base.
In all honesty, I understood why a unified code base was important, but not necessary. Why not just fix existing overlapped code? Why do we need to invest in re-writing the whole application when we could be adding new functionality?
One day, out of the blue, the senior executives called a meeting to share that they purchased a company called Ariba. The executives envisioned a world where they would provide a marketplace for vendors to sell their products directly to enterprise customers. Part of that vision meant Maximo would orchestrate those purchases with SAP, PeopleSoft, and other enterprise applications.
Enter APIs
It was not until I moved on from PSDI that I came to realize just how forward-looking the company was. If they wanted to be the hub for materials procurement, then they needed to integrate with any software at any company. Just as much as they were creating a marketplace, they were building an application programming interface (or API). The ability for developers to quickly write software interfaces and open their product up to a marketplace of providers was a truly ingenious idea, and they knew it would have to work for a whole new set of developers that may not be familiar with their product.
Fast-forward to today, and the term cloud-computing is almost synonymous with the term serverless computing. The concept of serverless computing is that you build small bits of business logic once and reuse them.
Ultimately, those little bits of business logic are just APIs that orchestrate the business logic for an application. Many of the popular apps you use on your phone today are small programs that call APIs from the cloud. The bulk of the download on your phone is code to make the app look pretty and store information locally for when you are not connected to a network.
For example, when you open your banking app, it will make an API call to confirm your identity. Another API call lists all the things you can do (pay a bill, transfer money, etc.) When you go to another screen to look at your deposits, yet another API call transmits the list of transactions.
While websites and software companies use APIs to make it easier for developers to extend functionality or use the product, new businesses are forming to monetize APIs. For example, when you receive a text message from your bank or call an airline and have to answer a few questions, you may be interacting with APIs from a company called Twilio. Governments are even looking to create APIs that unlock data for companies willing to pay for access. You could easily imagine weather data, zoning information, and other information made available for real-time access through APIs for a fee.
Enter API-driven programming.
Monetizing APIs with Postman
If you want to write a brand-new application today, there is a good chance you will start by creating APIs. However, designing, documenting, and testing APIs can be tricky with traditional integrated development environments (IDEs).
Enter Postman, a wildly popular API development environment (or ADE), that lets you mock, test, build, document, and share your APIs. I recently had an opportunity to speak with the CEO and founder, Abhinav Asthana. In today’s T-Suite Podcast, we talk about the monetization of APIs, as well as talk about the past, present, and future of APIs.
