Doing The Hard Work To Define APIs

Two years later, I am still working to define the API driven marketplace that is my digital self. Understanding how I generate revenue from my brand (vomits in mouth a little bit), but also fight off the surveillance capitalists from mining and extracting value from my digital existence. It takes a lot of hard work to define the APIs you depend on to do business, and quantify the digital bits that you are transacting on the open web, amongst partners, and unknowingly with 3rd parties. As an individual, I find this to be a full time job, and within the enterprise, it is something that everyone will have to own a piece of, which in reality, is something that is easier said than done.

Convincing enterprise leadership of the need to be aware of every enterprise capability being defined at the network, system, or application level is a challenge, but doable. Getting consensus on how to do this at scale, across the enterprise will be easier said than done. Identifying how the network, system, and applications across a large organization are being accessed, what schema, messages, and other properties are being exchanged is not a trivial task. It is a massive undertaking to reverse engineer operations, and identify the core capabilities being delivered, then define and document in a coherent way that can be shared with others, and included as part of an organization messaging campaign.

Many will see work to define all enterprise API capabilities as a futile task–something that is impossible to deliver. Many others will not see the value of doing it in the first place, and unable to realize the big picture, they will see defining of APIs and underlying schema as meaningless busy work. Even when you do get folks on-board with the important, having the discipline to see the job through becomes a significant challenge. If moral is low within any organization group, and team members do not have visibility into the overall strategy, the process of defining gears that make the enterprise move forward will be seen as mind numbing accounting work–not something most teams will respond positively about working on.

Once you do define your APIs, you then have to begin investing in defining what the future will hold when it comes to unwinding, evolving, maturing the API infrastructure you are delivering and depending on. This is something that can’t fully move forward until a full or partial accounting of enterprise API capabilities has occurred. If you do not know what is, you will always have trouble defining or controlling what will be. One of the reasons we have so much technical debt is we prefer to focus on what comes next rather than attending to the maintenance required to keep everything clean ,coherent, organized, and well defined. It is always easier to focus on the future, than it is to reconcile with mess we’ve created in the past. This is why it is so easy to sell each wave of enterprise technology solutions, promising to do this work for you–when in reality, most times, you are just laying down the next layer of debt.

Whether it is our personal lives, or our professional worlds, defining the APIs we depend on, as well as the APIs that aren’t useful and become parasitic, as well as the schema objects they produce and exchange is a lot of hard work. Hard work most of us will neglect and outsource for convenience. Making the work become even harder down the road–nobody will care about doing this as we do. The really fascinating part of all of this for me, is that with each cycle of technology that passes through, we keep doubling down on technology being the solution to yesterday’s problem, even though it is the core of yesterday’s problem. In my experience, once you really begin investing in the hard work to define the APIs you depend on, you begin to realize that you don’t need so many of them. That the number of API connections you depend on can actually begin to hurt you, which is something that can wildly grow if you aren’t in tune with what your API landscape consists of in your personal and professional worlds.