At first glance, probably not much.
One works with financial performance, budgets, forecasts and business decisions. The other designs enterprise solutions, connects systems and makes technology decisions.
But the longer I have worked across Finance, Operations and ERP transformations, the more I have come to believe something:
A great Controller needs to think like a Solution Architect. And a great Solution Architect needs to think like a Controller.
Both need to understand the details without losing sight of the big picture. Both need to understand cause and effect. Both need to recognize when something does not make sense. And both need to keep asking: Why?
There is a German word I like for describing this: Maschinist. For me, both roles need to become the Maschinist of the machine. Let me explain what I mean.
I Didn’t Start as a Solution Architect
I started my career in Accounting. From there, my journey took me through roles as Controller, Head of Controlling, Head of Operations, Finance Director and CFO. Eventually, I moved much deeper into ERP transformation and Solution Architecture.
On paper, these look like very different roles. Looking back, however, one thing connected all of them: I always wanted to understand how the process actually worked.
Not only: What is the number? But: What happened in the business? Which process created it? How does the ERP support that process? Which transaction was created? And ultimately: What accounting entry did the system create—and why?
For me, the number in the financial statement was always the end of a much longer story. I wanted to understand that story.
A Controller Needs to Understand the Machine Behind the Numbers
A Controller does not create every sales order. They do not post every vendor invoice. They do not execute every inventory movement or production order. And they should not have to.
There are specialists who understand those individual areas in much greater depth. But a good Controller needs enough understanding to connect them.
Imagine gross margin suddenly changes. A Controller can report: “Gross margin decreased by 3%.” But that is only the beginning. The interesting question is: Why?
Was it pricing? Product mix? Purchase prices? Production variances? Inventory valuation? Master data? Incorrect postings? An integration? A reporting transformation? Something else entirely?
The Controller needs to be able to move backwards through the machine: Management Report → Data & Reporting → Financial Result → Accounting Posting → ERP Transaction → Business Process → Business Event.
They do not need to personally fix every component. But they need enough understanding to recognize where to start looking.
A great Controller needs to understand the architecture behind the numbers.
The Year-End Close and the Black Box
I still remember one of my first year-end closes. We had challenges around inventory. During the audit, the inventory functionality in the ERP was essentially described to me as a black box.
Transactions went in. Accounting results came out. But understanding exactly what happened in between—and why—was much more difficult.
For me, that was not an acceptable answer. We had to close the year. The numbers had to be right. And if I was responsible for those numbers, I needed to understand what the system had actually done.
So I worked through it. Days and nights. Across time zones. Following inventory movements. Understanding the transactions. Tracing the ERP logic. Following the postings into Finance. Connecting operational activity to accounting entries. Until eventually we understood what was happening. And we closed the year.
If I am accountable for the outcome, I cannot simply accept that the machine producing it is a black box.
I do not need to understand every line of code. But I need to understand enough to connect: Business event → Process → ERP transaction → Posting → Financial outcome. And when those pieces do not connect, I need to keep asking questions until they do.
And a Solution Architect Needs to Think Like a Controller
Now look at the same machine from the other direction. A Solution Architect may start with a business need: redesign Purchase-to-Pay, improve inventory management, automate Order-to-Cash, introduce a new production model, or build a global Finance template.
The architect cannot stop at: “Technically, this works.” They need to ask: What business outcome are we trying to achieve? How should the process work? Who performs which activity? Where are decisions made? Where are controls required? Which system should own which part? What data is created? What happens downstream? And in an ERP environment: What is the accounting impact?
Operational processes eventually have financial consequences. Purchasing creates liabilities. Inventory movements affect valuation. Production creates costs and variances. Sales create revenue and receivables. Projects affect cost and revenue recognition.
A Solution Architect does not need to replace the accountant, Controller or Finance consultant. But they need enough understanding to recognize whether the solution makes sense from beginning to end.
A great Solution Architect needs to understand the business behind the architecture.
Controller ↔ Solution Architect: Two Perspectives. One Machine.
The Controller may start with the outcome: “Why did this number change?” And work backwards: Power BI → Fabric → ERP → Posting → Transaction → Process → Business Event.
The Solution Architect may start with the business need and work forward: Business Need → Process → Solution → Transaction → Posting → Data → Reporting.
One follows the machine to understand the outcome. The other designs the machine to produce the right outcome. But I believe both need to be able to travel in both directions.
Because when the result does not make sense, an architecture diagram alone is not going to solve the problem. You need to understand how the machine actually runs.
What I Mean by “Maschinist”
Let me explain this with a simple example I often use. I drive a car. I get in, start the engine and drive. I know how to operate the car. I know what it is supposed to do. And as long as everything works, I do not need to understand every component under the hood.
But imagine I am driving somewhere far from home. Suddenly, the engine stops. I can see that something is wrong. Maybe I can describe what happened. Maybe I heard a strange noise. Maybe a warning light appeared. But cars are not my profession. I do not really understand the engine. So at some point, I have to call someone who does.
Someone who can look at the machine, understand how its components interact, diagnose what went wrong and determine what needs to happen next. That person understands the machine.
At some point in my career, I realized: That is exactly who I wanted to become for ERP.
Not someone who knows every parameter by heart. Not someone who can write every line of code. Not someone who is the deepest specialist in every module. But someone who understands the machine well enough to know: How does it work? Why does it work this way? What happens when we change something? What happens when it does not work? And where do we start looking?
Operate the system ≠ Understand the machine.
But the Machine Is No Longer Just the ERP
Years ago, perhaps we could have described the machine primarily as the ERP system. Today, that is no longer enough.
A customer process may begin in CRM. An approval or business workflow may run through Power Automate. Dynamics 365 may execute the core transaction. An external application may perform another part of the process. Integrations connect the different components. The ERP creates the accounting entries. Data flows into Microsoft Fabric. Power BI presents the result to management. Planning applications may use that information for forecasts and business decisions. And increasingly, AI and AI agents may analyze information, recommend actions or execute activities somewhere along that chain.
Technically, these are different technologies, applications, platforms and often even different teams. But from the perspective of the business: It is one machine.
The business does not care where one application ends and another begins. The process does not stop simply because the architecture diagram shows another box.
That means the modern Maschinist needs to understand more than ERP. They need to understand the ecosystem around it—not every component at the deepest technical level, but enough to understand how the pieces work together.
From the business perspective, it is one machine.
Being the Maschinist Does Not Mean Knowing Everything
A Solution Architect cannot be the deepest expert in Finance, Supply Chain, Manufacturing, CRM, Fabric, Power BI, integrations, development, infrastructure, security, AI and every other technology involved in a modern enterprise landscape. And a Controller cannot understand every operational process better than the people performing it. Nor should they try.
Both need specialists: functional consultants, developers, integration architects, data engineers, accountants, Fabric and Power BI specialists, business process owners, key users, operational experts and AI specialists.
Some of these people will understand their individual component far better than the Controller or Solution Architect ever will. That is exactly how it should be.
The Maschinist has a different responsibility: know enough about the components to understand how they work together; know enough about the business to understand what the machine is supposed to achieve; and know enough about the whole to recognize when something does not sound right.
That is also why working with people is such an important part of Solution Architecture. You do not replace the specialists. You connect them. You listen to them. You learn from them. You let them go deep. But you keep connecting their decisions back to the bigger picture.
You don’t replace the specialists. You connect them.
Because somebody still needs to ask: Does this piece still fit the whole machine?
Don’t Just Translate Requirements. Challenge Them.
This is another lesson I carried with me from Controlling into Solution Architecture. A good Controller does not simply accept a number. They challenge it: Why did it change? Does it make sense? What is driving it?
A good Solution Architect should do the same with requirements. “We need this customization.” Why? “We need another integration.” Why? “We need to replicate this old process.” Why?
The role of the architect is not simply to take every requirement and convert it into technology. Sometimes the most valuable architectural contribution is asking: Why are we doing this at all?
Understand the requirement. Understand the business problem behind it. Challenge the assumptions. Then design the solution.
That is another reason why I believe the Controller and Solution Architect mindsets are so closely connected. Both need curiosity. Both need healthy skepticism. Both need to understand cause and effect. And both need enough understanding of the detail to challenge it without losing sight of the bigger picture.
Maybe This Is Why I Founded Modern Finance Consulting
I started in Accounting. Then came Controlling. Operations. Finance leadership. ERP transformation. Solution Architecture. And eventually, I founded Modern Finance Consulting.
Looking back, these may appear to be very different chapters. For me, they were always connected by the same curiosity: What happened? Why did it happen? Which process created it? What did the system do? What was posted? Where did the data go? What does management ultimately see? Does the result make sense? And when it does not: Where do we start looking?
Over the years, the technology changed. The ERP landscape became an ecosystem. ERP was joined by CRM, Power Automate, integrations, Microsoft Fabric, Power BI, planning platforms and now AI and agents.
But the fundamental challenge remained remarkably similar: someone needs to understand how the business, the processes, the numbers and the technology come together.
That is one of the ideas behind Modern Finance Consulting. Not Finance on one side and technology on the other. Not ERP as an isolated system. Not data and reporting as something that happens afterwards. But a connected view of Business, Finance, Processes, ERP, Data, Automation, AI and People.
Because from the perspective of the business, these are not separate machines. They are one machine.
The Maschinist
I will probably never become the Maschinist of my car. If the engine breaks, I will still have to call someone. But I decided a long time ago that ERP should not be that kind of black box for me.
I wanted to understand the process. I wanted to understand the system. I wanted to understand the posting. And as the technology landscape grew, I wanted to understand how ERP, integrations, automation, data and reporting all worked together. Today, that includes AI as well.
I wanted to become the Maschinist of that machine.
Looking back, that idea connects much of my journey from Accounting and Controlling through Operations, Finance leadership and Solution Architecture—and eventually to founding Modern Finance Consulting.
A great Controller needs to understand the architecture behind the numbers. A great Solution Architect needs to understand the business behind the architecture. Neither needs to build every component. Neither can know every detail. Both need great specialists around them. But both need enough understanding of the whole to recognize when something does not fit. And enough curiosity to keep asking why until they understand it.
Understand the business. Understand the process. Understand the numbers. Understand the technology. Connect the people who know the details. And never lose sight of the whole machine.
Because whether you are closing the year, transforming Finance, implementing an ERP system, building a data platform or introducing AI:
The machine has to run.
Let’s Continue the Conversation
Do you agree that Controllers increasingly need to understand technology architecture—and Solution Architects increasingly need to understand Finance and the business?
And in your organization: Who is the Maschinist of the whole machine?