I was publishing the Naftiko Capabilities I had generated from the 36 Palo Alto Networks OpenAPIs. Before I generated these capabilities I generated a standardized set of Spectral rules based upon the most common patterns present across Palo Alto Networks APIs. After generating the capabilities, I realized that the capabilities were still oriented based upon how APIs are defined and organized by Palo Alto Networks, and opted to group them based upon how the capabilities would be applied.
The OpenAPIs I harvested from Palo Alto Networks reflect the lines of business and historic tribal boundaries in which these APIs came to life, and not how they would be used. I think this is one of the greatest sins of the API producer mindset. The design and usage of APIs should reflect how they are going to be used by consumers, and not based upon how they were developed and brought to life. This is what the next wave of API investment will need to focus on—how an API will be used in a business workflow or process. It isn’t that complicated, but it is something that seems to be very, very, very difficult for many API providers who are in the weeds.
Realigning the organization of how we organize and make our APIs available is just the beginning, using Naftiko we can also completely redesign the APIs to meet the needs of whatever the business outcome is for the capabilities being produced. I reorganized and redesigned the Palo Alto Network APIs with what their consumers might want based upon what Palo Alto Networks offers. This is something that can dramatically reengineered from a context perspective based upon the addition of new APIs from beyond what Palo Alto Network, further considering what the overall business outcome and experience in which consumers are expecting.
I know the limitations of the ways in which I’ve reorganized the Palo Network APIs as capabilities. I also know the possibilities for reorganizing when I bring in more additional context from those who are building on top of Palo Alto Networks. What other APIs live within those everyday workflows? I have long used OpenAPI and APIs.json tags to organize things, but it was always from an engineering perspective. Capabilities force things into the business realm. Reorganizing the Palo Alto Networks capabilities has allowed members to associate with a persona and begin thinking more deeply about the experience. This feels like where the next of investment will need to be made when it comes to API, but also AI, ensuring the experience always steers towards business outcomes.
