Interfaces and Contracts

I've been thinking a lot about interfaces and contracts recently, specifically when it comes to data solutions. I think this is such an important topic and it being forgotten about is an issue I keep coming up against everyday.

All I mean here is that if you are building a piece of software and it is not a self-contained monolith (which is generally not a great idea - maybe I'll cover that in another post) then you are likely building components that have to talk to each other somehow. Unless you're doing it by magic, in which case, wrong blog!

So if your components have to talk to each other, what language are they speaking? Could be anything from a JSON body in a REST API call, to just using an agreed upon schema or a dump of data on a schedule, to prescribing to a topic in a pub/sub mechanism ... The key thing is that even asking this question puts you ahead of the game, as people can leave this too late or not really appreciate it's importance.

On top of the language you're speaking, you also have to, stretching the metaphor here, agree the etiquette you will use in speaking to one another. This to me is represented by the contract between the components. For example, I may be using a REST API call to transfer data, but I have to do this in a specific way, usually defined in the documentation of the system I am calling. This should specify key-value pairs I can provide, including which are mandatory and which are optional, and clearly state the form of the return I will get in different scenarios. By having this contract in place it means that new users of the API can build resilient mechanism for calling the API and processing the response. You have to do something similar no matter the transfer mechanism, but you really have to do it. When you don't do this, or more likely when you leave it too late in a project, you are running the risks of building something that breaks easily, not building on time or not even successfully building anything.

So, do me  a favour. When you are building your data solution, make sure to consider the interfaces and contracts in the solution. If you don't, I'll be annoyed and I'll think you've wasted someone's time.