The ambiguity of arrows

#1 What do you mean by that?

Imagine that there are two software professionals - Daniel, Developer and Dylan, Developer - discussing an engineering problem.

Fortunately, they are quite self-aware beings, knowing their cognitive limitations, so Daniel, Developer draws the following diagram on the virtual board:

A diagram.

And then it all started.

It was a polite conversation and fortunately it turned out that one was talking about more object-oriented design while another focused more on functional aspects of the solution.

They noticed a team mate walking by, Dwight, Developer, and they asked him what he thought.

And complete silence followed.

Both Dylan, Developer and Daniel, Developer stared at Dwight, trying to comprehend his statement.

They tried to interpret the summary given by their team mate.

Eventually, Dwight, Developer spoke again, telling them what he meant.

"It's the mind that either transforms or interacts." - he said. - "Or rather it sees transformation or sees interaction."

And they both became enlightened.

#2 What do you mean by that?

Another time, in the same company, two architects had a heated discussion about a piece of the system.

Another diagram.

They both were looking at the diagram, trying to make sense of it.

Neither of them was the original author of it, so they needed to derive the understanding, together.

It turned out pretty quickly, that they couldn't agree whether it is the information flow or HTTP requests between services.

"Services?", commented one of them.

After they agreed that those architectural elements can be named "services", they continued their discussion.

"Ok, so information flows from service A to service B and service C, and then", highlighted another one, but got interrupted.

Heated debate went on and on until a manager came and summarized by saying "this org chart looks a bit weird, because hierarchical diagrams are drawn from top to bottom."

They remained silent and waited for him to disappear in the rest part of the office.

Arrows?

"These were imaginary conversations!", some might complain.

Yup, it's all made up, right?

Literally every human conversation about diagrams reveals that we all interpret the information in the same way, ain't it dear Reader?

What's your preference, dear Reader, when you draw a diagram?

Do you start with information flow?

Maybe you rather draw an Entity-Relationship Diagram (ERD) to highlight information relationships (I know those are not arrows, but stay with me, dear Reader)?

Or maybe you focus on who initiates actions?

Drawing is of course important, as it's a form of communication, but it's a consequence of...Thinking.

And thinking involves using mental models, which effectively analyze, interpret and filter incoming information, leading to various actions.

So whatever is visible, might be a reflection of our mental models.

And possibly what's even more important - whatever is invisible, might be shaping our mental models, as we saw in tiny tales.

What is an arrow?

Ask a developer and you get one answer.

Ask another one and you'll get a different answer.

Who's right?

We saw that it's not about who's right or wrong, but about seeing through the models, understanding the perspectives, and recognizing the underlying assumptions.

This can be done by training ourselves in self-awareness, in noticing that we might use a different model than our conversation partner.

Arrows might mean different things to different people.

And this meaning is given by the observer.

Processing relationships?

There are multitude of ways how one can interpret arrows in diagrams.

But I truly believe two of such interpretations are a little bit more important than the others, as they are fundamental and complementary to each other.

They can appear on "higher levels" (ekhm, "architecture levels") or on more tactical ones.

Both of them are specific examples on how two or more elements relate to each other.

Relationships.

Why did I say they are "a bit more important than the others"?

They primarly focus on doing something, so they are related to acting.

As we explored in Modeling Maturity Levels, when modeling on the right levels, one is able to capture subtle contextual nuances, just because the focus was placed on actions.

Verbs.

Arrows can represent processing relationships: transformations and interactions.

In the first tale, one of the developers tried to emphasize the transformation aspect, while the other focused on the interaction aspect.

A -> B notation should be recognizable by functional folks, who often deal with function signatures that have such expressions built-in in their functional languages of choice.

I would guess that such notation isn't well known to object-oriented people (unfortunately), who might think of objects as a data-bags (you might be interested in reading The ambiguity of objects).

Are functional programmers only transform things into other things?

What about calling an external service to get the information to be later transformed?

Oopsie, an interaction.

What do I mean by "an interaction"?

Communicating, exchanging information, collaborating, sending messages or signals - everything between two parties, across boundaries.

Transformations and interactions are dual aspects of processing relationships.

One does not exist without the other.

It's the observers who assign meaning to these relationships.

Such duo appear literally everywhere: from small objects transforming data, after responding to a method invocation, to business workflows that represent "the flow of work", exercised by the interacting parties.

Processing relationships express the structure of actions, which allow for the observer to focus on movement, rather than static elements - which as we saw in Boundaries, modularity and a diaper effect, is quite important aspect when looking at things.

Another name for such structure is a protocol.

Well, it's more close to an etiquette, but still it captures the essence of this abstraction - "correct conduct and procedures".

Such "the structure of actions" is nothing more than a process, which involves steps that need to be executed in a specific order to achieve a desired outcome, which requires transforming information into some other type of information...

...And each transformational step requires a transforming party to provide capabilities for doing so...

...Without directly caring how the work is done (from the process perspective), but focusing on what needs to be achieved.

...Ok, now we're doing circles, but I hope you got the point, dear Reader?

Transforming or interacting?

When you deal with object-oriented code, do you think about objects interacting with each other, "not caring about transformations"? Why?

When looking at the diagram - do you focus on information flow and how the data is getting transformed? Why?

Interactions are quite different from transformations, as they involve communication between elements rather, without breaching certain established boundaries.

Transformations, on the other hand, might not pay attention at boundaries (and information hiding), as they mostly focus on immutable state evolution.

But at some stage, an Order might become an Offer, which eventually might become an Invoice, but each capability transforming one into another will be provided by a party, playing a certain role in the workflow.

What is really interesting is that typically providers are interested in details what are the steps (a workflow), whereas consumers are more focused on the provided capabilities and outcomes they can get.

Which expresses an interesting dynamic: providers might care more about transformations, consumers might care more about interactions (of course it's a huge simplification, as both processing relationships are dual and complementary).

Another fun fact, visible in mentioned tiny tales: trying to present both processing relationships at the same time might make participants confused, worried or overwhelmed.

That's why I find particular ways of collaborative modeling (like Event Storming, BPMN, Event Modeling) powerful as they aim at capturing both perspectives: transforming and interacting.

So next time dear Reader, when you'll be reviewing a diagram or drawing one, or maybe you'll be applying business logic in the code (with or without LLMs), ask yourself a question:

Bonus: here's the original Zen Koan I got inspiration from:

What have changed since then?