Building an API is a Joint Venture of Tech and Business

Last Update: 09.11.2017. By Jens in APIs | API Business

APIs have gone a long way from a purely technical thing to now being a core business. Many businesses depend so much on their APIs that they would go out of business when the APIs fail. But whos responsible for building and maintaining?

That is a hard question, and the answer you get depends on who you ask. Some say, it is a tech thing, and “I don’t care”, others think it is the business, and the devs are just the hands building it.

If you ask me, I’d say they are both right and wrong. I believe that tech and business must work together and share the responsibility but also the wins. Let me show you how I came to that conclusion.

I’ve been working for almost two decades in the industry now and have seen a few pitfalls which are repeated over and over again. It doesn’t matter if big or small companies. But let’s illustrate that a bit.

SmallMegaCorp Press is a magazine publisher, and they decided to build an API to give access to the content for their corporate customers. Bob is the guy in charge of the business and Alice is responsible for developing the API.

The worst thing Bob can do now is to go to Alice and say “We need an API for getting our content”. And guess what the worst thing Alice can do now is, saying “Sure, I’ll have it by Monday”.

I know that sounds a bit exaggerated, but it actually happens with a bit of back and fore added of course. Sometimes these situations go so far that Bob tells Alice to call the dev of a customers shop and ask what they want and then just do it.

Usually, such an API will be painful for everyone involved. Even to the tenth client trying to adapt the SmallMegaCorp Press API. Bob and Alice get depressive and might quit over time. And the customers complain and if they have a choice will move somewhere else.

So, the first pitfall is APIs are tech so don’t bother me with it. Yes, they are tech, and they are not. Behind every API is at least one business case; it is tech and business.

Now, Bob did quit and was replaced by Andrew. He’s the new guy, has no clue of the business and no clue of the API. As Bob left no traces of why the API is as is, Andrew must assume it is doing fine. When now one of their customer requests a change because they need some additional information to solve one of their business cases, he will do so without question. That’s the first step of a form of feature creep.

When Alice wants to remove a field for cleaning up the API later, Andrew will get nervous and block the wish. He does not know the purpose of individual parts and is reluctant to change. A customer might need it; doesn’t matter if real or not.

The second pitfall is the business responsible does not know the use cases, neither theirs nor customers. It’s like driving blindfolded on a German Autobahn at 180km/h.

Let’s rewind and assume Bob and Andrew both take their role serious but with the slight change that they have no power in making any decision regarding the API. It doesn’t really matter if it’s Bob or Andrew because they are both screwed. When Andrew and Alice decide to put the API on a diet to turn it for the better, they still can’t do it. They’d need approval. And there is always something with higher priority than the API nobody likes and cares about.

If Bob had done that in the first place he might still screw up because of lack of power. It had depended a lot on his boss and their relationship.

How hard each pitfall affects your business depends on a few additional factors. There’s for one, the experience the participants have in their field; a mediocre dev can still screw your API with a perfect business case. On the contrary, an experienced dev can build you an excellent technical API but if your business sucks, the overall result will suck.

Another is the experience or understanding of the participants of the domain of the others. When your dev knows your business, industry, etc. and can talk business to you, it is a plus. Same goes for business people having enough understanding of techs so they can discuss better with devs.

The corporate culture also plays a huge role. When it is allowed to take action and to fail, then people are more eager to try something out, and they usually do their best to succeed.

And the last factor is you. Whatever your role is in this, do your best and grow better.

Conclusion

The three pitfalls I’ve shown you are real and I’ve seen them all in action; sometimes alone and sometimes together. However, a single one might not be deadly for your API, but they suck the life nonetheless out of every party and the money out of your company. When you accept that tech and business must work together, you are already way better than your competitor. When you act respecting the factors, I mentioned above, you are on a great way to build a for you successful API.

Need assistance? Contact me and let’s chat.