A Metamodel That Reflects the Business

The starting point

The organisation, active in the energy sector, had been running Sparx Enterprise Architect for about four years when we were asked to look at it. On paper the practice was healthy: a shared repository on SQL Server, around thirty people with modelling licences spread across enterprise architecture, integration and data teams, and a steady stream of diagrams feeding project documentation. The tool was not the problem. The problem surfaced the first time senior management asked the repository a question.

The question was a reasonable one: which applications support our metering-to-billing chain, and what would it cost us in dependencies if we replaced the oldest of them? The architecture team spent the better part of two weeks assembling an answer, and most of that time went into arguing about what the model actually said. The same application existed in three places under three names. Relationships that should have carried the answer simply were not there, or were there five different ways. The repository could render hundreds of diagrams, but it could not answer a question, and a repository that cannot answer questions is an expensive drawing archive.

We were brought in to fix the foundations rather than the symptoms: to define, together with the people who would live with it, a metamodel that reflected the business the organisation is actually in — and then to make Sparx EA enforce as much of it as the tool allows.

What we found when we looked

Before proposing anything we spent a week reading the repository, using model searches and a handful of scripts over the automation API to profile what was really in there. The numbers were not unusual for an installation of this age: several thousand elements, close to a thousand diagrams, and a long tail of packages nobody had opened in years. What mattered was not the volume but the variety.

One flagship application appeared as an ArchiMate Application Component in the enterprise architecture packages, as a UML Component in the integration team's models, and as a stereotyped Class in an older data package — three elements, three names, no relationships between them. Tagged values told the same story. Ownership was recorded under Owner, owner, App Owner and Responsible, depending on who had created the element and in which year. Some teams recorded lifecycle status; most did not; two teams recorded it with incompatible value lists. None of this was carelessness. Each team had made locally sensible decisions in the absence of a shared definition of what a thing was and what you were supposed to say about it.

We also found genuine quality in the middle of the noise: the integration team's interface models were detailed and current, and the data team maintained a conceptual model that the business actually recognised. A cleanup that flattened everything to a lowest common denominator would have destroyed real value. Whatever we designed had to give these teams a home, not a haircut.

Why the out-of-the-box metamodel fell short

Sparx EA ships with the full ArchiMate language, the full UML, BPMN and a dozen other notations, and that abundance was precisely the issue. ArchiMate alone offers more than fifty element types. Ask thirty modellers to describe an energy company with fifty types and no further guidance, and you will get thirty dialects — all technically valid, none interoperable.

The deeper mismatch was vocabulary. The business runs on concepts the standard palette does not name: installations and metering points, market processes with regulated deadlines, market roles such as grid operator and supplier and balance responsible party, flexibility services traded on markets that did not exist ten years ago. Modellers were forced to improvise a mapping every time — one chose Business Object for a metering point, another chose Node because the physical device felt like infrastructure, and both were defensible. When the mapping lives in individual heads, every model is a private translation, and translations drift.

The fix was therefore not more training on notation, and we said so early. Training thirty people to make the same fifty-way choice consistently is a losing game. The winning game is to shrink the choice: agree on the concepts once, name them in business language, decide which attributes each must carry, and configure the tool so that the agreed palette is the path of least resistance.

How we set up the engagement

Metamodel work touches everyone who models, so we spent the first two weeks on structure rather than content. We interviewed the lead of each modelling team for an hour, asking the same three questions: what do you record in the repository, who consumes it, and where does the current setup make you improvise? Those interviews produced the stakeholder map for the workshops and, just as usefully, a list of improvisations — the places where people had invented local conventions because no shared one existed. Nearly every card that later survived the workshops traced back to one of those improvisations.

On the technical side we took a full project transfer of the repository into an offline copy and did all profiling and later all migration rehearsal there, never against the live database. The profiling scripts walked packages over the automation API and wrote element counts, stereotype usage, tagged value spellings and relationship type frequencies into a set of spreadsheets. Putting those spreadsheets on the wall in the first workshop had an effect no slide deck achieves: the teams saw their four spellings of Owner in one column and laughed, and from that point the exercise was collaborative rather than defensive. We also agreed the ground rules early — the metamodel would be decided in the workshops and nowhere else, existing content would be migrated by script wherever a rule could decide, and no team's working models would be frozen while the design ran.

Designing the metamodel in workshops

We ran the design as a series of six half-day workshops over roughly two months, deliberately mixing populations: enterprise architects, the integration and data leads, two solution architects from delivery projects, and — this proved decisive — people from the business side of market operations and asset management who had never opened a modelling tool. A metamodel designed only by modellers reflects the tool. We wanted one that reflected the business, and that meant the business had to be in the room.

Each workshop worked backwards from questions, not forwards from notation. We collected the questions the organisation had recently failed to answer — the metering-to-billing question among them, alongside audit requests and a technology renewal discussion — and asked, for each: what concepts must exist in the model, with what attributes and what relationships, for this question to be answerable by a search rather than a meeting? Proposed concepts went up as cards. Every card had to survive three tests: a one-sentence definition everyone accepted, a named example from the real estate of systems, and a stated reason someone would query it. Concepts that failed went to a parking lot, and most stayed there.

The arguments were the point of the exercise. Asset management and IT discovered they meant different things by installation; settling that definition took forty minutes and was worth more than any diagram we drew that month. By the final workshop we had a concept catalogue the participants felt they owned — which mattered later, because a metamodel imposed from outside gets worked around, while one people argued into existence gets defended.

The concepts that made the cut

The agreed metamodel ended up with nineteen concepts — deliberately few. Each is defined in business language, mapped to an ArchiMate base type so that standard viewpoints and exchange formats keep working, and carries a short list of required attributes implemented as tagged values. A sample of the core:

Just as important as the concepts were the relationship rules: an Application realises Application Services, serves Market Processes, and accesses Data Objects; an Integration links one providing Application to one consuming Application through flow relationships and must name the Data Objects it carries; a Market Process must be assigned to a Market Role. Rules like these are what turn a drawing convention into a queryable structure, because every rule is also a search: any Integration that does not name its data is a defect the repository can list by itself.

The diagram above is the actual centrepiece we worked from: capabilities from the strategy layer above the market processes, applications and integrations beneath them, data objects and the installation concept alongside, with the allowed relationships drawn once and argued over until they were right. Everything else in the metamodel hangs off this picture.

From whiteboard to MDG Technology

A concept catalogue in a document changes nothing about Monday morning. The catalogue had to become the tool's default behaviour, and in Sparx EA the vehicle for that is an MDG Technology: a packaged extension holding stereotypes, tagged values, toolboxes and diagram types.

We built a UML profile in which each concept is a stereotype extending its ArchiMate base type, with the required attributes defined as tagged values — with sensible defaults and, where the workshops had agreed a value list, an enumerated type so that lifecycle can only ever be one of the five agreed states. On top of the profile we defined four custom diagram types matching the viewpoints the organisation actually uses, each with its own toolbox showing only the concepts that belong on that view. A modeller opening a Landscape diagram sees eight tools, not eighty. We also configured quick-linker rules so that dragging a connection from an Application towards a Market Process offers serves and nothing else.

The MDG Technology is versioned and deployed from a shared location that every EA client references, so a release lands on all thirty desks the next time EA starts. Alongside it we configured the standard model validation and wrote additional checks with the scripting engine for rules the validator cannot express — the Integration-must-name-its-data rule among them. The scripts run on a schedule, from a command-line EA instance on the automation server, and write their findings to a report, which turned out to matter more than the interactive validation, for reasons covered below.

Four diagram types, not forty

Choosing the diagram types deserved and got its own workshop, because views are where a metamodel meets its audience. We asked each consumer group — management, delivery projects, integration, operations — what decision they take with a diagram in front of them, and defined a view for each answer. The result was four: a Landscape view showing capabilities with the applications that serve them, used in portfolio discussions; an Integration view showing applications, integrations and the data they carry, used in impact analysis and solution design; a Market Process view connecting market roles, processes and supporting applications, used with the business; and an Asset view relating installations to the systems that monitor and control them, used with operations.

Each view is a custom diagram type in the MDG with its own toolbox, and each has a one-page description in the repository stating what belongs on it, what does not, and who its audience is. That last discipline sounds bureaucratic and is anything but: the moment a view has a named audience, arguments about what to show resolve themselves, because the question stops being what the modeller finds interesting and becomes what the audience needs to decide. Views that could not name an audience in the workshop did not become diagram types — which is how we ended at four rather than the forty the full palette invites.

Migrating what already existed

The repository already held years of content, and the new metamodel would have died on arrival if adopting it had meant remodelling from scratch. So migration was scripted from the start. Working over the automation API, we took a baseline of every affected package, then reclassified elements in bulk: matching on type, stereotype and naming patterns, mapping old stereotypes to new ones, folding the four spellings of ownership into the one agreed tagged value, and normalising value lists where a mapping was unambiguous.

Roughly four out of five elements converted cleanly by rule. The remainder — a few hundred elements where the script could not decide whether a thing was an Application or an Application Service, or which of two duplicate elements was the survivor — went into a review queue, package by package, that the owning teams worked through in short sessions over a few weeks. Duplicates were merged rather than deleted, with relationships and diagram occurrences re-pointed to the surviving element so that no diagram silently lost its content. The integration team's detailed interface models and the data team's conceptual model came through intact, re-stereotyped but structurally untouched, which repaid the early decision to design the metamodel around existing strengths.

Verification was as scripted as the migration itself. Every run wrote a before-and-after count per package — elements by stereotype, relationships by type, tagged values populated — and we compared the two mechanically rather than by eye. We rehearsed the full migration three times against the offline copy before touching the live repository, and the rehearsals earned their keep: the second run uncovered a batch of elements whose stereotype lived in a legacy profile with the same name but a different profile identifier, which the mapping had silently skipped. On diagrams we checked fidelity the unglamorous way, opening a sample of the most-used ones next to their baseline export and confirming nothing had visually moved or vanished. Bulk changes to element types are exactly the kind of operation that looks successful in a log and is wrong on one diagram someone presents to a steering committee a week later, so we treated the log as a claim and the sample as the evidence.

Keeping the metamodel alive

A metamodel is a living agreement, and agreements decay without maintenance. Two mechanisms keep this one alive. The first is a named owner: one senior architect is accountable for the metamodel, collects change proposals in a dedicated package in the repository itself, and convenes a short review every quarter. Accepted changes ship as a new MDG release with release notes; rejected ones get a recorded reason. In the first year the metamodel changed four times — two new attributes, one new concept from the parking lot, one relationship rule relaxed because practice proved it too strict. That rhythm is healthy. A metamodel that never changes is being ignored, and one that changes monthly was never finished.

The second mechanism is the weekly conformance report. The scheduled scripts check every package against the relationship and attribute rules and send each package owner a short list of their own defects: elements missing an owner, integrations that do not name their data, relationships outside the allowed set. The lists are short because they arrive weekly — nobody accumulates a hundred defects in a week — and that keeps them actionable. Within a few months the reports had become the quiet backbone of quality: not a gate anyone had to pass, just a mirror nobody could argue with.

What changed for the client

The metering-to-billing question that started the engagement now takes minutes: it is a model search across the serves and accesses relationships and the integration hops between the applications involved, and the answer comes back as a table with owners and lifecycle status attached, generated straight from the repository through the document templates. The same is true of the questions behind audit requests and renewal planning, because the workshops designed the metamodel from exactly those questions.

Adoption told the same story from the other side. New modellers become productive in days rather than months, because the toolbox offers only what is allowed and the quick-linker steers every connection to a legal one; there is far less to know before your first correct diagram. Cross-team friction dropped for a less obvious reason: the teams now disagree about content, which is useful, instead of disagreeing about representation, which never was. And management started trusting repository output enough to ask it more questions — the surest sign a modelling practice has turned a corner.

A quieter change followed in documentation. Because every Application now carries the same tagged values and the same relationship types, the document templates could finally be written once and reused: a solution design pack pulls the Integration view, the affected data objects and the owner table for any application in the estate, and the generated document is identical in structure whichever team produces it. Two report templates the client had abandoned years earlier — an application passport and an interface register — came back to life within a month of the migration, not because anyone rebuilt them but because the content they depended on finally existed in one predictable shape. Our Sparx EA consulting work increasingly starts from exactly this symptom: a repository full of content that answers nothing.

What we would do differently

Two lessons are worth stating plainly. The first concerns enforcement, and it is a genuine limitation of the platform: Sparx EA cannot make an agreed metamodel mandatory. Quick-linker rules guide, toolboxes suggest, and model validation flags, and MDG metamodel constraints veto many illegal connections outright — but the guardrails have edges: imported content, script-created elements and a modeller who switches perspective all pass beneath them, and validation only speaks when asked. This is why the scheduled conformance scripts are not an optional extra. In this kind of setup the honest statement is that the MDG makes conformance easy and the reports make deviation visible, and that combination — not the tool — is the enforcement.

The second lesson is about size. We held the line at nineteen concepts at design time, twenty after the parking-lot promotion, and still, a year on, two of them see little use. Had we accepted every plausible card in the workshops we would have passed thirty, and the migration effort and validation surface would have grown with them. Start smaller than feels complete. It is far cheaper to promote a concept from the parking lot next quarter than to retire one that three hundred elements already depend on.

If your repository has grown into several dialects of the same landscape and you are weighing a tailored metamodel against another round of training, we have run this kind of engagement in several sectors — you can reach us through our contact page.

This case study describes a representative engagement pattern. Organisational details are illustrative and do not identify a specific client.