Modellierung von Unternehmensarchitekturen

Die ersten grossen Herausforderungen sind geschafft: Das Architektur Board ist operativ, die wichtigsten Architekturstandards werden befolgt und die Architecture Development Method (ADM) aus TOGAF ist etabliert. Doch wie sehen die Architekturbeschreibungen aus?  Werden diese von allen verstanden?

Die Sprachverwirrung:

Pieter Brügel: Turmbau zu Babel, SPrachendurcheinander

Pieter Brügel: Turmbau zu Babel, Sprachendurcheinander

Obwohl die grosse babylonische Sprachverwirrung schon einige Zeit her ist, leiden wir noch immer darunter. Das gilt auch in der Modellierung von Unternehmens Architekturen, auch wenn deren Sprachen nicht aus der Zeit Babylons stammen…

Für die Modellierung von Unternehmensarchitekturen stehen uns die folgenden Hauptvertreter von Sprachen zur Verfügung:

–          BPMN 2.0 (Business Process Modelling Notation)
–          UML 2.5 (Unified Modelling Language)
–          ArchiMate 2.0 (Modellierungssprache der OpenGroup)

Die Sprachverwirrung gilt es aufzulösen oder zumindest aufzuweichen wenn Architekturen erfolgreich modelliert werden sollen. Der erste Schritte dazu ist das Verstehen der verschiedenen Sprachen und wozu diese typischerweise eingesetzt werden.

Die Sprachen:

Jede der genannten Sprachen zeichnet sich durch spezifische Notationen, Einsatzgebiete und Schwerpuntke aus. Diese sollen im Folgenden beleuchtet werden. Beginnen wir mit BPMN: Diese Sprache ist stark im Business verankert, der Name verrät das schon. Mit BPMN lassen sich Business Prozesse in eindeutiger Art und Weise modellieren und können Basis sein für die Entwicklung von IT Lösungen (mehr Informationen zu BPMN). BPMN unterscheidet die Kernelemente Event, Activity, Gateway und Connections.

BPMN Hauptelemente (Quelle: Wikipedia)

BPMN Hauptelemente (Quelle: Wikipedia)

Die zweite stark verbreitete Sprache ist UML. Auch hier ist der Name Programm: Es geht ums modellieren, meistens von Software Lösungen. Damit ist auch klar, wo die Sprache ihre stärkste Verbreitung geniest  UML ist hauptsächlich eine Sprache der Entwickler welche als Basis für die Codierung oder das Costomizing von Software Produkten dient, insbesondere in der objektorientierten Software Entwicklung. UML unterscheidet zwei Haupttypen von Diagrammen: Strukturdiagramme und Verhaltensdiagramme. Es gibt 7 verschiedene Strukturdiagramme und 8 Verhaltensdiagramme.

UML Diagramme (Quelle: Wikipedia)

UML Diagramme (Quelle: Wikipedia)

ArchiMate, die dritte Sprache, ist nicht klar dem Business oder der IT-Entwicklung zuzuordnen. Das verwundert nicht weiter, adressiert ArchiMate mit seinen drei Layern sowohl Business als auch IT: Der Business Layer befasst sich mit Business Prozessen, Business Services und Business Funktionen. Der Application Layer adressiert die Software welche das Business unterstützt. Der Technology Layer umfasst die Hardware und kommunikations Infrastruktur zur Unterstützung des Application Layer. ArchiMate unterscheidet über alle Layer hinweg die folgenden drei Elementen: passive structure, behaviour und active structure.

Archimate Elemente (Quelle: OpenGroup)

Archimate Elemente (Quelle: OpenGroup)

Die Gemeinsamkeiten & Unterschiede

Einige Elemente sind in allen Sprachen sehr ähnlich, so hat ArchiMate z.B. die Darstellung von Beziehungen aus UML 2.0 übernommen. Trigger anderseits wurden aus verschiedenem Business Prozess Modellierungsprachen entnommen. Als einzige Sprache adressiert ArchiMate die drei Layer Business, Application und Technology und gibt auch Hilfestellung zur Verbindung dieser drei Layer. ArchiMate berücksichtigt insbesondere auch die spezifischen Informationsbedürfnissen der unterschiedlichen Stakeholder. Dazu verwendet ArchiMate das Konzept der Views & Viewpoints aus TOGAF. BPMN geht dafür stark ins Detail bei der Businessprozess Architektur. UML detailliert die Beschreibung von Software Architekturen. Kein Sprache ist besser als die andere, sie verfolgen nur unterschiedliche Zwecke.

Die Sprachwahl

Welche Sprache zur Beschreibung der Unternehmensarchitekturen soll nun zum Einsatz kommen? Es ist natürlich möglich, dem Business BPMN zu lassen, die Entwickler in UML modellieren zu lassen und in der Architekturabteilung ArchiMate zu verwenden. Die entstehenden Diagramme werden alle ähnlich aussehen, aber eben nicht gleich und schon gar nicht konsistent. Besser wäre die Einigung auf eine gemeinsame Sprache zur Modellierung von Architekturen oder zumindest auf die Definition der Schnittstellen zwischen den verschiedenen Sprachen. In einem kleineren Unternehmenskontext erscheint die Einigung auf eine Sprache am sinnvollsten, weil die individuelle Schnittstellendefinition aufwändig ist und sich für das kleinere Unternehmen nicht rechnet. In grösseren Organisationen kann es sinnvoll sein, mehrere Modellierungssprachen zu verwenden und den Aufwand für die Schnittstellendefinition zu treiben. Die Klärung der wichtigen Frage der Sprachwahl ist übrigens Bestandteil der Preliminary Phase aus TOGAF.

Das Zusammenspiel von ArchiMate und TOGAF

Wollen Sie auf ArchiMate setzen, ist ein Blick auf TOGAF unvermeidlich, kommen die beiden Frameworks doch aus dem gleichen Haus (Open Group). Das folgende Bild zeigt, dass ArchiMate insbesondere in den ADM Phasen B, C und D zum Einsatz kommt. Die Phasen also, in welchen die eigentliche Architektur entwickelt wird (mehr Informationen zu TOGAF). Die anderen Phasen befassen sich mit Implementierung, Change Management etc. TOGAF als Architektur Management Framework greift also deutlich breiter als ArchiMate als Modellierungssprache.

Zusammenspiel TOGAF - ArchiMate (Quelle: OpenGroup)

Zusammenspiel TOGAF – ArchiMate (Quelle: OpenGroup)

Wie modellieren Sie Architekturen? Haben Sie das notwendige Wissen über Architektur Management und das entsprechendes Modellierungs Know-How? Gerne unterstütze ich oder meine Kollegen Sie beim Wissensaufbau und bei konkreten Architektur Modellierungen.


 

Dieser Eintrag wurde veröffentlicht in Allgemein, BPMN und verschlagwortet mit , , , von Daniel Schmid. Permanenter Link zum Eintrag.

Über Daniel Schmid

Daniel Schmid hat langjährige Erfahrungen als Line Manager im IT Management und ist ausgewiesener Kenner von Best Practice Frameworks wie ITIL, CobIT und TOGAF. Weiter hat er fundierte Kenntnisse im IT Financial Management sowie dem IT Einkauf. Er ist Dipl. Wirtschaftsinformatiker Universität Zürich, Certified ITIL Expert in IT Service Management, Certified IT Service Manager sowie TOGAF 9 Certified. Daniel Schmid ist seit 2003 in der Informatik tätig. Er befasste sich in einem Schweizer Energieunternehmen, zuletzt in der Rolle als Head IT Governenance & Controlling, hauptsächlich mit den folgenden Themen: • Einführung und Durchsetzung von wirkungsvollen Kostenkontrollmassnahmen • Einführung und Durchsetzung von ITIL Prozessen, insbesondere IT Change Management • Einführung des IT Teils des gesetzlichen Internen Kontroll Systems (IKS) • Durchführen von Kundenumfragen in Zusammenarbeit mit der Universität Bern • Professionalisierung und Durchsetzung des zentralen IT Einkaufs • Durchführung von IT Benchmarks • Konzipierung und Erstellung der IT Service Kostenkalkulation, Kostenverrechnung und Erstellung der Service Verträge

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>