Reusability

In almost every enterprise I walk into, the same capability has been built three, four, five times — by teams who were not being lazy, but who could not find, could not trust, or could not adopt what already existed. Reuse gets treated like a value statement, something you put on a slide and cannot inspect. It is neither. Whether an API can be reused comes down to concrete, checkable things, and whether it is being reused is sitting in your gateway logs right now.

I assess your API estate against a written, weighted rubric across three axes — the design of the interface (can a stranger build against it), the operational anatomy (can they find it, get a key, and try it in a sandbox without a meeting), and its composability (can an agent reuse it as a capability). I run duplication detection across the whole portfolio, semantically, so the same capability hiding under different names surfaces. Then we name your capabilities, map the implementations to each one, and choose canonicals with adoption data in the room — turning “we have sprawl” into decisions your organization can actually make.

The rubric is yours to keep and tune — a governance artifact your teams can score themselves against long after the engagement ends. The method is the same one behind my paper on the subject and the free assessment tool at reusability.apicommons.org, calibrated against hundreds of real public API programs.

What you walk away with

• A scored inventory of your APIs across design, operational, and composability axes
• A duplication map — the same capability under different names, made visible
• A capability map with canonicals chosen on adoption, and a consolidation roadmap
• Your reusability rubric — written, weighted, and published for your teams to run

Related reading

• The Fundamentals of API Reusability (paper)
• reusability.apicommons.org — the free, browser-based assessment tool