Static or Live: Choosing How to Publish Architecture

Two different products, often confused

"Publishing architecture" covers two things that look similar in a demo and behave nothing alike in production. One is a live web application reading your repository. The other generates files from your repository and puts them somewhere. Sparx users meet the first as WebEA or Prolaborate; the second as HTML report generation, or a dedicated publishing tool.

The choice is usually made on features. It is better made on which question your readers are asking.

The question that decides it

A live portal answers what is the architecture right now. A static publication answers what did we approve, and when. Those are both legitimate questions and they belong to different people.

Architects and delivery teams working inside a change need the first. They want to see the model as it stands, including the parts that are mid-edit, because that is the work. Risk, audit, procurement, suppliers and steering committees need the second. They need something they can cite, that will still say the same thing next month when someone asks them to justify a decision.

What each one actually costs

The row people underestimate is the security review. A live portal needs a network path from a web tier to the repository that holds your organisation's application landscape, integration points and security controls. That is a genuinely sensitive dataset, and in a regulated environment the review is not a formality. A folder of static HTML on an existing intranet server usually inherits an approval that already exists.

Where static publication stops working

It is not a universal answer, and the failure modes are predictable:

• You need write-back. Comments, approvals, feedback captured in the portal — a static site cannot do it. A mailto link is the honest limit.
• Your readers need live status. If the portal is meant to show deployment state or incident impact, a snapshot is misleading.
• The model changes hourly and readers need to track it. At that cadence you are effectively rebuilding a live portal out of a publication schedule, badly.
• The index gets too big. Browser-side search has a practical ceiling. Past roughly 8 MB of index the first-load cost stops being acceptable, and you need either sharding or a search service.

If you hit two or more of those, buy the live product. That is what it is for.

What "live" does to modelling behaviour

One consequence of live publication gets discovered only after go-live, and it belongs in the decision: exposing current state changes how architects model. The repository was a workshop; it is now a shop window, and people behave differently in windows.

The healthy version of the change is real — knowing that delivery leads see the model tomorrow does wonders for naming discipline and for the backlog of "temporary" scaffolding. The unhealthy version arrives with it: architects hesitate to sketch, because a half-formed idea now has an audience; exploratory work migrates out of the repository into slide decks, where nobody can see it and nothing governs it; and the boldest modellers start keeping private working copies, which is the file-share era returning in disguise. The repository becomes tidier and emptier — polished current state, no visible thinking — and an architecture function that cannot think inside its own repository has traded its workshop for a showroom.

Mitigations exist — draft packages excluded from the live view, personal sandboxes, a visible "work in progress" state readers are taught to expect. All of them amount to reintroducing a boundary between working and published, which is the boundary a scheduled publication has by construction. That is the quiet argument for the static side that never appears in feature comparisons: a publication step is also a psychological airlock, and practices that keep one tend to keep their exploratory modelling in the repository, where it belongs. Whichever way you choose, decide who is allowed to see unfinished thought, and make the tooling enforce the answer rather than leaving it to nerve.

Where a live portal is overkill

Conversely, a surprising number of organisations run a live portal to do something a scheduled publication would do better and cheaper. The signature is a portal whose readers are almost entirely passive, whose content changes weekly at most, and whose main use is being linked to from other documents.

That last one is the tell. If the dominant use of your portal is people linking to it from decision records, business cases and audit responses, they need permanence, not currency. A link that resolves to a moving target is a weaker citation than a link to a dated baseline.

Where the files can live

One consequence of the static choice deserves its own section, because it quietly decides several arguments that look unrelated: files can live anywhere. A generated portal is a folder, and a folder deploys to whatever the organisation already trusts — the intranet web server, a cloud storage bucket behind the corporate CDN, a static hosting service, or a directory on a server in a network segment no vendor product will ever be allowed to reach.

That last case is not exotic. Estates exist whose architecture describes systems in enclaves — operational technology, defence, payment infrastructure — where the review question is not "is this application secure" but "nothing new runs here, full stop". A static publication passes that bar by having no runtime to review. The same property serves the opposite extreme: the due-diligence data room during an acquisition, where a scoped, dated, self-contained portal can be handed to the other side's advisers as files, with no accounts to provision and no server whose logs now contain a counterparty's reading habits. And it serves the mundane middle — the supplier who needs the integration views but will never be in your directory, the joint venture on a different tenant, the regulator who wants a copy rather than a login.

The live portal's answer to each of these is federation, guest identities or exceptions — each solvable, each a project, each a small negotiation with a security team. The static answer is a folder whose contents were already deliberately scoped at generation. Reach is the static model's most underrated property: not that the files are simple, but that simplicity travels through organisational boundaries that applications cannot.

Running both

The pragmatic answer in most large organisations is both, with a clear split: the live view for the architecture practice and active delivery, a scheduled publication for everyone else. This is less work than it sounds, because the publication is generated from the same repository and needs no separate maintenance once its schedule is set.

Three years of each, sketched honestly

Feature tables hide time, so run both options forward three years for a typical mid-size estate and watch where the effort actually lands.

The live portal's year one is procurement and the security review — the licence negotiation, the penetration test, the network path argued through two committees — followed by a go-live that works. Years two and three are an operations story: the server on a patching rota, the licence renewal, the upgrade that has to be scheduled around the vendor's compatibility matrix, the SLA conversation after the morning it was down during a board meeting. None of this is pathological; it is what running an application costs, and organisations that already run fifty applications absorb it without noticing. Organisations where the architecture practice would be running its first application notice a great deal.

The static publication's year one is building or configuring the pipeline and arguing about scope — a shorter list, mostly internal. Years two and three are almost embarrassingly quiet: the pipeline runs, failures alert and get fixed, the runner gets its EA upgrade twice a year, and the recurring cost is measured in hours per month. The effort migrates instead into content and curation — perspectives, catalogues, the change log — which is to say, into the product rather than the plumbing. That migration is the real difference between the columns: both options cost something forever, but one pays its residual in operations and the other in editorial work, and only one of those compounds into a better portal.

A decision you can make in an afternoon

List your portal's intended readers. For each, write down the last question they actually asked and whether a week-old answer would have been wrong. If most answers are "a week-old answer is fine", you are looking at a publication problem, and the cheapest correct solution is to generate files on a schedule.

What a security review actually asks

The cost row that surprises people is the review, so it is worth being concrete about what the two options face.

A live portal is an application with a network path to the repository. The review will cover authentication and session handling, authorization and whether it can be bypassed, input handling, the database connection and the credentials behind it, patching responsibility, logging, and what happens when the component is compromised. In a regulated environment that is typically a penetration test and several weeks of exchange.

A static publication is a folder of files on infrastructure that already exists and was already approved. The review is mostly about content classification — what is in it and who can reach it — which is a conversation with the architecture team rather than an assessment of software.

That difference is not a technicality. It is frequently the difference between publishing this quarter and publishing next year.

The hybrid that works

Organisations that run both usually arrive at the same split, and it is worth adopting deliberately rather than discovering it.

The important discipline is that the published portal is generated from an approved baseline, not from current state. That is what makes the two artefacts genuinely different rather than the same content at two refresh rates — and it is what lets you tell a reader, honestly, that what they are looking at was agreed rather than merely drawn.

Reading vendor pages with this lens

Every tool in this space describes itself as "publishing", so the buyer's job is to detect which product is actually on offer, and four questions cut through the language reliably. What runs at the moment a reader opens a page — a server evaluating queries, or a web host returning files? Where do repository credentials live — inside a component readers can reach, or only inside a pipeline that ran and exited? What exists after the process completes — a session that ends, or an artefact that persists? And can last March's output be produced again, byte for byte — the citability question, which most demos cannot answer because most demos have no March.

The answers sort any tool into one of the two products this article describes, whatever its homepage says. They also expose the marketing seam where trouble lives: tools that generate static output but only from inside a running server, tools that are "static" except for the search service, tools whose "snapshot" is a database backup rather than a publication. None of these are dishonest products; they are hybrids, and hybrids inherit the review burden of their most demanding component — which is the fact to establish before procurement, not after the security questionnaire arrives.

Ask the four questions in the demo, write the answers into the requirements, and the static-or-live decision stops being a philosophical debate and becomes what it always was underneath: an operations decision about what your organisation wants to run, review and stand behind for the next three years.

Migrating between them

Teams sometimes worry about choosing wrongly and being stuck. In practice the move from static to live is straightforward — the repository is unchanged and you are adding a component. The move from live to static is also straightforward and rarely happens for technical reasons; when it does, it is usually cost or the end of a licence.

What is genuinely hard to undo is neither: it is building a bespoke portal that encodes your metamodel assumptions in templates nobody else understands. That is worth avoiding regardless of which side of this choice you land on.

The sentence to put in the requirements

Decisions like this one get made properly and then unmade by procurement documents that never recorded the reasoning, so it is worth writing the conclusion down in a form that survives. One sentence per audience does it: "Delivery teams require live access to current state, provided by [the live product], with named accounts" — and separately — "governance, audit and external audiences require dated, immutable, self-contained publications, generated on a stated cadence from approved baselines, hosted as static files." Two requirements, two products, no ambiguity for the vendor whose tool does one of these to claim it does both.

That wording carries the whole article inside it. "Dated and immutable" rules out the moving target; "self-contained" rules out the portal that secretly needs a server; "from approved baselines" preserves the working-versus-published boundary; "stated cadence" imports the staleness contract; and splitting the audiences prevents the classic compromise where one product is bought to serve both and serves the louder one. Requirements written at this level of intent survive personnel changes, procurement cycles and vendor pitches — which is more than can be said for the reasoning in anyone's head, however sound it was on the afternoon this decision got made.