Connecting A to B: a decision tree approach

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.

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

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