What is a brittle interface?

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.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine