Today I’m touching a sensitive topic - architecture. Architects I know are sometimes touchy about anyone else discussing their territory. In my work as consultant (APIs) I’ve faced situations in which I have had to educate the business layer and even some architects about APIs and integrations. Some think it’s the same, but it’s not. After that has been cleared in the discussions, the audience still wants to see how to get started with APIs. Lets discuss these two topic today and how they are DX related. In short, today’s post is mostly about internal DX in architecture level and how to enable agility with APIs.

Change is evident

Bad news is that you need to be ready for changes. You would want to have everything as steady as possible. One of the Ten Commandments of Egoless Programming is

The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.

Good news is that you can make choices in architecture which will less destroy the developer experience.

APIs and integration

But first let’s make it clear what is an API and what is an integration. I’ll throw “app” in the soup as well, since those 3 are unfortunately confused too much by not-so-technical people. The API and integration are confused also occasionally by technical people.

APIs act as insulation

Normally in discussions the above is something that is good to make clear to all. Then the question often is “How do we get started?”. My advise is to start with internal APIs. Learn, experiment and get mature (as organisation) for APIs under the radar. My advice is to start with insulation.

The idea is that if you create a insulation layer around your core functions (what ever those are) and let other services to use those only from your defined and controlled APIs, you can change the component easily without interfering the consuming services.

For example if you use customer management such as hubspot and Zuora for subscription management in various services in your architecture, you don’t want those services to interact directly with Hubspot API or Zuora APIs. You want to have insulation layer in between.

Replace services in the background without interruptions

You do not want to cause SLA breaks. That is bad developer and customer experience (even your internal developers are your customers).

In the above example you might start taking advantage of Zuora’s excellent subscription management. I love the book Subscribed: Why the Subscription Model Will Be Your Company’s Future - and What to Do About It written by founder of Zuora Tien Tzuo, but one day you (or me) might want to replace that service with another one. Reasons might vary:

If you have the insulation API layer controlled by you and used by the services on top of it, you can in silence setup replacement service for Zuora and at convinient time just swiftly replace it. None of the services will know about the change (unless told). Of course same applies to the other services as well, not just Zuora :)

Replace external service to internal service without interruptions

It is also likely that first it makes sense to fill in the needs of the services with someone elses service like Zuora or Hubspot. Eventually it might make sense to build in-house solution. In that case you can again develop the replacement solution under the radar and again just replace the service at your API level. None of the service build upon all that will not notice anything (if all goes well and it rarely does, Mr Murphy).

Architecture affects your internal DX

How do I minimize the damage of architecture driven changes towards any of the services build on top of it? You might have separate teams working on separate services and still those teams have similar needs for for example to manage customer information. In that case teams are working most often quite independently to ensure advancing in their schedule.

Of course the same applies to external DX as well if you at some point make the internal API a public one. The above approach is by the way one way to eat an elephant eg replace a monolith in the backend and go towards micro-service architecture.

Some more to read from 100 Days DX