CelinQ Insights · No. 63

Prompt to ArchiMate: generating layered Sparx EA models through CelinQ

ArchiMate rewards discipline more than any other notation Sparx EA supports — which is exactly why a prompt cannot be allowed to bypass it.

ArchiMate is, among the notations Sparx Enterprise Architect supports, unusually strict about what is allowed to connect to what. A Business Process can serve an Application Service; an Application Component can realise an Application Service; a Technology Service can be used by an Application Component. The layers — business, application, technology, and the motivation, strategy and implementation extensions around them — are not decoration. They encode a set of relationship rules that exist precisely so that an ArchiMate diagram means the same thing to every trained reader who looks at it, across organisations, without anyone having to ask the author what they intended. That rigour is the whole value of the notation. It is also exactly the property that makes naive AI-assisted generation more dangerous for ArchiMate than for almost any other kind of modelling content, because a plausible-sounding relationship between two ArchiMate concepts is not automatically a legal one, and an AI system generating free-form output has no inherent reason to know the difference.

This article looks specifically at what it takes to generate ArchiMate content from a prompt without quietly degrading the notation's own rigour in the process — the same underlying pipeline described in AI for Sparx Enterprise Architect and walked through for a generic architecture in generating a model from a prompt, applied here to a notation that is considerably less forgiving of small mistakes than UML component diagrams tend to be.

Why ArchiMate is the harder case

A UML component diagram tolerates a certain amount of looseness. A dependency arrow between two components communicates roughly the right idea even if the precise UML semantics of "dependency" versus "realization" are not observed with total rigour, because most readers of a component diagram are reasoning informally about the architecture rather than parsing the notation formally. ArchiMate readers, by contrast, are frequently doing the opposite: an experienced ArchiMate practitioner reads a "serving" relationship and a "realization" relationship as meaning genuinely different things, and a diagram that used the wrong one is not a stylistic quibble, it is a diagram that says something false about the architecture. Layer violations are worse still. An Application Component directly realising a Business Process, skipping the Application Service that should sit between them, is not merely untidy — in a strict ArchiMate reading it misrepresents how the business actually depends on the application landscape, and anyone building an impact analysis off that diagram inherits the error silently.

This is the reason a request such as "model the online banking capability with a business process, the mobile app that supports it, and the core banking system behind it" cannot be handled the same way a generic component-and-connector request is handled. The words in the sentence map naturally onto Business Process, Application Component and Application Component (or Technology Service, depending on how "core banking system" is meant), but the relationships between them have to be chosen correctly — serving, realization, assignment, triggering, flow — or the resulting diagram is ArchiMate in appearance only, wrong in exactly the way that matters to the people who will actually rely on it.

Mapping the banking example concept by concept

It is worth slowing down on that banking request and tracing exactly how each phrase becomes a typed ArchiMate construct, because the mapping step is where most of the risk in ArchiMate generation actually lives, and seeing it done carefully is more convincing than describing it abstractly. "Online banking capability" is a business-layer notion, and depending on how your organisation models capabilities it becomes either a Business Function or, more commonly in a process-oriented repository, a Business Process — "Confirm Order" style granularity rather than an abstract capability box, because most EA repositories used day to day favour concrete processes over the more abstract Motivation-extension capability concept. "The mobile app that supports it" is application-layer: an Application Component representing the mobile app itself, and because a business process is served rather than realised by application content, the relationship from an Application Service the component provides back up to the business process should be typed as serving, not as a more direct — and layer-skipping — relationship straight from the component.

"The core banking system behind it" is the phrase that most needs care, because "behind it" is doing a lot of unstated work. Read literally it could mean an Application Component the mobile app talks to, or it could mean a Technology Service the core banking application itself depends on. A generation step that guesses wrong here still produces a formally valid ArchiMate diagram, because both readings are legal — it simply models the wrong architecture, which is precisely the failure mode structural validation cannot catch, because structural validation only refuses illegal constructs, not legal-but-mistaken ones. This is exactly the ambiguity the review step is for: the proposal has to pick one reading to build, and the preview is where an architect who actually knows whether "core banking system" means an application or the infrastructure underneath it corrects the choice before it becomes a revision. Ambiguity of this kind is not a defect in the generation step; it is a property of natural language that no amount of type-mapping discipline removes, and pretending otherwise would be the least honest thing this article could claim.

What stays deterministic, and what does not

The honest way to describe how CelinQ approaches this is to separate two things that are easy to blur together: choosing an element or relationship type, and judging whether a proposed architecture is a good one. The first is a mapping problem — given a concept in your description, which ArchiMate type does it correspond to, and given two related concepts, which relationship types are legal between elements of those types in ArchiMate's own rules. That mapping is deterministic. It does not depend on the AI's judgement at generation time so much as on a fixed correspondence between EA's internal element types and their ArchiMate meaning, which is exactly the kind of thing that belongs in code rather than in a language model's discretion, because it should never vary between one request and the next asking for the same concept.

What is not deterministic, and does not pretend to be, is whether "a business process served by an application service" is the correct way to model your specific banking capability rather than, say, a business function decomposed differently, or whether the mobile app genuinely deserves its own Application Component rather than being represented as a channel on an existing one. That is architectural judgement, resting on knowledge of your specific domain that no generation step has access to, and it is exactly the kind of decision the review stage exists to catch, not something the type mapping can or should resolve on its own.

Relationship validation as part of the same gate

A proposal that would create an illegal ArchiMate relationship — a Technology Component "serving" a Business Actor directly, skipping every intervening layer, for instance — is exactly the kind of structural problem the validation stage described in the AI positioning article and in the series' coverage of semantic conflict resolution is designed to catch before you ever see a preview. The same discipline that checks whether a relationship's endpoints resolve to real entities and whether containment forms a cycle is the natural place to enforce ArchiMate's own layering and relationship-legality rules, because both are structural constraints the model itself carries, independent of whoever or whatever proposed the change. Where that enforcement today is strongest is on the constraints CelinQ's shadow validation already applies to every ChangeSet regardless of notation — parents exist, endpoints resolve, no containment cycles, identity stays unique — and extending that same validated-changeset path with ArchiMate-specific relationship-legality checks is the natural direction for a notation this exacting, run through the identical gate rather than a separate, notation-specific one bolted on beside it.

This distinction matters practically. It means that even while that extension matures, the burden of catching a layer violation does not fall solely on an architect's memory of ArchiMate's relationship matrix during review — the same deterministic gate that already refuses structurally broken proposals is where such a rule belongs, and it is where it is designed to live rather than as an AI-side promise to "try to get ArchiMate right," which is a much weaker guarantee than a validation rule that either passes or refuses.

Viewpoint awareness in practice

ArchiMate viewpoints are lenses — a Layered Viewpoint that shows all three layers together, an Application Cooperation Viewpoint that focuses on how application components interact, a Business Process Cooperation Viewpoint that stays within the business layer. A request that says "show me how the mobile app cooperates with the core banking system" is implicitly asking for something closer to an Application Cooperation Viewpoint than a full layered diagram, and a generation capability that ignores that implicit framing produces a diagram that is technically correct but visually noisy, burying the two elements the architect actually cares about in a scatter of business and technology content nobody asked to see.

The pattern worth aiming for — and the one the diagram-generation stage of the pipeline is built toward — is that the scope of what gets included in the generated diagram, as opposed to what gets created in the model, should follow the viewpoint implied by the request. The full set of proposed elements and relationships still gets created as real model content, because a viewpoint is a way of looking at the model, not a restriction on what the model may contain, but the diagram that accompanies the proposal can stay focused, showing the cooperation the request was actually about and leaving the wider layered context to the elements' own relationships rather than cluttering a single picture with everything.

An ArchiMate diagram is not just accurate or inaccurate. It is legible against a specific viewpoint, or it is not, and generation that ignores viewpoint framing trades a notation's discipline for a wall of correct but unreadable boxes.

Motivation and strategy content, handled more cautiously

Business, application and technology are the three layers most generation requests actually touch, because most requests describe a landscape of things that do work, rather than the reasons behind them. ArchiMate's motivation extension (Stakeholder, Driver, Goal, Requirement, Principle) and its strategy extension (Resource, Capability, Course of Action) sit at a different level of abstraction, and a request that reaches into that territory deserves more caution from a generation capability than one describing components and services. "Add a goal that customer onboarding should take under five minutes, driving a requirement for the mobile app to support instant verification" is a perfectly reasonable ArchiMate request, and the type mapping for Goal, Driver and Requirement is no less deterministic than the mapping for Application Component. What changes is the density of judgement packed into the relationship between a Goal and the Requirement that realises it, or between a Driver and the Goal it motivates — these relationships often encode a genuine strategic argument, not a structural fact about a system landscape, and an architect reviewing a motivation-layer proposal should expect to spend more time checking whether the argument the relationships imply is the one that was actually agreed, rather than only whether the relationship types are legal.

This is not a reason to avoid generating motivation and strategy content — the same transcription saving applies, and a Requirement that already exists in the model can be referenced by a new Realization relationship exactly as an existing Application Component can. It is a reason to treat the review step for this category of content with the seriousness that a strategic claim deserves, rather than the lighter check that a straightforward "component calls component" proposal might reasonably get. The pipeline does not distinguish between these cases by slowing itself down automatically; the distinction has to come from the architect doing the reviewing, who knows that a Goal-to-Requirement relationship is a claim about intent in a way a Component-to-Service relationship usually is not.

Iterative refinement inside a notation with rules

Refining an ArchiMate proposal through follow-up prompts works the same way it does for any generation request, with one added benefit: because the type mapping and relationship legality are deterministic, a follow-up request such as "add a Technology Service between the Order Application component and the database, instead of a direct access relationship" produces a proposal that is checked against the same ArchiMate rules as the original, so an architect steadily tightening a diagram towards proper layering gets the same validation guarantees at every step rather than only at the first one. This matters for teams gradually introducing ArchiMate discipline into a repository that has historically been looser — the tool does not get more permissive as the conversation goes on, which is precisely the property you want from something meant to uphold a notation's rigour rather than merely produce its first draft.

Where this connects to the rest of your model

ArchiMate content generated this way is not an island. The Order Service in the example above may already exist as a UML interface documented elsewhere in the repository, or the Core Banking System may already be modelled as a technology node with its own set of relationships to infrastructure content nobody described in the prompt at all. The same context-retrieval and reuse discipline covered in the walkthrough of generating a model from a prompt applies here without modification: a proposal that can recognise an existing element by name attaches to it rather than creating a parallel ArchiMate-flavoured duplicate of something that already has a UML-flavoured life elsewhere in your repository. Getting this right is arguably more important in ArchiMate work than anywhere else in the series, because ArchiMate repositories tend to accumulate cross-notation duplication precisely at the seams where a business-and-application view was bolted onto an existing, more technical model built by a different team with a different notation habit.

Traceability back to what prompted the generation also matters more here than in a looser notation, because ArchiMate content is frequently produced to support a specific governance artefact — a capability map, a target-state review, a technology roadmap — and someone will eventually ask why a particular relationship exists. Because the proposal that produced it is expressed in exactly the same modelling terms the final content takes, and because it is recorded as a canonical revision in the ordered history the moment it is approved, tracing a generated relationship back to the request that produced it and the person who approved it is a matter of reading the revision record, not reconstructing a decision from memory. A layered ArchiMate model built up this way is also a natural candidate for the kind of standing analysis covered in AI-assisted model analysis — orphaned Application Services, Business Processes with no Application layer support underneath them, the sort of layering gap that is easy to miss diagram by diagram and much easier to catch with a pass over the whole repository.

The honest limits

It would be dishonest to claim that a deterministic type mapping and a validation gate turn ArchiMate generation into something an architect can approve without ArchiMate expertise of their own. They do not, and they are not meant to. The mapping ensures that whatever relationship type is proposed is one that ArchiMate actually recognises between concepts of those two kinds; it says nothing about whether that relationship, however legal, is the one your specific business capability actually needs. A proposal can be entirely free of layer violations and still misrepresent your architecture, because "legal" and "correct" are, as with any notation, different properties, and only the second one requires the judgement of someone who understands both ArchiMate and the domain being modelled. The review stage exists for exactly this reason, and it asks more of the reviewer here than it does for a looser UML sketch, precisely because ArchiMate readers hold the notation to a higher standard and will notice a subtle relationship-type mistake that a looser diagram would have hidden.

There is a narrower technical limit worth naming plainly too: the relationship-legality checking this article describes as belonging in the deterministic validation gate is, for parts of ArchiMate's fuller rule set, a direction the same validated path is built to carry rather than a claim that every nuance of the specification is already enforced today. Where that is the case, the review step is doing more of the work than it eventually will need to, and an architect reviewing ArchiMate proposals should apply the same scrutiny to relationship choices they would apply to a colleague's freehand diagram, rather than assuming the notation's discipline is being fully enforced automatically. That is not a reason to avoid the capability — the mechanical transcription it removes is real and considerable, and the type mapping underneath it is genuinely deterministic and genuinely tested — but it is a reason to keep the review honest rather than reflexive, in a notation where a small mistake carries more weight than in most others Sparx EA supports.

None of this is available unless AI has been explicitly enabled for the workspace by an administrator, and a workspace working under Sovereign mode or restricted policy can keep it disabled entirely while continuing to model in ArchiMate exactly as it always has, by hand, through EA's own palette. What changes when it is enabled is not the rules ArchiMate holds you to — those do not move — but how quickly a correctly-typed, correctly-connected first draft of a layered architecture can exist for you to refine, argue about, and eventually trust.

Teams that have spent years persuading colleagues to respect ArchiMate's layering in the first place have a particular reason to care about this distinction between deterministic mapping and human judgement. The discipline of the notation was hard-won, usually through a slow accumulation of reviewed diagrams and corrected habits rather than a single training session, and it is exactly the kind of discipline that erodes quietly if a generation capability is trusted a little too far, a little too often, without the review it was built to require. Used with that review intact, ArchiMate generation through CelinQ does the opposite: it lowers the cost of producing a first draft that already respects the layering, which makes it easier, not harder, to hold the rest of the team to the same standard, because the tedious part of getting the types and relationships right the first time is no longer the reason people cut corners.