Every Arrow Is a Decision

Module 3 of 6 in the chapter Think Like an Integration Architect, chapter 1 of the Integration Architect course. Each module stands on its own. Previous: You’re Already Doing Integration · Next: The Building Nobody Described

The question this module answers: What does an arrow on an integration diagram mean, and why does the architect have to decide?

Every integration diagram is boxes and arrows. The boxes are easy: a system is a system. The arrows are where the trouble starts, because an arrow can mean more than one thing, and people draw them without saying which.

So here’s the question I ask every class. What does an arrow mean on a system landscape?

Two Meanings, One Drawing

The first answer people give is usually: who is the client and who is the server. The arrow starts at the system that opens the connection and points at the system that answers. The one that starts the call is the client; the one that answers is the server.

The second answer is: the data flow. The arrow points the way the data travels, from where it starts to where it ends up.

Both are fair. Both appear on real diagrams every day. And here’s the catch: those two can go completely reversed. Think about one of your internal users signing in to Salesforce. The user’s browser opens the connection, so a client-server arrow points from the user to Salesforce. But what comes back is a sea of data: records, list views, dashboards, all flowing the other way. A data-flow arrow for the same conversation points from Salesforce to the user.

Same two boxes. Same conversation. Two arrows pointing in opposite directions, and both of them “correct.”

You’ve already done this yourself. In the last module, you ran Data Loader. Load a file of accounts and your laptop starts the call and the data goes into Salesforce: both meanings point the same way. Now run an export. Your laptop still starts the call, but now the data comes back out of Salesforce to your laptop. The initiator didn’t change. The data turned around.

Click to enlarge

A load. The laptop starts the call, and the data goes into Salesforce.

Click to enlarge

An export. The laptop still starts the call; now the data comes back out.

Why It Matters Which One You Mean

If the diagram doesn’t say which meaning it uses, the people reading it will each pick one, and they’ll pick differently.

And the difference isn’t cosmetic. The system that starts the call is the one that needs the address of the other system, the credentials to sign in, the decision about when to call, and the plan for what to do when the other side doesn’t answer. The system that answers needs to be listening, needs to know who’s allowed in, and carries the load when the calls arrive. Get the initiator wrong on the diagram and you’ve put the credentials, the scheduling and the error handling on the wrong side of the project.

So the architect decides, and says so on the diagram.

How I Draw Mine

I tend to make mine client-server: the arrow starts at the system that opens the connection. Then the label on the arrow says what moves. That’s the rule this course uses on every system landscape, and you’ll see it in the legend of the landscape from Everything Is Knowable: the arrow starts at the system that opens the connection, and the label says what moves.

Drawn that way, the arrows on a landscape start to tell you a lot at a glance. An IVR, the phone menu that answers a customer’s call, is an arrow in: it calls Salesforce to find the right record. An outbound dialer is an arrow out: Salesforce starts the call. Email can be both, in for email-to-case and out for replies, so it gets two arrows, one for each.

You’ll also meet data-flow landscapes, and they’re useful too, especially when the question is where the data ends up. That’s fine. Just put it in the legend, so nobody has to guess.

This is the first of four seeds this chapter plants. Chapter 2 takes the client and the server apart properly: who listens, who calls, and what each one is responsible for. Chapter 5 draws the whole landscape with these arrows.

What an Architect Decides Here

• Whether each diagram’s arrows show who starts the connection or which way the data moves, and saying so in its legend.
• For every arrow, which system is the client: the one that holds the address, the credentials, the schedule and the retry.
• Where an arrow’s data flows the opposite way to its connection, and whether the label makes that clear.
• When one pair of systems really has two conversations, and so needs two arrows rather than one double-headed one.

Explore

• The Data Architect course, Before the Arrow: the same question asked by a data architect, with who starts it and which way the data moves as the first two of seven.