Mark Needham

One of the fairly standard ways of shielding our applications when integrating with other systems is to create a wrapper around it so that all interaction with it is in one place.

As I mentioned in a previous post we have been using the repository pattern to achieve this in our code.

One service which we needed to integrate lately provided data for populating data on drop downs on our UI so the service provided two pieces of data – a Value (which needed to be sent to another service when a certain option was selected) and a Label (which was the value for us to display on the screen).

Our original approach was to pass both bits of the data through the system and we populated the dropdowns such that the value being passed back to the service would be the Value but the value shown to the user would be the Label.

The option part of the drop down list would therefore look like this:

<select>
...
<option value="Value">Label</option>
</select>

With the data flowing through our application like so:

Although this approach worked it made our code really complicated and we were actually passing Value around the code even though our application didn’t care about it at all, only the service did.

A neat re-design idea a couple of my colleagues came up with to was to only pass the Label through the application and then just do a mapping in the Repository from the Label -> Value so we could send the correct value to the service.

The code then became much simpler:

And we had isolated the bit of code that led to the complexity in the first place.

The lesson here for me is that it’s not enough merely to isolate the endpoint, we also need to think about which data our application actually needs and only pass through the data we actually use.

One of the inevitabilities of most projects is that at some stage there is going to need be some sort of integration.

The likes of Alistair Cockburn in Crystal Clear and Andy Hunt/Dave Thomas in The Pragmatic Programmer talk of the need to do integration early rather than letting it wait until later, but why?

Get the pain out the way

To some degree every time we try to integrate there is going to be some level of pain – for me it therefore makes sense that we take this pain early on when we have the chance to do something about it rather than leaving it until later and being surprised at the problems it causes.

We never really know that the system actually works as expected until it is fully integrated, and integration inevitably leads to situations which we didn’t know existed previously.

The potential problem we need to be careful about here is that we still deliver features with business value while doing our early integration otherwise we end up with the problem that we seem to be delivering absolutely nothing.

Code can be more example driven

When we integrate later on one problem we face is that we have to try and assume what the integration will be like rather than actually knowing.

While it is possible to somewhat isolate ourselves from other systems, at some stage we need to integrate and this can typically lead to different data flowing through, in a different format than expected and we need to handle these differences.

If we integrate late we are putting ourselves into a guessing game of what we think we are going to integrate against and this leads us down the path of assumption driven development.

This inevitably leads to us coding for some situations which won’t actually happen when we are integrated and missing out some situations which we didn’t actually know could happen until we integrated.

Less inventory

In lean terms inventory is a product or part of a product which is basically in a state of waiting – either waiting for something to be done to it or waiting for a customer to buy it.

I think we can find a similar analogy in terms of story cards where a part of that story is to integrate with another system for example.

When we do the integration work needed later on the additional problem we face is that we naturally lose some knowledge in the time that the story is sitting waiting.

In addition there is also wasted time as people regain the context of how the integration fits into the overall functionality of the story.