The Tools We Use Shape the Way We Think About Architecture

There's an idea often attributed to Abraham Maslow, though the exact quote is a bit fuzzy:

"If the only tool you have is a hammer, everything looks like a nail."

It's become a cliché, but like a lot of clichés, there's a kernel of truth in it that's easy to overlook. Especially in the world of enterprise architecture, where the tools we use every day quietly influence the way we think, the way we model, and the way we communicate.

We're not talking about features or product comparisons here. We're talking about something more subtle: the way a tool frames the thinking of the person using it.

Visio: Thinking in Boxes and Arrows

Let's start with the tool everyone knows, and that many still use.

When you open Visio (or Draw.io, or Lucidchart, or any diagramming tool), the natural gesture is: place a box, then another, then draw an arrow between them. That's the basic vocabulary. Boxes. Arrows. Sometimes colors to distinguish layers.

It's not a bad starting point. But it tends to push fairly naturally toward a static, positional view of architecture. You see components. You see links. What you don't see as easily is the dynamics: which way does the information flow? How critical is that dependency? What happens if you remove that box?

A Visio diagram tells you about a snapshot. That's useful. But a snapshot doesn't say much about the movie.

There's also a more subtle effect: since each diagram is a standalone file, you fairly quickly end up with dozens of diagrams that aren't connected to each other. The "CRM" application on the Sales diagram and the "CRM" on the IT diagram, are they the same? Probably. But nothing in the tool guarantees it.

Excel: Thinking in Rows and Columns

The other classic. We smile a bit when we mention it, but the reality is that a significant chunk of enterprise architecture worldwide lives in Excel files.

And that's not absurd. Excel is universal, flexible, and everyone knows how to use it. When you need to inventory an application portfolio or document data flows, a spreadsheet gets the job done.

But Excel pushes toward tabular, inventory-style thinking. Each application is a row. Each attribute is a column. You end up with a catalog: name, owner, technology, status, deployment date.

What's missing is the relationship. In a spreadsheet, the link between two applications doesn't exist naturally. You can model it (a "dependencies" column, a separate sheet for flows), but it's a workaround. The spreadsheet wasn't designed to think in networks.

And there's another effect: when architecture lives in an Excel file, it becomes a management object, not a thinking object. You update the rows, fill in the columns, generate reports. But you don't navigate it. You don't explore it. You don't tell stories with it.

PowerPoint: Thinking in Sequential Narrative

This one is interesting because it starts from a good place.

When an architect prepares a presentation for the executive board or an architecture review, they open PowerPoint. And something different happens: they're no longer modeling, they're storytelling. They pick an angle, sequence the ideas, simplify so it fits into forty-five minutes.

That's valuable. It's even an underrated skill in enterprise architecture. But PowerPoint pushes toward linear, time-frozen thinking. The presentation captures a moment, an angle, a message. It doesn't live beyond the meeting. And most importantly, it's not connected to the underlying model.

We've all seen it: a beautiful architecture slide deck, presented at committee, approved... and already slightly out of sync with reality three months later. The narrative was good, but it became a historical artifact rather than a living tool.

The Graph: Thinking in Relationships

And then there's another way to look at things.

When you represent enterprise architecture as a graph (nodes and relationships, rather than boxes or rows), something shifts in the way you think.

You stop asking only "what are my components." You start asking "what are the connections between them." The natural question becomes less "how many applications do I have" and more "what depends on what." Impact analysis becomes almost intuitive: if I touch this node, which paths are affected?

A graph also surfaces patterns that you don't see in a spreadsheet or a diagram: clusters of tightly coupled applications, single points of failure (one node everything depends on), isolated zones connected to nothing.

It's not a magic solution. A graph can also become unreadable if it's too dense, or confusing if it lacks context. But it's a way of thinking that maps fairly well to what an information system actually is: a network of dependencies, not a list of components.

What We Take Away from This

The interesting part isn't saying one tool is better than another. Each has its place and its moment.

The interesting part is becoming aware that the choice of tool is never neutral. It steers thinking, it makes certain questions easy and others almost invisible.

Visio makes quick visual communication easy, but fragments the big picture. Excel makes inventory rigorous, but flattens relationships. PowerPoint forces storytelling, but disconnects the narrative from the model. A graph makes dependencies visible, but requires effort to keep readable.

The question that's maybe worth asking is: does the tool I'm using allow me to think about architecture the way I need to think about it right now? Or am I thinking a certain way... because that's what my tool allows?

At Boldo, We Think About This a Lot

This topic runs pretty deep for us at Boldo, because it's at the heart of what we're trying to build.

We started from the idea that an enterprise architecture tool should be able to combine these modes of thinking rather than force a single angle. Being able to model as a graph to understand dependencies. Being able to navigate between different views to tell different stories to different audiences. Being able to connect everything to real data so the model stays alive.

The goal isn't to replace every existing tool. It's to offer a space where architectural thinking isn't constrained by the format.

It's a work in progress, and we certainly haven't solved everything. But we think it's a question worth exploring.