Enterprise Architecture as a working practice.

An EA platform only creates value within a working practice. We design the operating model, the meta-model, and the governance framework surrounding them so that architecture becomes an integral part of how your organization plans and makes decisions.

Learn More Discuss your practice

TOGAF & IT4IT Meta-model design

Why the Method Matters

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

Architecture that is consulted

When architecture is incorporated into portfolio planning, project intake, and lifecycle decisions, teams include it because it helps them make better decisions more quickly.

A model you can maintain

We deliberately model less than the tool would allow. Every object type, relationship, and attribute must justify its existence through a question it answers and a person who maintains it.

Data People Trust

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

Decisions that can be traced

Documented principles, defined review processes, and time-limited exceptions ensure that architectural decisions can be reviewed by auditors, successors, and, increasingly, AI systems as well.

What We Do

From framework
to daily practice.

We cover the five elements that determine whether an architecture practice is effective: its role within the organization, its methodology, its business model, the quality of its data, and its decision-making process.

01EA Operating Model

A clear role within the organization.

We define what your architecture function is responsible for and what it is not: the roles ranging from enterprise architect to domain and solution architect, the decision-making authority, the mandate of the architecture board, and the interfaces to portfolio planning, demand management, project delivery, and operations. Whether the structure is centralized, federated, or a hybrid model, it must align with how your organization actually operates.

What You Get: Anarchitecture function with a clear mandate and defined interfaces, brought in early rather than after the fact.

Roles & Decision-Making Authority
Architecture Board
Central vs. Federated
Process Interfaces

Operating ModelCharter

Where architecture belongs.

MandatesAdvise and Decide

RolesEnterprise · Domain · Solution

BoardMonthly, decision-empowered

InterfacesPortfolio · Projects · Operations

ShapeFederated, centralized standards

02Methods & Frameworks

Frameworks applied with discernment.

TOGAF, IT4IT, and ArchiMate provide a proven structure and a common vocabulary, but they are not necessarily intended to be implemented in their entirety. We select the components that address your needs and document the result as a methodology your architects can follow: notation conventions, deliverable templates, and the level of detail for each layer.

What You Get: Adocumented, teachable method that is tailored to the size and maturity of your organization and continues to be applied after the training.

TOGAF
IT4IT
ArchiMate notation
Method documentation

Our Methodv1.0

Based on TOGAF, IT4IT, and ArchiMate.

Notation: a defined ArchiMate subset
Deliverables: standard templates, one page each
Modeling depth agreed upon for each layer
Written in the working language
~~Every element defined by the frameworks~~

03Meta-model & Data Design

A meta-model built from your questions.

The meta model determines what your practice can address and what it costs to keep the data up to date. We derive it from the questions you need answered: what types of objects exist, how business capabilities, applications, technologies, data objects, and processes relate to one another, which attributes are required, and how detailed the taxonomies need to be. We then implement the model in your platform and document it for the architects who will be working with it.

What You Get: Amodel that answers your actual questions, with a maintenance effort your team can sustain.

Object-Relational Design
Attributes & Lifecycles
Taxonomies
Question-driven scoping

04Data Ownership & Quality

Data quality with clear accountability.

Architecture data loses accuracy unless it is actively maintained. We assign ownership by object type, define the collection processes, and establish survey and review cycles that prompt the responsible person to answer a short, specific question at the right time. Quality is measured and reported: completeness by domain, overdue confirmations, orphaned objects, and discrepancies with connected source systems.

What You Get: Aninventory that remains accurate even after the initial project is complete, with quality metrics you can provide at any time.

Ownership Model
Survey and review cycles
Quality Rules
Quality KPIs
Source System Alignment

SurveyQ3 cycle

Three questions for 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 architectural decisions.

We document architectural principles, standards, and reference architectures, and define the process a change must follow: when a review is required, who makes the decision, what evidence is needed, and how exceptions are granted with an expiration date. The same governance framework covers lifecycle and roadmap management, ensuring that end-of-life decisions are identified before they lead to incidents.

What you get: Quickdecisions with a written record, and a standards framework that doesn't accumulate permanent exceptions.

Principles & Standards
Review paths
Time-limited exceptions
Lifecycle & Roadmaps

Decision RecordNo. 041

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

DecisionApproved, with an expiration date

ExpiresQ2 2027

SuccessorIntegration platform

Decided byArchitecture Board

Challenging scenarios

Where the practice
proves its worth.

Certain situations place architecture under particular pressure: corporate transactions, regulations, certifications, and transformation programs with fixed deadlines. In each of these situations, the outcome depends on whether the inventory is up to date and the method is sound.

Transactions

Mergers, carve-outs, and divestitures

Integration and separation depend on knowing which applications, interfaces, and data belong to which part of the business. We map both landscapes onto a single capability model, analyze dependencies before systems are separated, and support the transition out of transitional service agreements.

EU regulation

Regulatory Resilience

Regulations such as NIS2 and DORA require supervisory authorities to maintain an architecture inventory, ranging from asset inventories to registers of third-party ICT providers. We structure the metamodel so that these reports are generated directly from the repository.

Certification

Certifications and Audit Readiness

Certifications such as ISO 27001 or TISAX require documented processes, asset inventories that include owners, and controls whose implementation can be demonstrated. We integrate these requirements with your repositories so that audit evidence is derived from up-to-date data.

Transformation

ERP Transformation with a Fixed Deadline

Programs such as the migration to SAP S/4HANA involve process decisions just as much as technology decisions. We provide the inventories of interfaces and ERP add-ons, as well as the process baseline on which these programs depend.

Consolidation

Rationalization of the application portfolio

Rationalization fails when it remains a one-time exercise. We combine a capability-based assessment of the portfolio with ownership and review cycles that ensure decisions remain up-to-date and traceable.

AI regulation

AI Governance Under the EU AI Act

The EU AI Act requires organizations to know which AI systems they operate and which processes those systems affect. We document AI systems in your meta-model, including their risk class, ownership, and process linkages, and the same governance framework guides AI-assisted development.

One practice, three directions

The method is
the foundation.

EA, process management, and AI-assisted software development are all built on the same foundation: a model of the organization that is agreed upon, up-to-date, and well-understood. Once established, it supports both.

Process Management

Process architecture, modeling conventions, and ownership, as they relate to the applications and capabilities already described in your EA model.

Explore Process Management

Agentic Engineering

AI agents generate code quickly, but without context. Your meta-model, principles, and process models ensure that the results align with your environment.

See how we handle it

Where do we stand?

An EA health check of the operating model, meta model, data quality, and governance, with prioritized recommendations.

Request an assessment

Independent of the tool

First the method, th
, then the platform.

We implement the method on the platform you use, and we are transparent about situations where a simpler solution is sufficient. The meta-model, governance, and ownership come first; the tool configuration follows from them.

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

SAP SignavioProcess layer linked to the architecture model.

BizzdesignAlfabet and Unify, including ArchiMate-based modeling.

Tool SelectionRequirements and criteria derived from your method, not from a list of features.

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

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

Does that sound familiar?

How is your "
" practice coming along?

Whether you are starting an architecture firm, reviving one that has stalled, or streamlining a firm that has grown too large to manage, we assess the current situation and outline a practical path forward.

Talk to our EA experts

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

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

“The data has not been updated since the system went live.”

“None of the exceptions we granted ever expired.”

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