Interpreting the Briefing
There are many ways to begin building a system.
Some people open the IDE immediately, as if typing fast enough could compensate for not knowing where they are going.
But if we do that, we lose the most important part of the journey:
the map.
Why care about a map if it will probably change?
Exactly because it will change.
A map is not a prophecy.
It is a shared language — a temporary agreement that lets everyone understand where we think we are and what we believe matters right now.
We draw enough to move. We avoid drawing more than we can carry.
So let’s begin.
From Briefing to Understanding
In real projects, information arrives in three familiar shapes:
-
The Ancient Manuscript
Pages of comprehensive documentation written by people who may no longer work in the company.
Heavy, complete, and often outdated the moment you open it. -
The Coffee-Break Download
A rushed explanation from a stakeholder who is already late for another meeting.
Incomplete, fragmented, sometimes contradictory. -
Silence
No documents, no explanations, only expectations.
So the first universal step is always the same:
discovery.
In Hireflow, we keep things lightweight.
This Saga is not about bureaucratic analysis — it’s about constructing a real system, with just enough reasoning to support the next move.
But even a “fair tale” needs a bit of structure.
What Do We Mean by “System”?
A system, in the most generic sense, is a set of components that interact to achieve a purpose.
It has inputs, outputs, internal rules, boundaries, and behaviors that emerge from the interaction of its parts.
Your body is a system.
A city is a system.
A hiring platform — with people, processes, queues, and decisions — is undeniably a system.
This broad definition helps us because it removes the illusion of “software = code”.
Software is behavior built intentionally.
Why Big Design Upfront Fails in Reality
There was an era when architecture meant designing everything before writing anything — the famous Big Design Up Front.
It sounds rational:
“If we think hard enough in the beginning, we won’t make mistakes.”
But that’s not how the world works.
Every plan is exposed to external forces — market shifts, new priorities, sudden meetings, interruptions, team rotations.
Like an adversarial game, every player competes for the same limited resource: time.
So the problem with a giant upfront design is simple:
the world moves while you are drawing.
By the time you finish, part of your masterpiece is already obsolete.
Agile emerged to counter this, embracing an uncomfortable truth:
planning still matters, just not all at once.
We plan just enough to take the next coherent step, and we validate direction along the way.
Chaotic? Sometimes.
Effective? Usually.
This is the spirit we’ll follow.
Back to the Briefing: Extracting Structure
We now take the first pass on the briefing and try to understand it in a structured way.
Let’s borrow some ideas from Object-Oriented Analysis — not because it’s perfect, but because it offers a clear conceptual vocabulary.
And we’ll follow a relaxed version, adapted to WNT’s minimalistic and pragmatic tone.
Other common techniques include:
- Use-Case Modeling (UML)
- Domain-Driven Design discovery methods (event storming, ubiquitous language)
- User Stories (agile)
- Business Process Modeling
- Impact Mapping
- Functional Decomposition
We’re not committing to any of them formally — we’re borrowing whatever helps us think with clarity.
Identifying Actors
First step:
Who interacts with the system?
These are our actors — human or non-human entities that trigger behavior.
Extracted directly from the briefing:
- company
- recruiters
- candidates
- the system
- scheduler
Now refine:
Company
A company itself doesn’t “act”.
A person in a role does.
So we materialize it as Company Admin — a simple, descriptive (and intentionally uncreative) name.
The System
“The system evaluates applications.”
This is not an actor — it’s a business rule inside the system.
Scheduler
This one is an actor.
Time-based triggers behave like external events.
If an external system wakes us, that system becomes the actor.
If time itself wakes us, the actor is the Timer.
Recruiters & Candidates
Clear and straightforward.
So our final list becomes:
-
Company Admin
-
Recruiter
-
Candidate
-
Timer
These are the four identities our system must support from day one.
And this implies one foundational service:
Identity Service — the place where roles live and authentication/authorization is anchored.
So far, the map expands naturally.
Next Step: Identifying Services
With actors in hand, the next movement is to identify what services exist and what each service owns — but that is the next part of the episode.