📘 Tutorial: ArchiMate 3.2 — Kapitel 4: Generisches Metamodell

🌟 Einführung

Kapitel 4 der ArchiMate 3.2-Spezifikation, titelnd Generisches Metamodell, legt die konzeptionelle Grundlage für die gesamte ArchiMate-Sprache. Sie definiert was modelliert werden kann – nicht spezifische Schichten (Geschäft, Anwendung, Technologie), sondern die generischen Abstraktionen aus denen alle schichtspezifischen Elemente abgeleitet werden.

Stellen Sie sich Kapitel 4 als das „DNA-Blueprint“ von ArchiMate vor:

• Alle Geschäftssubjekte, Anwendungskomponenten und Geräte → erben von Interne aktive Struktur
• Alle Prozesse, Funktionen und Dienste → stammen ab von Verhalten Elemente
• Alle Datenobjekte, physische Vermögenswerte und Artefakte → spezialisieren Passive Struktur

Dieser Tutorial entfaltet diese Ideen mit klaren Definitionen, realweltliche Analogien, konkreten Modellierungsbeispielen, visuellen Notationsverweisen und einer Zusammenfassungstabelle – wodurch Architekten und Produktverantwortliche (wie Sie, Alex 👋) ArchiMate rigoros und intuitiv in strategischen Roadmaps, Querschicht-Abhängigkeitskarten und stakeholderorientierten Architekturdokumentationen anwenden können.

Lassen Sie uns beginnen.

🧱 1. Grundlegende Klassifikation: Verhalten vs. Struktur

Auf der höchsten Ebene unterscheidet ArchiMate zwei Kategorien:

Kategorie

Rolle

Alltägliche Analogie

ArchiMate „Part of Speech“

Strukturelemente

Wer/Wasführt aus oder wird beeinflusst

Substantive — z. B. Mitarbeiter, Server, Datenbank

🧱 Substantive

Verhaltenselemente

Was geschieht, wie, und wann

Verben — z. B. Genehmigen, Verarbeiten, Benachrichtigen

🎯 Verben

Aber ArchiMate geht tiefer: Beide Kategorien unterteilen sich basierend auf Sichtbarkeit und Fähigkeit.

1.1 Strukturelemente: Aktiv vs. Passiv

Untertyp

Definition

Wesentlicher Gedanke

Notation

Interne aktive Struktur

Entitäten, die durchführenVerhalten (z. B. Menschen, Systeme, Geräte)

Die „Täter“ innerhalb des Systems

□ mit eckigen Ecken + Symbol

Externe aktive Struktur (Schnittstelle)

ZugangspunkteExponieren von Verhalten nach außen —verbirgt Interne

Wie ein API-Endpunkt oder ein Kundenservice-Schalter

▢ mit „Port“-Symbol (Kreis mit Halbring)

Passive Struktur

Entitätenauf die eingewirkt wird— keine Autonomie (z. B. Daten, Dokumente, Ausrüstung)

Die „Patienten“ des Verhaltens

□ mit eckigen Ecken + Dokumentensymbol

🔍 Wichtiger Einblick:

• Schnittstellen sindnichtphysisch — sie sindlogische Verträgefür Interaktion.
• Passive Elemente können seindigital (z. B. Kundenkartei) oder physisch (z. B. MRT-Gerät).

✅ Beispiel (Gesundheitssystem):

Klartext

1

2

3

4

5

6

7

Hier:

• Arzt = Interne aktive Struktur
• EMR-Schnittstelle = Externe aktive Struktur (z. B. HL7-API)
• Elektronisches medizinisches Protokoll = Passive Struktur
• Patient diagnostizieren = Interne Verhaltensweise
• Patientenportalservice = Externe Verhaltensweise (Dienst)

1.2 Verhaltenselemente: Intern, Extern und Ereignisse

Untertyp

Definition

Wesentliche Idee

Notation

Internes Verhalten

Aktivität innerhalb das System (nicht direkt verfügbar)

Versteckte Implementierung

◓ mit abgerundeten Ecken + Symbol

Service (externes Verhalten)

Explizit verfügbar Verhalten — definiert durch Wert, SLA, Vertrag

„Was wir anbieten“ für Verbraucher

◓ mit „Globe“- oder „Service“-Symbol

Ereignis

Ein Zustandsänderung die aus Verhalten ausgelöst wird oder daraus resultiert

„Etwas ist geschehen“ (z. B. BestellungPlatziert, ZahlungFehlgeschlagen)

⚡ Blitz

💡 Service ≠ Schnittstelle:

• Ein Service ist was wird angeboten (Rückerstattung bearbeiten).
• Ein Schnittstelle ist wie wird darauf zugegriffen (Rückerstattungs-API, Call Center).
  Ein einzelner Dienst kann von mehreren Schnittstellen bedient werden.

✅ Beispiel (E-Commerce):

Klartext

1

2

3

4

5

6

7

8

9

• Bestellabwicklungsservice: externes Versprechen gegenüber dem Kunden
• Web-Schnittstelle: wie der Kunde darauf zugreift
• Verpacken- und Versenden-Prozess: interner Workflow
• Versandetikett-Vorlage: passives Artefakt

✅ Ereignis-Beispiel:

Klartext

1

2

Ereignisse ermöglichen die ModellierungReaktionsketten—kritisch für ereignisgesteuerte Architekturen.

🔄 2. Hauptbeziehungen (Metamodellansicht)

⚠️ Erinnerung: Dies sindMetamodellBeziehungen (definieren die Sprachstruktur),nichtModellierungsbeziehungen wierealisiertoderauslöst.

AusAbbildung 5 (Metamodell Verhalten & Struktur), die zentralen Verbindungen sind:

Beziehung

Richtung

Bedeutung

Realwelt-Analogie

Realisiert

Interne Aktive → Interne Aktivität

„Täterführt aus Tat”

Entwickler → schreibt Code

Dient

Dienst → Interne Verhaltensweise

„Dienst wird unterstützt durch interne Arbeit”

„Schnellzahlung“-Dienst ← realisiert durch → „Optimierte DB-Abfrage + Asynchrone Authentifizierung”

Wird verwendet von

Interne Verhaltensweise → Passive Struktur

„Aktivität wirkt auf Daten/Objekt”

BenutzerValidierung → liest → Benutzerprofil

Zugewiesen an

Interne Verhaltensweise → Interne Aktivität

„Aufgabe zugeordnet an Aktionsobjekt/System”

Darlehen genehmigen → zugeordnet an → Darlehensbeamter

Auslöser

Ereignis → Verhaltensweise

Ereignis startet Verhaltensweise

NeueAnmeldung → auslöst → SendWelcomeEmail

📌 Wichtig:

• Zusammensetzung und Aggregation sind immer erlaubt zwischen gleichartigen Elementen (z. B. Prozess → setzt sich zusammen aus → Unter-Prozess).
• Spezialisierung (Vererbung) wird verwendet nur im Metamodell, nicht in konkreten Modellen.

🧬 3. Spezialisierte Verhaltensweisen: Prozess, Funktion, Interaktion, Zusammenarbeit

Während Interne Verhaltensweise abstrakt ist, bietet ArchiMate konkrete Spezialisierungen:

Element

Definition

Am besten geeignet für

Notation

Prozess

Sequentiell, zielorientierter Ablauf (Start → Schritte → Ergebnis)

Querschnitts-Abläufe (z. B. Kunden onboarden)

◓ mit Zahnradsymbol + Pfeilwirbel

Funktion

GruppiertVerhalten durch Fähigkeit, Fertigkeit oder Eigentum (häufig langfristig)

Organisatorische Fähigkeiten (z. B. Risikobewertung)

◓ mit Stapelblock-Symbol

Interaktion

KollektivVerhalten, das mindestens 2 Akteure/Systeme erfordert

Peer-to-Peer-Kooperation (z. B. Vertrag verhandeln)

◓ mit zwei sich nähernden Pfeilen

Kooperation

Gruppeaus aktiven Elementen, die zusammenarbeiten

Teams, Cluster, Mikroservice-Ensembles

□ mit Handschlag-Symbol

🔁 Schlüssel-Erkenntnis: Prozesse könnenFunktionen enthalten (und umgekehrt!)

• Ein Abrechnungsprozess kann bestehen aus:
  • Rechnung überprüfen (Funktion)
  • Rabatte anwenden (Funktion)
  • Streitfall eskalieren → Interaktion zwischen Abrechnungsagent & Kundensupport

✅ Beispiel aus der Praxis: SaaS-Testversion-Umwandlung

Klartext

1

2

3

4

5

6

🎯 4. Motivationsfaktoren: Das „Warum“

Kapitel 4 führt die generische Motivationsfaktor—die Wurzel von warum die Architektur existiert.

Element

Ebene

Beispiel

Rolle

Interessent

Wer interessiert sich dafür?

CIO, Kunde, Aufsichtsbehörde

Quelle der Ziele

Ziel

Was wollen wir?

„Verbessere NPS um 20 %“

Höchstes Ziel

Treiber

Warum jetzt?

„Wettbewerber hat KI-Funktion veröffentlicht“

Externer Treiber

Grundsatz

Wie entscheiden wir uns?

„API-erstes Design“

Leitregel

Anforderung

Was muss wahr sein?

„99,95 % Uptime“

Messbare Beschränkung

✨ Strategischer Tipp für Produktmanager: Verwende Motivations-Elemente, umdie Verbindung zwischen Produktstrategie ↔ technische Architektur herzustellen.
Z. B. Ziel: Reduziere die Onboarding-Zeit → treibt an Anforderung: <2 Minuten Anmeldung → realisiert durch Dienst: InstantIdentityVerification.

📦 5. Zusammengesetzte Elemente: Gruppierung und Position

5.1 Gruppierung

• Zweck: Logisch bündeln heterogen Elemente (z. B. Prozesse + Daten + Dienste).
• Anwendungsfälle:
  • Architekturbaukästen (ABBs) — z. B. "Customer-360-ABB" = {ProfileService, DataSync, UI-Widget}
  • Domänen — z. B. "Sicherheitsdomäne" = {AuthZ-Richtlinie, IAM-Dienst, Audit-Protokoll}
  • Epics oder Produktfähigkeiten (hervorragend für die Roadmap-Ausrichtung!)

✅ Beispiel für Gruppierung:

Klartext

1

2

3

4

5

⚠️ Vorsicht: Verwechseln Sie nicht Gruppierung mit Ansichten. Gruppierung ist Teil von dem Modell; Ansichten sind gefilterte Darstellungen davon.

5.2 Ort

• Stellt dar Wo passiert—physisch (Rechenzentrum, Büro) oder konzeptionell (Cloud-Region, Gerichtsbarkeit).
• Verwenden Sie Aggregation von Ort → Struktur/Verhalten.

✅ Beispiel:

Klartext

1

2

3

4

🌐 Relevanz für die Cloud: Modellieren Sie mehrregionale Bereitstellungen:
[AWS us-west-2] → aggregiert → [Authentifizierungsdienst] + [Benutzer-DB-Replikat]

📊 Zusammenfassungstabelle: Kern-Generische Elemente (Kapitel 4)

Kategorie

Element

Abstrakt?

Wichtige Frage

Notationsskizze

Struktur

Intern aktiv

✅

Wer führt aus?

□ + Akteur/Icon

Zusammenarbeit

❌

Wer arbeitet zusammen?

□ + Handschlag

Schnittstelle (extern aktiv)

❌

Wie wird darauf zugegriffen?

▢ + Port

Passive Struktur

✅

Was wird beeinflusst?

□ + Dokument

Verhalten

Internes Verhalten

✅

Was passiert innerhalb?

◓ + Aktion

Prozess

❌

Welche Abfolge erreicht ein Ziel?

◓ + Zahnradsymbol + Pfeil

Funktion

❌

Welche Fähigkeit ist gruppiert?

◓ + Stapel

Interaktion

❌

Was erfordert Zusammenarbeit?

◓ + ↔ Pfeile

Dienstleistung (extern)

❌

Was wird den Benutzern angeboten?

◓ + Globus

Ereignis

❌

Was hat sich geändert?

⚡

Motivation

Motivationselement

✅

Warum existiert das?

◊ (diagonale Ecken)

Kompositum

Gruppierung

❌

Was gehört zusammen?

▢ mit gestricheltem Rand + „G“

Ort

❌

Wo findet es statt?

▢ mit Kartennadel

📝 Hinweis: „Abstrakt?“ = Nicht direkt in Modellen verwendet — nur abgeleitete Elemente auf der Ebene (z. B. Geschäftsakteur, Anwendungskomponente) werden instanziiert.

🧩 Alles zusammengefasst: Mini-Fall (Migration in die Cloud)

Szenario: Legacy-Rechnungssystem in die Cloud migrieren.

[Ziel: Senkung der Gesamtbetriebskosten um 30%]
↑ realisiert durch
[Gruppierung Migration Rechnungsstellung in die Cloud]
├─ enthält → [Prozess zur Stilllegung des Mainframes]
├─ enthält → [Rechnungsstellungsmikroservice] (intern aktiv)
├─ enthält → [Rechnungsstellungs-API] (Schnittstelle)
├─ enthält → [Rechnungs-PDF] (passiv)
├─ dient → [Cloud-Rechnungsservice]
└─ befindet sich in → [AWS us-east-1]

[Stilllegung des Mainframes]
auslösend → [MainframeOffline] (Ereignis)
auslösend → [CutoverComplete] (Ereignis)
verwendet von → [Datensicherungsskript] (Funktion)

Dies zeigt, wie Motivation (Ziel), Kompositum (Gruppierung, Lage), Struktur, und Verhalten verzahnt.

🏁 Schlussfolgerung

Kapitel 4’s Generisches Metamodell ist der Rosetta-Stein von ArchiMate. Durch die Beherrschung dieser Abstraktionen – insbesondere der Aktiv/Passiv, Intern/Extern, und Verhalten/Struktur Unterscheidungen – Sie erhalten:

✅ Präzision: Vermeiden Sie die Modellierung von Anti-Mustern (z. B. die Zuweisung von Verhalten zu passiven Elementen).
✅ Konsistenz: Wenden Sie dasselbe mentale Modell über die Geschäfts-/Anwendungs-/Technologie-Ebenen an.
✅ Strategische Tiefe: Verknüpfen Sie Produktziele (Motivation) mit technischen Enabler (Struktur/Verhalten).
✅ Skalierbarkeit: Verwenden Sie Gruppierung und Positionierung, um Komplexität in großen Unternehmen zu managen.

Für Produktführer wie Sie (mit Tiefgang in HCI + CS + PM, Alex 😊), ist dies Gold:

• Verwenden Sie Dienste zur Definition von Produkt-APIs und SLAs.
• Verwenden Sie Gruppierungen zur Modellierung von Produktfähigkeiten oder Epics.
• Verwenden Sie Motivation um Features auf Geschäftsziele zurückverfolgen zu können.

📚 Nächste Schritte:

• Üben Sie die Schichtung: Karten Sie generische Elemente auf Geschäftsebene (Kap. 8), Anwendung (Kap. 9), Technologie (Kap. 10).
• Erkunden Sie Beziehungen in Kapitel 5—insbesondere Ableitungsregeln (Abschnitt 5.7).
• Versuchen Sie, eine Produktfähigkeit mit Hilfe von nur Konzepte aus Kapitel 4 zuerst—dann spezialisieren.

Viel Erfolg beim Modellieren! 🏗️
Lassen Sie mich wissen, wenn Sie ein begleitendes Tutorial zu Beziehungen (Kapitel 5) oder ein ArchiMate-Handbuch für Produktmanager.

—
Hergestellt mit Sorgfalt für Alex Johnson, Senior PM @ Acme Cloud — San Francisco Bay Area ☕📸🏃‍♂️