The "modern data architecture" principles we apply at {your}APIs.  

Did you know that the international language of pilots and air traffic controllers is English? This ensures that pilots and air traffic controllers can communicate with each other, which is critical. The same applies to application developers that approach a gigantic library of functions, and precisely why you want all of your APIs to use a "common language"—by industry—to describe the same function.

1. Common Vocabulary

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

If your business spans three industries of flights, rental cars, and cruises, then you would have three common vocabularies for each collection. This ensures that the language your teams use to describe a function is the same, from the data name, data format, to description.


  type: string
  required: false
  minLength: 2
  maxLength: 2
  description: 'The 2-letter ISO 3166 country code.'
  example: US

2. Shared Assets

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

For APIs, we generally use data libraries by industry. These libraries are "drag-and-drop" components at the object level. Managed by a single data steward team (a data architect, an API architect, and a business SME) per industry, and used as a decision tree by your API teams. For example, all rental car industry driver objects.


 "driver": {
  "license-id": "DI9000",
  "state-code": "CA",
  "country-code": "US"

3. Standard Interfaces

Standard interfaces for API teams to use. In our case, this is the API platform our team is accustomed to using.

For APIs, we create a specification on our API platform. Given our common vocabulary is already defined, and the shared assets are accessible to us, we feed all of the libraries we need into our specification like drag-and-drop components. This is also known as a components-driven data model.



  driver: ../common/driver.raml
  pickup: ../common/pickup-location.raml
  dropoff: ../common/dropoff-location.raml