💰 Having Accounts Is Not Having a Budget
From a Tool Inventory to Intentional Architecture
Many technology departments in Colombia can show an extensive inventory. They have a tool to move data, another to store it, another to query it, and another to visualize it. When someone asks how the information flow is organized, the answer usually is that same inventory.
The problem is not that tools are missing, but that no one traced the blueprint that connects them.
Data architecture is the design that defines how information is collected in the company, how it's transformed, how it travels between systems, and how it reaches the people who make decisions. It's not the catalog of what there is. It's the blueprint that determines what each piece is for and how they relate.
Think of someone managing their finances with four bank accounts, two digital wallets, and a half-updated spreadsheet. Money is scattered, some accounts have movement and others are open with no clear purpose. Having many accounts is not having a budget. Without a plan saying what each account is for, the money is dispersed even though it's in formal banks.
Something similar happens in companies where a data warehouse, a data lake, multiple operational databases, and visualization tools that each area chose separately coexist. The data stack, which are all the technological pieces an organization uses to manage its information, exists and is visible. But without a design that defines how they connect, who is responsible for each piece of data, how information travels from one system to the next, and what rules apply at each point in the flow, that stack is not architecture.
The friction from that accumulation shows in daily work. The finance department has its numbers and the commercial department has theirs. When they cross paths in a meeting, the numbers don't match and no one knows which table is official. Manual reprocessing is generated to reconcile what two tools report differently about the same period.
IBM Think's overview of data architecture notes that 94% of data leaders listed the absence of a defined architecture among their top challenges.
First map what data tools the company has, what each is for, and who controls it. Then identify at which points data from different sources should match but don't. Then define a single official source for each key business data point. Finally assign someone the responsibility to keep that map updated, not to keep adding tools.
How many versions of the same data circulate in your company before someone decides which is correct? 💰