We design for the human experience of your customers by applying three modern data architecture principles.  

Common Vocabulary

A common vocabulary for API teams to use when designing APIs. Your "data model."

For example, if your business spans three industries of x-y-z, you should have three common vocabularies within collections of /x, /y, and /z. Then employ guidelines with enough logic that allow your common vocabularies to scale across global teams and collections in step 1-2-3.

Shared Assets

Shared assets for API teams to use for design and deployment. Your "common" data libraries.

For APIs, we mean common data libraries. There will never be a manually-maintained, singular data model that scales across all industries within an enterprise. For example, a hotels API would have "checkin_date" whereas a cars API would have "pickup_date." These collections should be managed by your API development teams within that industry.

Standard Interfaces

Standard interfaces for API teams to use for their specifications. For a consistent developer portal experience.

For APIs, we mean documentation/specifications with fill-in-the-blank {x,y,z}. There's nothing your developer customers like more than spending more than 60 seconds trying to figure out whether/how your API can be used within their application. (Joke.) The reality is, they scan for 5 seconds, use Ctrl + F, read for 60 seconds, then open all links in a new tab to read later. Modeling specifications (like Swagger and Raml) will allow you to offer a predictable developer experience for your customers.