Three Dimensions of a Software Interface
What are the three dimensions of a software interface?
Visibility is what crosses the boundary: fields, operations, and types. Rigor is how hard the contract is to change. A requirement needs formal governance and stays fixed. A design criterion is an internal constraint the provider team can challenge. Nature is what kind of thing crosses the boundary: a logical relationship, a physical connector such as an endpoint, or a behavioral operation that does a job and returns an outcome. Software teams design as if visibility were the whole problem. An interface designed on visibility alone becomes obsolete when the domain shifts, because nobody set the rigor and nobody distinguished the nature.
How do you revalidate an interface that is still in production?
Unused and useless are different failures. An unused interface has no callers. The article's policy is ninety days for an internal API and one year for an external API, then a flag to the named owner, who either names a reason or schedules deprecation. A useless interface still receives calls, but the calls serve no demand. Automation cannot see that. A periodic audit asks what job the consumer is doing, whether the interface generates revenue, reduces cost, or ensures compliance, and whether any customer would notice if it disappeared. Both the provider and the consumer have to justify keeping it. The only acceptable end is a named reason to live or a date to die.
Get notified when new content drops