We were talking to a potential #AgileDataNetwork technology partner recently about the options to integrate their product with the AgileData Platform.

Their product had some interesting value in a specific part of the Information Value Stream and we could see how it might be used by our AgileData Network partners to help streamline the work they do with their customers.

We have architected the AgileData product based on a pattern where our AgileData App talks to a set of API, which in turn talks to our Config database. Each action in the App invokes the API, for example creating a Concept Tile, creating a Change Rule etc.

This meant the potential technology partner could push the config (they call it metadata) from their tool to our API’s and it would be the same result as the user doing the work manually in our AgileData App.

During the conversation on how we would do this, Nigel made the point that we would probably create a new set of API’s that abstracted the complexity of our underlying APIs.

So rather than having to push their metadata to the create Concept API and then to the create Detail API and the the create Event API, we would create an API that is a Data Design API.

The benefit is we abstract away their need to understand our underlying Config model, and we create a shared language we could use with any other technology partners. Reminds me of a Semantic layer.

This architecture design allows us to refactor our underlying API’s whenever we feel like it, while making sure we don’t push any extra work to the technology partner.

I started thinking about how many of these semantics API’s we would need if we adopted this as one of our core integration patterns.

This is what I have so far.

Data Design

The ability to push the Business, Conceptual and Logical data model to AgileData.

The ability to read these data models.

Data Contract

The ability to push Data Contract rules to AgileData

The ability to test data against the Data Contract

Last Mile Semantic Layer

The ability to push the Agiledata Consume tile semantic information to a last mile tool (reporting tool, analytics tool etc)

What use case have I missed?