BUSINESS ANALYSIS / PROJECT ARCHITECTURE

Easier Said
Than Done.

Designing the operating architecture of a literary review.

What does it take to turn a submission into a printed issue, a delivered order and the next editorial cycle?

This is the publishing system on which The Brussels Review and Revista Letrare are built. It connects objectives, processes, rules, requirements, systems and decisions through one publication lifecycle.

BUILT FOR THE BRUSSELS REVIEW & REVISTA LETRARE ↘
The Brussels Review cover with a black and white illustration of a readerThe Brussels Review Summer 2025 cover with orange and pink artworkThe Brussels Review cover with blue and white abstract artworkThe Brussels Review Remember cover with a photograph of hands holding pendantsThe Brussels Review Winter 2025 cover with a woodland portraitThe Brussels Review Winter 2024 cover with layered figure artworkBlanc cover with handwritten contributor namesBlue cover with abstract artworkHeartwarming Stories cover with a bookshop imageDark cover of The Brussels ReviewRouge cover of The Brussels ReviewEntrances and Exits cover of TBR Blanc
TWO DECISIONS FROM PRACTICE

It began with a simple question:
How should a writer submit?

The submission workflow at The Brussels Review took shape through choices that looked small until the consequences arrived.

01 / THE PLATFORM

Choose a doorway.

We considered email, Duotrope and Submittable. Submittable offered the more expansive option, but at a price we could not justify. Duotrope gave us broad reach at a cost we could sustain, so we chose it.

That choice has a limit: Duotrope has no API for the integration we would like. Its team has been receptive to suggestions, and we remain happy with the decision. The system had to fit the publication’s resources, even when it could not do everything.

02 / THE GATE

Then the submissions came.

We accepted work from everyone. With free submissions, the volume became a flood. We introduced a €5 fee for a first submission to discourage casual entries.

The work we now receive is, in our editorial judgement, very good. That is an observation, not a measured claim that the fee improved literary quality. The decision also leaves a question we must keep asking: how do we manage volume without closing the door to a writer who cannot pay?

02 / PROCESS ARCHITECTURE

From idea to the next issue.

PUBLISHING PROCESS MODEL
PROCESS FLOWTRIGGER → DECISION → OUTPUT
03 / METHOD & SCOPE

The model is the argument.
Literary excellence is the constraint.

The model makes the work of publishing visible, but every operational decision must protect the quality of the writing and the integrity of the editorial judgement. Each stage has a trigger, responsible roles, a decision, an exception path and an output. The left navigation follows the lifecycle; the flowchart describes the selected stage; the right panel records dependencies and constraints.

The model is informed by the operating context of The Brussels Review and Revista Letrare. Its detailed rules and requirements are analytical proposals for discussion; confirm them with the teams responsible before treating them as operating policy.

Business contextProcess decompositionFunctional requirementsArchitecture decisionsException handling