I am back to my work to precisely define how we integrate with many different APIs. With this round I am doing it for a handful of use cases meant to satisfy customer conversations around their AI integration needs. If you’ve been tuned into my newsletter than you’ll know that I am wrestling with defining these conversations in the context of a capability. Not an API capability, but just a capability that describes something we need to be capable of when it comes to our businesses. As part of this work I am aggregating many voices from stories I’ve read online, but also podcast episodes I am producing as part of this work. Across these stories I regularly hear how a capability is a wrapper for everything you need to integrate with AI—something that like AI, often seems pretty hand wavy.
Everyone I am talking with is someone willing to do the work to define the technical details of what a capability is, but I don’t think everyone is willing to do the work to define the business details of what a capability is. I don’t think this is any nefarious act—it is just that we aren’t used to prioritizing these things in engineering circles. In my experience, the engineering folks who I sit down to define all of the technical details aren’t always equipped or willing to sit down and go through the business details. The same is on the other side of things, and the business folks who I sit down to define all the business details aren’t always equipped or willing to sit down and go through all the technical details. With the folks willing and able to do work on both sides being a very rare beast.
The result is that you encounter people on both sides who are on board with the concept of a capability helping define the future of integrations as they are needed to drive our businesses, but things get pretty hand wavy about the details of what that means, and there is very little connecting of the dots across the business and engineering landscape. I’d say the technical details get the lion share of work, and the business details just being left unspecified, or not connected with the technical details—resulting in drift down the road. You often just end up with two distinct sets of specifications, that may or may not be connected, but as the road map rolls forward, this disconnect becomes greater over time, resulting in much of the friction and pain associated with legacy systems.
The concept of a capability is pretty powerful for bridging these two worlds. You can define, educate, govern, and align across what the two groups want. It also lets you set the context window for not just aligning with AI applications, but any application, as well as the human coordination, communication, and collaboration required to make this work. Capabilities exist within a domain, which has a well-defined vocabulary for tagging and organizing everything into meaningful boundaries. Capabilities have a well-defined set of services that are being used—including the business and technical details of these services. This alone, will help reduce the “everything you need to integrate with AI” to something that is manageable and communicated across the business and engineering groups, but also with the non-human interactions that are increasingly required to do business.
