September 07, 2004, 12:00 AM — 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%20de...
[3] http://www.xml.com/pub/a/2004/08/11/rest.html
