CTO Articles

Home > News > CTO Articles

Published in IT World
E-Business in the Enterprise – September 7, 2004

What is a brittle interface?

By Sean Mc Grath

You do not need to spend much time in the company of people noodling application integration before you hear the word "brittle". As soon as someone says it, all faces present develop pained expressions. The same sort of pained expression you see when neighbors gather to examine a busted lawnmower on a Saturday afternoon. Brittle is bad. Real bad. You need to steer away from brittle things. You definitely want clear water between you and brittle interfaces in your EAI strategies. Yes, Sir.

But what exactly is a brittle interface? My dictionary provides this definition of the adjective form of the word:

"Not annealed and consequently easily cracked or fractured."

I don't know about you, but that does not sit easily with my mental picture of a brittle interface. What is my mental picture? Well, I don't use the word 'brittle' when I am concerned about how easily an interface stops functioning owning to increased stress or workload. I don't use the word 'brittle' when I am concerned that a tighter specification or better materials (e.g. programming language) would have made the interface better.

I pretty much exclusively use the word 'brittle' to describe an interface that is not easily changeable through time. It occurred to me recently that I have been having conversations with technical folk for years now in which we all agree that brittle is bad, but each of us most likely have different interpretations of the word! Not good. It appears that EAI practitioners are a good example of a community - to paraphrase George Bernard Shaw - divided by a common language[1].

The confusion over the word 'brittle' is, I think, symptomatic of a greater disconnect between the IT world and the Business world. Unfortunately, many, many billions of dollars have been spent creating interfaces that do not take 'change through time' into account. Of all the blind alleys and mishaps of this rapidly evolving industry, paying mere lip service to the concept of change is perhaps the most egregious.

On a positive note, I think the need for easy changeability through time is rising to its proper place on our list of EAI priorities, namely, right at the very top. Luckily, this trend is paralleled by a trend in EAI best practice that seeks to build change-through-time right into the architecture[2]. This is being played out right now in the debate between document-centric Web Services and Interface Centric Web Services.

With document-centric Web Services you concentrate on making statements in business language about what has happened in your world: "An invoice has been raised", "A baby has been born", "A delivery has been received" and so on. You then establish a business flow in which these business-meaningful statements flow around your line of business applications.

Note that I managed to say all that without using the word "interface" once? In this EAI model, interfaces are largely irrelevant. You simply use a standard interface shared by all resources such as the REST[3] model used on the World Wide Web.

With interface-centric Web Services, you concentrate on deciding what objects make up your world and you specify a custom interface between each type of object and all the other types. You then hook these custom interfaces together with custom glue code.

The latter type of integration strategy is the one that causes my brittle sensors to go off. Brittle in the sense of hard to change through time. Brittle in the sense that if I change one of these interfaces, there will be knock on effects to who knows how many other interfaces. Not good.

The former type of integration strategy is not as brittle to my ears because it is 'softer'. I know I risk abusing language here again! Softer in the sense that business statements such as "An invoice has been raised" are timeless - they do not change very often. Systems will come and go but an Invoice is an Invoice is an Invoice. Soft integration is all about avoiding potential fractures. You do this by creating as small and tight and timeless an interface as you possibly can.

This article has pretty much completely turned me off the word 'brittle' and I intend to avoid using it in the future.

It is not a good word for use in EAI conversations. Too many conflicting mental models.

We need a better word. Suggestions?

[1] http://www.feniks.com/fbc/divided.html
[2] http://www.pacificspirit.com/blog/2003/12/22/formal%20compatibility%20definition
[3] http://www.xml.com/pub/a/2004/08/11/rest.html

 

http://seanmcgrath.blogspot.com