Was ist ArchiMate?

ArchiMate ist eine Modellierungssprache für Unternehmensarchitektur - ein Standard der Open Group und die einzige weit verbreitete Sprache, die für diese Aufgabe gebaut wurde. Wo UML Software beschreibt und BPMN einen Prozess beschreibt, beschreibt ArchiMate eine Organisation: was sie tut, was sie stützt und worauf das läuft, in einem Modell mit einem Vokabular.

Was sie kann und sonst nichts kann, ist Grenzen überschreiten. Ein Klassendiagramm kann nicht sagen, dass ein Stück Software einen Geschäftsprozess stützt. Ein Prozessdiagramm kann nicht sagen, von welchem Server der Prozess abhängt. ArchiMate kann beides im selben Bild sagen, durchgehend mit denselben elf Beziehungstypen, und das ist der ganze Grund ihrer Existenz.

ArchiMate ordnet seinen gesamten Elementsatz in einem Raster. An der einen Seite stehen die Ebenen, die sagen, wie nah am Blech ein Element ist. An der anderen die Aspekte, die sagen, welche Art von Ding es ist. Jeder Elementtyp der Sprache sitzt in genau einer Zelle.

Die Aspekte sind die zweite Achse und leichter: ein Element ist aktiv (es tut etwas - ein Akteur, eine Komponente, ein Knoten), Verhalten (etwas, das getan wird - ein Prozess, eine Funktion, ein Service) oder passiv (etwas, an dem gehandelt wird - ein Geschäftsobjekt, ein Datenobjekt, ein Artefakt). Aktive Elemente werden mit eckigen Ecken gezeichnet, Verhalten mit runden und passive Elemente als Objektform.

Das Raster zu lernen ist der größte Teil davon, die Sprache zu lernen. Sobald Sie wissen, dass ein "Service" ein Verhaltenselement ist und auf jeder Ebene existiert, wissen Sie bereits, was ein Geschäftsservice, ein Anwendungsservice und ein Technologieservice jeweils sind, und der Artikel zu den Ebenen füllt dann Details, statt Neues beizubringen.

ArchiMates Notation ist das Gegenteil von UMLs. UML gibt jeder Diagrammart eigene Formen - Ovale für Anwendungsfälle, Rauten für Entscheidungen, isometrische Kästen für Knoten. ArchiMate gibt fast allem ein Rechteck und unterscheidet Elemente auf drei anderen Wegen.

Elemente sind die leichte Hälfte. Die elf Beziehungstypen sind der Ort, an dem Modelle richtig oder falsch werden, und vier davon tragen den meisten Sinn:

Der Unterschied, den man zuerst falsch macht, ist Bedienung gegen Realisierung. Realisierung sagt "dies ist jenes, konkret gemacht"; Bedienung sagt "dies hilftjenem". Eine Zahlungskomponente realisiert den Zahlungsservice (dieselbe Fähigkeit auf zwei Abstraktionsebenen), und der Zahlungsservice bedient den Checkout-Prozess (zwei verschiedene Dinge, eines dem anderen nützlich). Sie zu vertauschen ergibt ein Modell, das gut aussieht und Auswirkungsfragen falsch beantwortet - siehe den Artikel zu den Beziehungen.

Vergleichen Sie das mit dem Titeldiagramm. Die UML-Version weiß, dass Claim.submittedOn ein Datum ist; die ArchiMate-Version hat keine Ahnung davon. Die ArchiMate-Version weiß, dass ein Ausfall der Schadendatenbank am Ende verhindert, dass ein Versicherungsnehmer einen Schaden meldet; die UML-Version kann die Frage nicht einmal ausdrücken.

Die beiden ergänzen sich, statt zu konkurrieren, und eine gesunde Praxis nutzt beide: ArchiMate für die Landschaft, UML für die Systeme darin. Was nicht funktioniert, ist eine Sprache, die man auf beide Aufgaben dehnt, was in der Praxis ein ArchiMate-Modell mit angeschraubten Attributen bedeutet oder ein Klassendiagramm mit Servern neben den Klassen.

1. Das ganze Unternehmen modellieren. Niemand wird fertig und niemand liest es. Modellieren Sie den Teil, von dem eine Entscheidung abhängt, und hören Sie auf.
2. Assoziation für alles benutzen. Ein Modell, dessen Linien alle schlichte Assoziationen sind, trägt nicht mehr Information als ein Foto vom Whiteboard. Wenn Sie keine bestimmte Beziehung wählen können, verstehen Sie die Verbindung noch nicht.
3. Eine riesige Sicht. Das Modell ist das Modell; eine Sicht ist ein Fenster darauf für ein Publikum. Fünf fokussierte Sichten schlagen ein Poster. Viewpoints sind der Mechanismus.
4. Anwendungskomponenten nach Teams benannt. Teams werden zweimal im Jahr umorganisiert, die Systeme nicht. Benennen Sie das System.
5. Die Motivationsebene auslassen. Ein halbes Jahr später erinnert sich niemand, welche Anforderung das seltsam aussehende Stück rechtfertigte, und es wird entfernt.