Enterprise Architecture as a working practice.

An EA platform only creates value inside a working practice. We design the operating model, the meta model and the governance around it, so that architecture becomes a reliable part of how your organisation plans and decides.

Learn More Discuss your practice

TOGAF & IT4IT Meta model design

Why the method matters

Whether an architecture practice succeeds is decided by its operating model, its meta model and its data quality, long before the choice of tool.

Architecture that is consulted

When architecture is part of portfolio planning, project intake and lifecycle decisions, teams involve it because it helps them reach better decisions faster.

A model you can maintain

We deliberately model less than the tool would allow. Every object type, relation and attribute has to justify itself through a question it answers and a person who maintains it.

Data people trust

Clear ownership, defined update cycles, data automation and measured quality keep the inventory accurate well beyond go-live.

Decisions that remain traceable

Documented principles, defined review paths and time-limited exceptions make architecture decisions reviewable for auditors, for successors and increasingly for AI systems as well.

What we do

From framework
to daily practice.

We cover the five elements that determine whether an architecture practice holds: its place in the organisation, its method, its model, the quality of its data and the way it makes decisions.

01EA operating model

A clear place in the organisation.

We define what your architecture function is accountable for and what it is not: the roles from enterprise architect to domain and solution architect, the decision rights, the mandate of the architecture board, and the interfaces to portfolio planning, demand management, project delivery and operations. Whether the setup is central, federated or mixed, it has to match how your organisation actually works.

What it gets youAn architecture function with a clear mandate and defined interfaces, involved early rather than after the fact.

Roles & decision rights
Architecture board
Central vs. federated
Process interfaces

Operating modelCharter

Where architecture sits.

MandateAdvise and decide

RolesEnterprise · domain · solution

BoardMonthly, decision‑empowered

InterfacesPortfolio · projects · ops

ShapeFederated, central standards

02Method & frameworks

Frameworks applied with judgement.

TOGAF, IT4IT and ArchiMate provide proven structure and a common vocabulary, but they are not necessarily meant to be implemented in full. We select the parts that answer your questions and document the result as a method your architects can follow: notation conventions, deliverable templates and the modelling depth for each layer.

What it gets youA documented, teachable method that fits the size and maturity of your organisation and is still applied after the training.

TOGAF
IT4IT
ArchiMate notation
Method documentation

Our methodv1.0

Distilled from TOGAF, IT4IT & ArchiMate.

Notation: a defined ArchiMate subset
Deliverables: standard templates, one page each
Modelling depth agreed per layer
Written in working language
~~Every element the frameworks define~~

03Meta model & data design

A meta model built from your questions.

The meta model determines what your practice can answer and what it costs to keep the data current. We derive it from the questions you need answered: which object types exist, how business capability, application, technology, data object and process relate to each other, which attributes are mandatory, and how deep the taxonomies need to go. We then implement the model in your platform and document it for the architects who work with it.

What it gets youA model that answers your actual questions, at a maintenance effort your team can sustain.

Object & relation design
Attributes & lifecycles
Taxonomies
Question-driven scoping

04Data ownership & quality

Data quality with clear ownership.

Architecture data loses accuracy unless it is actively maintained. We assign ownership per object type, define the collection processes and set up survey and review cycles that ask the responsible person a short, specific question at the right time. Quality is measured and reported: completeness per domain, overdue confirmations, orphaned objects and deviations from connected source systems.

What it gets youAn inventory that remains accurate after the initial project, with quality figures you can demonstrate at any time.

Ownership model
Survey & review cycles
Quality rules
Quality KPIs
Source-system alignment

SurveyQ3 cycle

Three questions to the application owner.

Is the application still in use by Sales & Service?
Is the lifecycle state still “Active”?
Are you still the responsible owner?

Time to answer90 seconds

Response rate94% this cycle

05Architecture governance

Documented architecture decisions.

We put architecture principles, standards and reference architectures in writing and define the path a change takes through them: when a review is required, who decides, which evidence is needed and how exceptions are granted with an expiry date. The same governance covers lifecycle and roadmap management, so that end-of-life decisions become visible before they cause incidents.

What it gets youFast decisions with a written trail, and a standards landscape that does not accumulate permanent exceptions.

Principles & standards
Review paths
Time-limited exceptions
Lifecycle & roadmaps

Decision recordNo. 041

Exception: legacy ESB remains in place for the order process.

DecisionApproved, with expiry

ExpiresQ2 2027

SuccessorIntegration platform

Decided byArchitecture board

Demanding scenarios

Where the practice
proves its value.

Some situations put architecture under particular pressure: company transactions, regulation, certifications and transformation programmes with fixed deadlines. In each of them, the outcome depends on whether the inventory is current and the method holds.

Transactions

Mergers, carve-outs and divestitures

Integrations and separations depend on knowing which applications, interfaces and data belong to which part of the business. We map both landscapes onto one capability model, analyse dependencies before systems are separated and support the exit from transitional service agreements.

EU regulation

Regulatory resilience

Regulations such as NIS2 and DORA make a maintained architecture inventory a supervisory requirement, from asset inventories to registers of ICT third-party providers. We structure the meta model so that these reports come directly from the repository.

Certification

Certifications and audit readiness

Certifications such as ISO 27001 or TISAX require documented processes, asset inventories with owners and controls whose application can be demonstrated. We connect these requirements with your repositories, so that audit evidence comes from maintained data.

Transformation

ERP transformation with a fixed deadline

Programmes such as the move to SAP S/4HANA come with process decisions as much as technology decisions. We provide the inventories of interfaces and ERP add-ons and the process baseline these programmes depend on.

Consolidation

Application portfolio rationalisation

Rationalisation fails when it remains a one-off exercise. We combine a capability-based assessment of the portfolio with the ownership and review cycles that keep decisions current and traceable.

AI regulation

AI governance under the EU AI Act

The EU AI Act requires organisations to know which AI systems they operate and which processes they affect. We record AI systems in your meta model with risk class, ownership and process linkage, and the same governance guides AI-assisted development.

One practice, three directions

The method is
the foundation.

EA, process management and AI-assisted software development build on the same basis: a model of the organisation that is agreed, current and understood. Established once, it supports both.

Process Management

Process architecture, modelling conventions and ownership, linked to the applications and capabilities your EA model already describes.

Explore process management

Agentic Engineering

AI agents deliver code quickly, but without context. Your meta model, principles and process models ensure that the results fit your landscape.

See how we ground it

Where do we stand?

An EA Health Check of operating model, meta model, data quality and governance, with prioritised recommendations.

Request an assessment

Independent of the tool

Method first,
then the platform.

We implement the method in the platform you operate, and we are open about cases where a lighter solution is sufficient. Meta model, governance and ownership come first; the tool configuration follows from them.

SAP LeanIXMeta model, surveys and governance configured to the method.

SAP SignavioProcess layer linked to the architecture model.

BizzdesignAlfabet and Unify, including ArchiMate-based modelling.

Tool selectionRequirements and criteria derived from your method, not from a feature list.

Existing landscapeWe work with the platform you already own before proposing a new one.

EnablementRole-based training, so the method remains effective after handover.

Sound familiar?

Where does your
practice stand?

Whether you are establishing an architecture practice, restarting one that has stalled or consolidating a model that has grown too large to maintain, we assess the current state and define a practical way forward.

Talk to our EA experts

“We have the tool, but nobody knows what to put into it.”

“Our meta model has 40 fact sheet types. We use six of them.”

“The data has not been maintained since go-live.”

“None of the exceptions we granted ever expired.”

“We learn about project decisions after they have been made.”