Location, Architecture, and Process Come First
By Hiran de Silva
A critique on this post by Folorunso Adebare Lala on LinkedIn.
There is a growing and welcome interest in reusable logic inside Excel.
Custom functions, named formulas, and most recently LAMBDA, are all expressions of the same instinct:
write logic once, reuse it safely, and reduce error.
That instinct is absolutely right.
But it is also incomplete.
Because the most important question is not whether logic should be reusable.
The pivotal question is:
Where should that logic live?
Until that question is answered, discussions about LAMBDA, custom functions, or formula abstraction remain technically interesting — but architecturally unresolved.
Reusable Logic Exists at Multiple Levels
Reusable logic can exist at many layers:
- Inside a single cell
- Across a worksheet
- Across a workbook
- Across multiple workbooks
- Across departments
- Across an entire organisation
LAMBDA operates inside one workbook.
That is not a criticism — it is simply a fact.
Once that workbook is copied, emailed, forked, versioned, or edited independently, the “reusable” logic immediately becomes local again.
So the real issue is not whether LAMBDA is clever — it is.
The issue is scope.
The Missing Question in Most Excel Content
Most content promoting local reusable components — LAMBDA is a good example — quietly avoids a far more consequential question:
What problem are we actually trying to solve?
If the problem is:
- one analyst
- one model
- one workbook
- one reporting task
Then LAMBDA is an excellent solution.
But if the problem is:
- many contributors
- shared data
- concurrent editing
- standardised reporting
- controlled consolidation
- auditability across teams
Then the problem is no longer a formula problem.
It is a system design problem.
Enterprise Work Is End-to-End
Enterprise finance work is not a collection of clever calculations.
It is an end-to-end process:
- Data capture
- Validation
- Storage
- Collaboration
- Consolidation
- Review
- Reporting
Reusable logic is only one small part of that chain.
When discussions focus almost entirely on formula abstraction, they implicitly assume that:
- data lives locally
- users work sequentially
- consolidation is manual or batch
- governance happens “somewhere else”
Those assumptions rarely hold in real organisations.
Why Location Matters More Than Logic
A function embedded inside a workbook answers one question very well:
How do we calculate this consistently?
But it does not answer more important questions:
- Who owns the data?
- Who can change it?
- Who else sees the impact immediately?
- How do hundreds of users contribute without breaking the system?
- How does management see the consolidated result without waiting?
Those questions cannot be answered at the formula layer — no matter how elegant the formula is.
Architecture First, Components Second
Once the architecture is right — once data is centralised, collaboration is live, and processes are designed end-to-end — then reusable components become genuinely powerful.
In that context:
- LAMBDA can sit in the presentation layer
- Logic can be standardised deliberately
- Reuse becomes organisational, not accidental
But without that architecture, reusable components simply make local spreadsheets more sophisticated, not enterprise processes more effective.
The Real Conversation Finance Teams Need
This is not an argument against LAMBDA.
It is an argument against starting in the wrong place.
The real sequence should be:
- What is the process?
- Who participates?
- Where does shared truth live?
- How does collaboration work?
- How does consolidation happen?
- Then — how do we abstract and reuse logic?
When that order is reversed, tools are asked to solve problems they were never designed to solve.
Closing Thought
Reusable logic is valuable.
But reusable logic inside one workbook is not the same thing as a reusable system.
Until we talk openly about where logic belongs — and why — we risk mistaking clever components for complete solutions.
And that distinction matters.
Add comment