CelinQ Insights · No. 16

From intent to model: generating designs directly in the tool

Turning a plain-language instruction into real, laid-out model content.

Most of the time spent building a model is not spent thinking. It is spent typing. You have already worked out, in a workshop or a corridor conversation or your own head on the drive home, that a particular capability is realised by three services, that those services depend on a shared identity component, and that the whole thing sits behind a gateway. The architecture is decided. What remains is the mechanical labour of turning that decision into model content: creating each element, giving it the right type, naming it consistently, drawing the relationships in the right direction, dropping the whole lot onto a diagram, and then spending twenty minutes dragging boxes around so the picture is legible enough to show someone. The thinking took ten minutes. The transcription takes an hour, and it is the least interesting hour of the day.

This is a strange way to spend the time of the person who is usually the most expensive and most scarce resource on the project. The value an architect brings is in the judgement — what the right decomposition is, where the boundaries fall, which dependencies are load-bearing and which are incidental. The value is emphatically not in their manual dexterity with a modelling tool's element palette. Yet the tool, as traditionally used, taxes the judgement and the transcription at the same rate, because both come out of the same hour. The result is that architects ration their own modelling. They capture the big decisions and leave the supporting structure vague, not because the supporting structure does not matter but because filling it in by hand is a chore that never feels worth starting.

What the manual path actually costs

It is worth being precise about where the hour goes, because the cost is not one big thing but a pile of small ones. There is the raw creation: right-click, new element, choose the type, type the name, repeat. There is the naming discipline, which is real work even when it feels like none — deciding whether this is an "Application Service" or a "Business Service", whether it follows the team's naming pattern, whether a thing with almost the same name already exists somewhere else in the repository. There is the relationship drawing, which in a dense design means a lot of careful clicking to connect the right ends in the right direction with the right relationship type, and a lot of undoing when you connect the wrong ones. And then there is layout, which is the part everyone underestimates. A diagram that has been auto-arranged by the tool's default algorithm is usually a hairball. Making it readable — grouping related elements, straightening the flow, giving the eye a path through the picture — is a genuinely time-consuming activity that produces nothing except legibility, and legibility is the whole point of a diagram.

Because each of these steps is individually small and collectively large, they have a corrosive effect on the modelling itself. An architect who has just spent forty-five minutes transcribing one design is not enthusiastic about starting the next one, so the second design gets a lighter treatment. Alternatives that would have been worth modelling to compare them never get modelled, because modelling one option was tiring enough and modelling three to hold them side by side is out of the question. The model ends up recording the option that was eventually chosen and none of the reasoning that led there, because the reasoning lived in the discarded alternatives and nobody had the appetite to build them.

The manual transcription of a decided design is the least valuable hour in an architect's week, and it is the hour that quietly determines how much of the thinking ever makes it into the model at all.

Describe it, and let the tool build it

CelinQ offers an optional design assistant that lives inside Enterprise Architect and attacks exactly this gap between a decided design and its transcription. The interaction is deliberately plain. You select the package you want the work to land in. You describe, in ordinary language, what you want — the capability and the services that realise it, the shared component they depend on, the gateway in front. You ask for it to be built. And the elements and relationships are created directly in that package, as real model content, with the types and names and directions you described. This is not a sketch or a preview or a document that you then have to re-enter by hand. It is model. It has the same standing as anything you would have created by right-clicking, because it was created in the same repository through the same mechanisms; it is simply created by automation rather than by your own clicking.

The plain-language part matters more than it might seem, and it is worth being clear about what it is and is not. It is a convenience at the front door: instead of translating your intent into a long sequence of manual operations yourself, you state the intent and the automation performs the sequence. It is not a channel to some external oracle that decides the architecture for you. The design is still yours. You decided the decomposition; the assistant is the pair of hands that builds what you decided, quickly and without the transcription tax. If you describe a bad design, you will get a bad design built accurately. The judgement stays exactly where it always was, with the architect. What moves is the labour.

The part that earns trust: nothing gets duplicated

The first fear anyone sensible has about automated element creation is duplication. Repositories that have been worked on by several people over several years are riddled with near-duplicates already — two elements called almost the same thing, created by two architects who did not know the other existed, now both referenced by different diagrams and neither safe to delete. A tool that cheerfully created a fresh element every time you described something would pour petrol on that fire. Within a month you would have three "Identity Service" elements and no idea which one was the real one.

This is why the design assistant matches what it is about to create against what already exists in the model before it creates anything. When your description mentions a component that is already present in the repository, the automation recognises it and connects to the existing element rather than manufacturing a second one with a slightly different name. The new work attaches to the real model rather than growing a parallel copy of it. This is the difference between a tool that helps you build a model and a tool that helps you build a mess, and it is the single most important behaviour to get right. A generator that does not reconcile with existing content is not a time-saver; it is a debt machine that hands you the bill later, when someone has to work out which of the duplicates is authoritative.

It is also the behaviour that makes the assistant safe to use repeatedly on the same area. You can describe an addition to a design that already exists — a new service that plugs into the components you modelled last week — and the automation will wire it into those existing components rather than rebuilding the neighbourhood around it. The model accretes cleanly instead of forking every time you touch it.

And then it draws the picture

Creating the elements and relationships is half the value. The other half is that a diagram of the result is generated and laid out automatically. This is the part that most directly gives an architect their afternoon back, because layout is the tax that never ends. A diagram is not just a set of boxes and lines; it is a visual argument, and a badly arranged one obscures the very structure it is supposed to reveal. The automatic layout produces a picture that is readable as it stands — related things near each other, the flow going in a sensible direction, the eye given somewhere to start. It is not claiming to have artistic taste. It is claiming to save you from the twenty minutes of dragging that stand between a correct-but-unreadable auto-arrangement and something you can put in front of a colleague without apologising for it.

The result is that the loop from having an idea to seeing it as a legible model shrinks from an hour to a few minutes. And the shrinking is not merely faster; it changes what you are willing to do. When building a design costs an hour, you build the one you have already committed to. When it costs a few minutes, you can build the two alternatives you were weighing and actually look at them side by side, which is the thing you wanted to do all along and never had the patience for. The cheapness of the transcription is what makes the comparison possible, and the comparison is where the real architectural thinking happens.

Where honesty is required

It would be dishonest to present this as a machine that produces finished architecture from a sentence. It does not, and pretending otherwise would set exactly the wrong expectation. The assistant is very good at the mechanical labour — creating, typing, naming, connecting, reusing, laying out — and it is only as good as your description at the level of intent. A vague description produces a vague model, quickly. A description that is confused about the boundaries produces a model that is confused about the boundaries, quickly. The speed is real but it is speed at transcription, not a substitute for having worked out what you want.

This is actually the healthy framing, and it is the one experienced architects respond to. The tool does not ask you to trust it with the decisions. It asks you to make the decisions, as you always did, and then it removes the drudgery of writing them down. The output always lands as ordinary model content that you can inspect, correct, extend, and refactor with every normal tool you already use. Nothing about it is opaque or locked. If the automation named something in a way your team would not, you rename it. If it created a relationship you did not want, you delete it. The generated model has no special status that puts it beyond your editing; it is just model, and it is yours the moment it exists.

There is a further piece of honesty worth stating plainly, because architects working in regulated or sovereignty-conscious environments will ask about it immediately and are right to. The design assistant is optional and off by default. The core of CelinQ — the local-first repository, the background sync, the merge that keeps a team's work reconciled — works entirely without it. The assistant is something you turn on when it earns its place, not a dependency you have to accept to use the product. Everything can stay under your organisation's control, and the core needs no external service to function. The generation capability is a convenience layered on top of a platform that stands on its own, not the reason the platform exists.

The workshop, and the hour after it

To see where this fits into a real week, it helps to think about the workshop, because the workshop is where most designs are actually decided and where the transcription problem does its quietest damage. You spend two hours with stakeholders and by the end you have agreement on a shape — a capability, the services beneath it, the dependencies that matter, the boundary the business cares about. The picture is completely clear in your head and in the heads of the people who were in the room. And then everyone leaves, and the picture begins to fade, because a shared understanding held only in memory has a short half-life. The right time to capture it as model is the hour after the workshop, while it is still vivid. The trouble is that the hour after the workshop is precisely when you have the least appetite for an hour of manual transcription, because you are tired and the next meeting is at four.

So the capture slips. You promise yourself you will model it properly tomorrow, and tomorrow the picture is a little fainter, and by the time you actually sit down to build it you are reconstructing a design from notes and memory rather than transcribing one that is fresh. The model that results is thinner and less faithful than the agreement that was reached, not because anyone modelled badly but because the transcription tax fell due at the worst possible moment. Lower the cost of capture to a few minutes and the dynamic reverses. You can build the design in the room, or in the ten quiet minutes right after, while it is still whole in everyone's mind, and what lands in the model is the actual agreement rather than a degraded recollection of it. The value there is not really speed. It is fidelity, bought with speed.

What it does for the people who are not architects

There is a second-order effect worth drawing out, because it touches the perennial problem of getting non-modellers to engage with a model at all. A stakeholder who is fluent in their business but not in modelling notation cannot easily contribute to a model by editing it, and the traditional workaround — the architect transcribes what they say and shows it back later — introduces exactly the delay that lets a misunderstanding calcify. When a design can be built from a plain description in the moment, the conversation changes shape. You can say what you understood the stakeholder to mean, build it in front of them, and let them react to a concrete picture rather than to your promise of one. The correction happens immediately, against something real, rather than a week later against a diagram they struggle to read.

This does not turn stakeholders into architects, and it should not try to. The judgement about how to model something well remains the architect's, as it must. But the loop from "here is what I think you mean" to "no, not quite, it is more like this" collapses from days to minutes, and that loop is where most of the divergence between what stakeholders wanted and what got modelled actually creeps in. Closing it quickly, with real model content the architect still curates, is worth more than any amount of after-the-fact reconciliation between a diagram and a set of workshop notes that have already started to disagree with each other.

Why it belongs where the modelling happens

A reasonable person might ask why this has to live inside Enterprise Architect at all. Could you not describe a design somewhere else, get a picture, and copy it in? You could, and it would be nearly worthless, because the value is precisely in the elements being created directly in your package, as real content, matched against your real repository. A picture produced in a separate place is just a picture. It has none of the connective tissue that makes a model a model — the relationships that other diagrams rely on, the elements that other work can reference, the reuse that keeps the repository from splintering. The instant the output is real content in the real package, it is part of the fabric. It participates in the model's history, it can be governed and reviewed like anything else, and — because this is CelinQ — it syncs to the shared workspace along with everything else you do, so the design you generated at your desk is reconciled into the team's model exactly the way a hand-built design would be.

That last point closes the loop with the rest of the platform in a way that is easy to miss. The generation capability is not a bolt-on toy that produces content in a corner. It produces first-class model content in your local repository, and the local-first architecture then carries that content into the shared workspace through the same deterministic merge that handles all your other edits. A design you dictated in five minutes on a train, offline, is waiting to be reconciled with the team's model the moment you reconnect, indistinguishable in standing from anything anyone typed by hand. The speed at the front end and the safety at the back end are the same system.

What actually changes about the work

The honest summary is not that architects will do the same job faster, although they will. It is that the balance of the job shifts back toward the part that deserves the person. When transcription is expensive, an architect is a scarce expert spending a large fraction of their time as a data-entry clerk, and the model reflects that by being thinner than the thinking behind it. When transcription is cheap, the same architect spends their time deciding and comparing and refining, and the model gets thicker, because there is no longer a tax that discourages putting the supporting structure in. The alternatives get modelled. The neighbourhood around a decision gets filled in. The picture you show a stakeholder is legible on the first pass rather than after twenty minutes of tidying.

None of that requires the tool to be clever about architecture, and it is important that it does not pretend to be. It requires the tool to be reliable about labour: to create real content in the right place, to type and name and connect it correctly, to reuse what already exists rather than duplicating it, and to lay out a picture you can actually read. Those are unglamorous properties, and they are exactly the ones that turn an hour of transcription into a few minutes and give the hour back to the thinking. The design was always yours to make. The assistant just stops making you write it out by hand.

If there is a single test of whether a capability like this is worth having, it is this: does it make you model more of what you actually know, or does it tempt you to model things you have not thought through? Used as intended — as fast hands for a decided design, reconciling with the model you already have — it does the first. It lowers the cost of getting your real thinking into the repository, and it does so without loosening any of the discipline that keeps a shared model coherent. That is a narrow claim, deliberately, and it is the claim that holds up.