Systems remember old organizations

Technology stacks are often described as collections of tools. I think they are also historical records.

A CRM field can preserve a decision made three reorganizations ago. An integration can encode a handoff between teams that no longer exist. A permission model can reveal who was trusted when the system was built. A duplicate tool can mark the moment one function stopped believing another function would meet its needs.

The org chart changes faster than the architecture underneath it.

At one company, a Salesforce baseline surfaced 872 objects and 10,161 fields. Those numbers are dramatic, but they do not tell you whether Salesforce is well designed.

They tell you where to start asking questions. Why does this field exist? Who uses it? Which decision depends on it? Is it still authoritative? What breaks downstream if it changes? Who is responsible for retiring it?

The archaeology matters more than the count.

Permissions reveal authority

Who can change a customer record? Who can approve a discount? Who can see compensation? Who can create a new workflow? Technology turns abstract decision rights into executable ones.

Sometimes the system contradicts the stated organization. A team is told it owns a process but cannot change the configuration. Another team technically has access but lacks enough context to use it.

Integrations reveal relationships

Follow the data and you can often see the organization’s real dependencies. Where does customer identity originate? Which system wins when two values disagree? What has to happen before Finance can invoice? Which team discovers the failure first?

An integration map is often a relationship map with APIs drawn on top.

Architecture is organizational memory

This is why technology cleanup is rarely only technical. Removing a field can reopen an old argument about ownership. Consolidating tools can expose a trust problem. Automating a handoff can force the organization to decide what the handoff actually means.

The stack is not separate from the organization. It is one of the places the organization has been written down.

If you want to understand how an organization really works, look at the org chart. Then look at the systems. Pay attention to where they disagree.

I have spent a lot of time thinking about Salesforce as a place where relationships can be mapped, understood, and shared—not merely as a database. Revenue flows have to be translatable across a wider toolset so the organization can see a larger story about its own health.

That is why I resist treating tools as isolated applications. Where engineers consume data may not be where Finance or Marketing should consume it. The architectural question is how information moves between technology systems, people and technology, and people and people.

The tech stack becomes an org chart because tools formalize who creates information, who can alter it, who sees it, and where one function has to cross a boundary to work with another.

Architecture records history

Most stacks are not designed in one sitting. They accrete. A team buys a tool because a problem is urgent. Another team solves a neighboring problem somewhere else. A field is added for one launch and remains for six years. Eventually the stack becomes an archaeological record of priorities, reorganizations, acquisitions, workarounds, and abandoned strategies.

That is why simplification is not primarily a software exercise. Removing a tool can require resolving the organizational ambiguity the tool had been quietly containing.