We work with software engineering teams new to the modern data architecture implementation approach.
Technology Provider A
Has a well-designed suite of 50 APIs. APIs are currently in their infancy, privately-accessible to customers, with high adoption rates. They're using an API management platform.
They're already taking advantage of built-in capabilities for their well-designed common vocabulary and shared assets, using common data libraries for each industry collection.
Today, their API development teams currently do everything well at-scale, but a year from now, there will be 5 more global teams creating APIs due to their quick growth.
A’s data tidy-up: API descriptions, request/response parameter descriptions, standard API specification template, API design guide.
Before they expose their APIs to a public developer portal, they need to ensure that their developer customers have a consistent and predictable experience.
Today, their API development teams currently do everything well at-scale, but a year from now, there will be 5 more global teams creating APIs due to their quick growth. They should have an API design guide so their common vocabulary and shared assets are ready to scale to other API suites; request/response parameter descriptions to make their endpoints simpler to consume and easier to understand; API specification templates (with fill-in-the-blank fields) to ensure standard interfaces on their developer portal.
Technology Provider B
Has a not-so-well-designed suite of 30 APIs. APIs are currently internally-accessible only. They’re using an API management platform.
They're not taking advantage of any built-in capabilities for any common vocabulary, shared assets, or a standard interface for market consumption. Data models vary from endpoint to endpoint (e.g. departureDate, departure_date). They need help re-vamping their API suite for a market launch.
A’s data re-launch: API design guide, standard API specification template, a common data model within their data libraries, API descriptions, request/response parameter descriptions.
Today, their API development teams may be developing and launching without regard to common vocabulary, shared assets, or standard interfaces, but their customers aren't going to appreciate that they need to create new code from endpoint to endpoint. Let alone, an unpredictable developer experience on their developer portal. They'll quickly lose market share to the next technology provider that's consistent.