Connecting A to B: a decision tree approach

by Sean McGrath

February 21, 2008 —

One of the most common problems tackled by IT teams is integration. In its
most basic form the question is "How to connect A to B?" (for arbitrary
systems A and B). In my travels, I find a tendency to jump straight to technology
to answer this sort of question. I find it more useful to follow a decision
tree process to zoom in on the most suitable approaches. From there, I move
to thinking about specific technologies.

The first question I ask myself is about the direction of discrete information
flows at a business level. Either A has something that B needs or B has something
that A needs. Which is it? Answering that question tells you something very
important: which system - A or B - has the "master" copy in this information
flow.

This a vital thing to know because once A and B are successfully connected
together, the information in the flow will exist in at least two places - not
one - for at least some period of time (possibly always). It is important to
be careful of words like "send". It is common practice to say "A
will send it to B" but computers rarely really send anything anywhere.
Instead they create copies. Where there are copies of data it is important
to know which one is master and which one is, well, a copy. Many times, when
this is not articulated properly, problems ensue when changes are made to "downstream"
copies and presumed by users to flow back upstream to the master copy.

The second question I ask myself concerns choreography. There are two main
approaches to causing information to flow from A to B. A could be the leader
and take responsibility for initiating the transfer. Alternatively, A could
sit back and wait for B to come calling looking for the information. Both work
fine. The net effect is the same. The important thing to notice is that the
flow direction is "A to B" in both cases. In the former, A is on top
as it were, driving. In the latter, B is on top doing the driving.

Again, this has important implications at a business level. If A is driving
the conversation, then A carries more responsibility than B and visa versa.
In the unhappy event that information flow is disrupted, technicians (and management)
will come looking for answers and it is very important to know the mutually
agreed responsibilities between A and B. Moreover, understanding the choreographic
relationship between A and B is important when it comes to reconciling log records
to establish ex-post-facto pictures of historical information flows.

In formal integration scenarios - where organizational boundaries are crossed
- the choreographic analysis is very important as it allows the "handover"
point to be articulated. i.e. if A is driving, there comes a point where A says
"Ok B - now it's over to you" and B will have to say "Ok A -
I acknowledge receipt. Have a nice day.". I have seen many, many arguments
and blame allocation meetings resulting from a badly articulated handover process.
Better to address the choreography up front and get it into the SLAs.

There are other steps in the decision process of course and there are some
hybrid scenarios that break this simple model but it works a lot of the time.
I find that it focuses attention on the key issues from a business perspective.
This industry has a tendency to throw acronyms and buzz phrases at integration
problems. For example I could say "let's use Web Services" or "let's
use REST" or "let's use .NET" and perhaps get lots of nodding
in a room of stakeholders at an integration planning meeting. However, none
of these give me answers to the key business questions of directionality and
choreography.

ITworld.com