VITI Magazine – Special Feature: Architecture & Engineering Series
Editor’s Note: After exploring the depths of meeting theater, VITI decided to visit the engineering basement to examine the secret engine behind the Business Impact Governance (BIGF) framework. We sat down with Erkki Laine to discuss why trading 200-page Word documents for a simple, cold-hearted Finite State Machine (FSM) is the ultimate form of "genius laziness."
VITI:
Erkki, let’s talk about the core engine of your framework. While everyone else is trying to solve DORA and NIS2 compliance by writing massive piles of new Word documents, you reached deep into computer science history and pulled out a Finite State Machine. Why?
Erkki Laine:
(Adjusting his glasses, sipping cold coffee) Because traditional compliance runs on "trust and prayer." In a normal company, a developer makes a change and just hopes a Tuesday Change Advisory Board (CAB) meeting will approve it based on good vibes and a spreadsheet. A Finite State Machine doesn't do "hope." It operates on pure digital logic: the system is either in State X or State Y. There is no "maybe" or "can we make an exception because it's Friday afternoon."
VITI:
Let's break down how your state machine actually devours enterprise bureaucracy. How does it stack up against the traditional way?
Erkki Laine:
Let's look at the actual math of how it replaces the theater:
| Element | Traditional Enterprise (Word/Excel) | Laine's BIGF (State Machine) |
|---|---|---|
| Current State | "We have this development phase going on right now, I think..." | State A: The system is in a verified, compliant, and approved state. |
| Change (Transition) | A developer makes a change and hopes the CAB meeting approves it on Tuesday. | Transition: A code change attempts to push the system into a new state. |
| Rules (Guards) | "Did you remember to fill out the risk assessment spreadsheet?" | Mathematical Condition: An automated code-level check (Policy Gate). If conditions aren't met, the transition is rejected in milliseconds. |
| Next State | "Let's hope nothing broke in production." | State B: The system successfully transitions into a newly proven, secure state. |
VITI:
That transition check sounds brutal. If a developer tries to push a change without meeting the conditions, what happens?
Erkki Laine:
The runtime environment rejects it instantly. Managing humans with manual rules is terribly inefficient because humans love to bend them. But if you bake the rules directly into the runtime environment as an authority boundary, an unauthorized change simply cannot move forward. The system physically blocks it. It is the ultimate form of genius laziness: instead of building complex managerial hierarchies, you let a good old-fashioned state machine ensure that illegal state transitions are mathematically impossible.
VITI:
And I assume corporate executives aren't huge fans of state machines, right?
Erkki Laine:
Oh, they despise them. You can't sweet-talk a state machine over lunch, and you can't bypass a mathematical guard clause with a PowerPoint presentation.
The Takeaway
When you replace bureaucratic guesswork with a deterministic state machine, the paperwork vanishes and the system simply executes.
P.S. Ready to see what a state machine rule (Guard) actually looks like as code?
- 🔍 Just Google it: erkki laine big framework 😉
- 💻 GitHub Repository & Code: https://github.com/ErkkiLaine/bigf-framework
- 📄 Full Technical Specifications (CERN Zenodo): https://doi.org/10.5281/zenodo.22658623
