Lesbarkeit von ArchiMate-Diagrammen

Wir benutzen ArchiMate um eine Architektur zu modellieren bzw. zu dokumentieren. Das tun wir nicht ohne Grund! Wir wollen gute Entscheidungen treffen und sicher gehen, dass uns die Stakeholder gut verstehen. Dabei ist entscheidend das wir eine gute Lesbarkeit der Diagramme erreichen.

Dazu gibt es ein paar grundlegende Ratschläge:

Kleine Diagramme, großes Modell

Ein Diagramm sollte bei Ausdruck auf DIN A4 ohne Brille lesbar sein. Nach meiner Erfahrung sollte ein Diagramm weniger als 30 Elemente beinhalten. In der Regel zwischen 10 und 20 Elementen.

Das Modell ist in der Regel viel größer und kann mehrere tausend Elemente und Beziehung enthalten. Aber es müssen nicht alle Aspekte eines Systems in einem Diagramm gezeigt werden.

Viewpoints haben sich bewehrt um Diagramm an ihrem Zweck auszurichten. Möchte ich die Statik der Architektur beleuchten oder die Dynamik? Interessiert den Stakeholder die Business-Architektur, oder die Technology Architektur? Hierfür gibt es dann die passenden Viewpoints. Mehr über Viewpoints gibt es in der ArchiMate Online Reference.

Klare Struktur

In unserem Beispiel-Diagramm ist einiges durcheinander geraten:

Beispiel 1

Es herrscht ein buntes Treiben auf dem Diagram, dass etwas aufgeräumt werden muss, bevor man damit seinen Stakeholder erfreuen kann. Es ist nicht ungewöhnlich, wenn Diagramm direkt nach der Erstellung ungefähr so aussehen aber man sollte sie bitte nicht so lassen.

Folgendes kann man tun, um die Lesbarkeit von Beispiel 1 zu erhöhen:

  • Schichtung: Alle Elemente eines Layers sollten auch visuell zusammengefasst werden. Dabei gilt: Zuoberst liegen die Elemente des Business Layers (Gelb), gefolgt vom Application Layer (Blau) und Technology Layer (Grün). Motivation Elemente können zu allen Ebenen gehören.
  • Zusammenhang: Elemente die miteinander in Beziehung stehen sollten nicht zu weit weg voneinander angeordnet sein.

Das führt uns zu folgendem Diagramm:

Beispiel 2

Ja, das sind schon viel besser aus! Aber es läßt sich noch einiges tun:

  • Gerade und möglichst überschneidungsfreie Beziehungen machen das Bild klarer und helfen den Linien schnell zu folgen. Ausserdem wird Symmetrie meist als schön empfunden.
  • Nesting: Dies bezeichnet das einbetten eines Elements in ein anderes. Dabei entsteht eine größere, visuelle Bindung der Elemente. Nachteil ist, dass ich dann nicht mehr sehen kann, welche Beziehung die eingebetteten Elemente haben. Deshalb sollte man sich auf die Struktur-Beziehungen beschränken. Diese sind: Composition, Aggregation, Assignment und Realization.
Beispiel 3

Hürden vermeiden

Hürden entstehen, wenn das Diagramm, z.b. in einem Meeting, in einem Schwarz/Weiß-Ausdruck zum Einsatz kommt. Nun kann man die Layer nicht mehr an ihrer Farbe unterscheiden. Immerhin haben wir noch eine Schichtung der Elemente, aber ich kann nicht mehr sicher sagen, ob ein Element nun zur Business oder Application Architecture zählt.

Eine weitere Hürde entsteht, wenn der Stakeholder keine Übung darin hat ArchiMate zu lesen, oder sogar ArchiMate vorher noch nie gesehen hat. Man kann, und sollte auch, die wichtigen Stakeholder in einem kurzen Crash-Kurs das notwendigste zu ArchiMate schulen. Dennoch könnte diese Schulung schon eine Weile zurückliegen oder ein Stakeholder hatte noch keine Schulung.

Das Problem mit dem Ausdruck und dem Kenntnisstand läßt sich mit der gleichen Maßnahme abwenden: Man schreibt in die Elemente hinein, um welche Art es sich dabei handelt. Zusätzlich kann ich das auch mit den Beziehungen machen.

Beispiel 4

Die Beziehungsnamen hinzuzufügen, möchte ich aber nicht empfehlen. Ich finde, dass es die Lesbarkeit nicht unbedingt erhöht und ich bin nicht mehr in der Lage eine fachliche Bemerkung an die Beziehung zu schreiben. Mein Lösungsansatz ist eine Legende für die eingesetzten Beziehungen hinzuzufügen.

So sieht dann das Endergebnis aus:

Beispiel 5

Übrigens am Modell hat sich kaum etwas verändert. Wenn das Modellierungs-Tool in der Lage ist die Namen der Elemente in den Klammern beim Ausdruck selbst hinzuzufügen, hat sich sogar zwischen dem ersten und dem letzten Beispiel gar nichts am Modell verändert, sondern nur am Layout.

Wer mehr über ArchiMate erfahren möchte, findet hier eine Einführung sowie weitere Beispiele.

Grundsätze des Scientific Management

Scientific Management? Nie gehört! So war meine Reaktion als ich über diesen Begriff gestolpert bin. Ich dachte erst, es handele sich um etwas Neues. Weit gefehlt! Der Begriff entstand Anfang der 1910er Jahre. Interessant ist, dass es damals eine schnell wachsende Industrie gab: Die Fertigungsindustie. Maschinen ersetzten die Muskelkraft und automatisierte Fertigungsprozesse die Geschicklichkeit des Menschen. 100 Jahre später zielt die Automation nicht mehr auf Muskeln und Geschick sondern auf Gehirn und Kreativität. Können wir vielleicht etwas lernen aus der Vergangenheit?

Der Begriff wurde von dem Maschinenbau-Ingenieur Frederick Taylor eingeführt. Taylor beschäftigte sich mit der Effizienz in der industriellen Fertigung und war einer der ersten Management-Berater überhaupt. Damals, so wie heute, gab es ein starkes Verlangen nach Effizienz im Aufbau der sich schnell veränderten Produktfertigung. Zu dieser Zeit entstand das „Efficiency Movement“. Eine Bewegung der Industrienationen, allen voran den U.S.A., zum Zwecke der Ermittlung und Beseitigung von Verschwendung in allen Bereichen der Wirtschaft und Gesellschaft sowie der Entwicklung und Umsetzung von Best Practices.

Es war eine Zeit des weit verbreiteten sozialen Aktivismus und der politischen Reformen in den Vereinigten Staaten. Die Hauptziele waren die Beseitigung der Probleme, die durch Industrialisierung, Urbanisierung, Einwanderung und politische Korruption verursacht wurden. Sie strebten auch eine Regulierung von Monopolen (Trust-Busting) und Unternehmen durch Kartellgesetze an, die als Möglichkeit zur Förderung des gleichen Wettbewerbs zum Vorteil legitimer Wettbewerber angesehen wurden. Das könnte einem schon fast bekannt vorkommen. Zwar wiederholt sich die Geschichte nicht, aber sie reimt sich!

Taylor kannte die Fertigung aus eigener Erfahrung. Er erkannte, dass die Arbeiter nicht so effizient wie möglich arbeiteten und dass dies zu hohen Lohnkosten für das Unternehmen führte. Als er Polier wurde, erwartete er mehr Leistung von den Arbeitern. Um festzustellen, wie die Leistung gesteigert werden kann, begann er, die Produktivität sowohl der Männer als auch der Maschinen zu untersuchen und zu analysieren.

Der Begriff Scientific Management bezieht sich auf die Koordination des Unternehmens zum Wohle aller. Der Ansatz stand im Widerspruch zu der damaligen Idee, dass es am Besten sei, wenn Arbeiter selbst bestimmen auf welche Art sie die Arbeit erledigen. Er sah auch, dass es Bedenken unter den Arbeitern gab, eine Effizienzsteigerung könnte ihren oder den Job ihrer Kollegen kosten. Taylor hielt dies allerdings für einen Irrtum. Generell ging er verantwortlich mit den Arbeitern um und machte sich für ihre Sicherheit und gerechte Bezahlung stark.

Für Taylor war es eine Notwendigkeit, sich auf die Ausbildung zu konzentrieren, anstatt den „richtigen Mann“ zu finden, und sagt: [..] das erste Ziel aller guten Systeme sollte die Entwicklung erstklassiger Männer sein.“ Neben der Fertigung mussten sich die Arbeiter auch um die Abstimmung der Prozesse und Verwaltungsaufgaben kümmern. In einer Abgabe dieser Aufgaben an das mittleres Management, sah er Vorteile für alle. Naja, wer den Film „Moderne Zeiten“ von Charlie Chaplin kennt, der weiß wie Effizient 20 Jahre später (1936) der Mensch in die Fertigung „integriert“ war. Auch die Arbeitermassen an ihren Rädern im Film „Metropolis“, aus dem Jahre 1927, verheißen die beängstige Mechanisierung des Lebens. Eine Dystopie die glücklicherweise nicht in diesem Ausmaß eintraf. Dank einer Gegensteuerung durch soziale, politische und technische Entwicklungen.

Ich sehe hier einige Parallelen zum Enterprise Architecture Management. Die Prinzipien beider Disziplinen sind vergleichbar und arbeiten beide mit dem Ansatz von Ist, Soll, Vorgaben, Analyse, Ausbildung und Best Practice.

Die meisten Produkte die wir heute benutzen, haben die Gene des „Scientific Management“ in sich, ohne das wir es bemerkenswert fänden. Insgesamt kann man in den Industrienationen eine mehr oder weniger ausbalanciertes Verhältnis zwischen sozialen Errungenschaften und wirtschaftlichen Interessen beobachten.

Können wir nun etwas lernen vom Scientific Management aus dem Jahre 1910? Das haben wir längst! Ich halte es aber für sehr Wahrscheinlich das in 100 Jahren keiner mehr von Enterprise Architecture Management spricht, weil es Teil des Genoms unsere digitalen Welt sein wird. Die Grundsätze des Scientific Management von Ist, Soll, Vorgaben, Analyse, Ausbildung und Best Practice werden in ihren digitalen Enkeln fortleben, ohne das wir es bemerkenswert fänden.

Wer mehr über Enterprise Architecture wissen möchte, finder hier eine Einführung.

Quellen:

https://en.wikipedia.org/wiki/The_Principles_of_Scientific_Management

Video: Toni und die ADM

Dieses Video bietet eine gute Einführung in die Architecture Development Method (ADM) von TOGAF®. Es geht dabei um Toni, den Buchhändler, und seinem Weg zum Online-Handel.

Im Stile des Storytelling werde dabei alle Phasen der ADM, inklusive Preliminary, vorgestellt. Auch die wichtigsten Deliverables sowie die Rolle des Architecture Boards wird erklärt.


Toni und die ADM

Das Video kann auch hier angeschaut werden:
https://www.youtube.com/watch?v=pdhHjlFTCrM

Wer mehr über TOGAF® erfahren möchte, findet hier weitere Artikel.

Referenz zur Beschreibung der Architecture Development Method.

TOGAF® ist eine eingetragene Marke von The Open Group.

Empfehlungen zur Einführung von Enterprise Architecture Management

In diesem Artikel stelle ich meine Do’s und Don’ts beim Umgang und der Etablierung von Enterprise Architecture Management vor. Sie basieren auf meinen persönlichen Erfahrungen, sind aber flankiert durch entsprechende Empfehlungen aus der Fachliteratur sowie Best Practices der Community.

Evolution statt Revolution

Dies ist ein sehr alter Grundsatz. Bereits die alten Römer kannten und folgenden ihm im Bezug auf Ihrer Verwaltung. Die Grenzen sind aber fliessend. DevOps ist zwar eine Revolution, die Einführung sollte es aber nicht sein. 

Generell gibt es immer einen Ausgangspunkt. Dies ist die Art wie heute Software entwickelt und geliefert wird. Die Schritte zum Ziel sollten spezifisch, schnell umsetzbar und realistisch sein. Viele kleine Schritt in kürzeren Intervallen sind besser als wenige große Schritt.

Innovationen sollten regelmäßig aufgegriffen und genutzt werden. Ihr müßt keine „Frontrunner“ sein aber ein jahrelanger Stillstand führt zur „Ermüdung“ der Akteure.

Revolution kann ein valides Mittel sein, wenn auch ein riskantes. Zwar können bestehende Probleme gelöst werden aber auch neue auftauchen.

Keep it stupid simple

Auch als das KISS-Prinzip bekannt. Das beste Prinzip überhaupt! Oft geht es bei der Planung eines Wandels um eine Vielzahl von Anforderungen. Wichtig ist aber ebenfalls die Frage: „Wie sieht die minimale Umsetzung aus?“. Architekturmuster helfen Dir einfache Lösungen zu finden. So kann ein File Transfer einfacher sein als das verschickten der Inhalte als ein Nachrichtenstrom. Insbesondere wenn es um die Integrität und Vollständigkeit der Daten geht. Mit dem Package Claim Pattern, zum Beispiel, lassen sich File Transfer und Messaging gut integrieren.

Beteiligung von Business

Gerade die Enterprise Architecture, aber auch agile Methoden wie Scrum, setzen auf eine enge Verbindung der Fachebene mit der IT.  Wenn Ihr also Eure IT besser machen wollt, empfiehlt es sich Business zu beteiligen. Die Haltung mancher Akteure auf IT- und Business-Seite ist zum Teil argwöhnisch oder geringschätzig. Auf beiden Seiten gibt es die Meinung, der Umgang mit derArchitekturlandschaft sei für Business zu komplex. Mehr über die Komplexität und deren Ursachen zu lernen ist für Business hilfreich. Für die IT ist es hilfreich zu lernen auch komplizierte Sachverhalte verständlich zu machen und auf die Bedürfnisse von Business abzustimmen. Das von TOGAF® empfohlene Architekturboard sollte deshalb auch Mitglieder aus den Geschäftsbereichen haben.

Aufgaben gut verteilen

Eine typische Aufgabe des Enterprise Architecture Management ist die Dokumentation der Architekturlandschaft. Eine Sisyphusaufgabe, insbesondere wenn sie von einem Team alleine geleistet wird und es viele Veränderungen in kurzer Zeit gibt.

Es ist zu empfehlen, diese Aufgabe auf mehrere Schultern zu verteilen. Die Dokumentation wird dann bei einer Veränderung der Landschaft genutzt und die Veränderung schon im Rahmen der Planung eingepflegt. Hier sei noch erwähnt, daß Aufgaben etwas mit Rollen zu tun haben. So kann die Aufgabe auch von der Rolle „Solution Architect“ erledigt werden. Wenn der Rolleninhaber einen Nutzen sieht und geschult ist, rennt man hier offene Türen ein. Auch Aufgaben aus dem Bereich Qualitätssicherung müssen nicht unbedingt zentral ausgeführt werden. Ein Architekt der eine Lösung A plant, kann für eine Lösung B ein Review machen. Dies verhindert organisatorische Engpässe und fördert den Blick über den Tellerrand. Ein zentrales EA-Team hilft bei der Organisation und unterstützt die Umsetzung tatkräftig.

Nicht überkompensieren

Organisationen, welche heute eine eher kooperative oder inhärente Governance betreiben, sollten bei Anzeichen von Problemen nicht mit einer großen Anzahl von Maßnahmen oder Prinzipien antworten. Ebenso ist es nicht ratsam, daß große, stark regulierte Unternehmen gleich alle Zügel loslassen um ein Lean-Management zu etablieren.

Es ist eine natürliche Reaktion möglichst schnell in eine andere Richtung zu steuern. Ihr kennt das vom Autofahren. Zu heftig am Lenkrad gedreht und man liegt im Graben, besonders auf glatter Fahrbahn. Ok, heute haben die Autos Assistenten, die Schlimmeres verhindern in dem sie permanent den Soll- mit dem Ist-Zustand abgleichen und ins Geschehen eingreifen, falls nötig. Bevor Ihr also alle Hebel umlegt und auf Gegenkurs geht, bedenkt wieviel Dynamik eventuell zu einem Abkommen von der „Fahrbahn“ führt und wieviel Vorsicht bei guter Bodenhaftung übertrieben ist und den Verkehr behindert. Automatische Assistenten gibt es nach meinem Kenntnisstand nicht. Das gibt mir Gelegenheit einen Link auf meine Coaching-Seite unterzubringen.

TOGAF® ist eine registrierte Marke von The Open Group.

Einführung in ArchiMate® 3

ArchiMate® ist eine visuelle Modellierungssprache zur Beschreibung von Enterprise Architekturen

Sie beinhaltet Elemente aus folgende Bereichen einer Enterprise Architektur:

  • Strategische Planung und Motivation
    Resource, Capability, Stakeholder, Driver, Goal, Requirement, etc
  • Business, Application, Data und Technology Architecture
    Actor,Process, Contract, Application Component, Interface, Data, Event, Device, Service, System Software, Network, etc
  • Physical Architecture (Industrie 4.0), Implementation & Migration und Composition
    Material, Equipment, Facility, Work Package, Deliverable, Gap, Location, Product, Grouping, etc

Des weiteren gibt es Beziehungen (Relationships), welche die Elemente in Kontext setzen:

  • Structural Relationships
    Composition (Teil von), Aggregation (Lose Sammlung), Assignment (Zuordnung), Realization (Verwirklicht)
  • Dependency Relationships
    Serving (Dienen), Access (Zugriff), Influence (Einfluss)
  • Dynamic Relationships
    Triggering (Auslösen), Flow (Fluss)
  • Other Relationships
    Specialization, Junction (Knotenpunkt für und/oder), Association (Verbindung)

Die meisten Elemente haben Icons und unterscheiden sich zusätzlich in Form und Farbe. Die Beziehungen unterscheiden sich in der Form der Linen und deren Enden. Hier ein kleines Beispiel:

Erläuterungen:

  • Der Business Actor „Kunde“ betreibt den Business Prozeß „Konfiguration“. Dieser Prozeß realisiert die Anforderung, dass der Kunde eigene Bilder hochladen kann.
  • Der Business Prozess wird durch einen über http angebundenen Application Service bedient. Realisiert wird der Service durch einen Web Server, welcher auf einem Virtual Server in der Cloud läuft.
  • Der Shirt Konfigurator schreibt die Layout-Daten, welche von einem Shirt-Printer im Copy Shop gelesen werden. Die Daten laufen über das Internet an dem sowohl der virtuelle Server als auch der Copy-Shop angebunden sind.
  • Der Shirt Printer arbeitet mit dem Material „Shirt“ und druckt das empfange Layout darauf. Dies realisiert die Business-Fähigkeit „Individuelle Massenfertigung“. Eine wichtige Fähigkeit der Industrie 4.0 (digitalisierte Fertigung).

Die Beziehung in den verschachtelten Elementen sieht man nicht, obwohl sie modelliert ist. Die verborgenen Beziehungen sind:

  • Die Cloud (Location) ist eine lose Sammlung von Devices
  • Der Web Server ist lose Sammlung von System Software
  • Der Shirt Printer (Equipment) ist ein Teil des Copy Shops (Facility)

Im Beispiel wurden schon viele Bausteine von ArchiMate® 3 eingesetzt, aber bei weitem nicht alle. Generell sind bei nicht trivialen Modellen mehrere Views notwendig. In weiteren Views könnte man zum Beispiel auf die Funktionen des Konfikurator eingehen, die Business Actors und Rollen für den Copy Shop beschreiben, einen Support mit eMail, Chat und Telefon Interface hinzufügen und vieles mehr. Sogar die Entwicklung und Lieferung der Lösung ließe sich beschreiben. Im Beispiel fehlen auch eine CRM (Customer Relationship Management) und Bezahl-Komponente, Versand/Retoure und Lager/Lieferung. Von den buchhalterischen/steuerlichen Aufgaben und Auflagen ganz zu schweigen.

Dies macht klar, daß nicht alles in ein einziges Diagramm passt, welches man dann auch noch leicht verstehen könnte. Muss man auch nicht! Alle Elemente und Beziehungen werden als Daten-Tupel in einem Modell gespeichert. Mit diesen Daten lassen sich nicht nur weitere Diagramme zeichnen, sonder auch Listen und Tabellen erzeugen. Beliebt sind Tabellen die zeigen, welche Komponente auf welche Daten-Entität in welcher Form (CRUD) zugreift oder eine Zuordnung von System Software zu Device und Location.

Der ArchiMate® 3 Standard bringt zur Vereinfachung der Frage, was in einen View gezeigt werden soll, eine Viewpoint-Library mit. Dadurch können, passende zum Zweck und zum Detailierungsgrad, die richtigen Elemente gewählt werden. Hier einige Bespiele für vordefinierte Viewpoints:

  • Organization
    Zeigt Business Actors, Roles, Locations, Business Interfaces (Telefon, Web, eMail, Post, etc)  und deren Zusammenhänge
  • Product
    Zeigt alles was zu einem Produkt gehört, wie Business Service, Contract, Application Interface, Data Object, Technology Service, Value und einiges mehr
  • Application Usage
    Zeigt zum Beispiel Business Prozesse und Funktionen im Zusammenhang mit Applikationen und Daten
  • Implementation & Deployment
    Zeigt wie Services von der Infrastruktur realisiert werden.

Insgesamt gibt es 24 vordefinierte Viewpoints. Sie bilden die Viewpoint Library von ArchiMate®. Da sollte jeder fündig werden.

Generell läßt sich ArchiMate® um eigene Attribute sowie Elemente erweitern. Die benutzerdefinierten Elemente können von den vorhandene abgeleitet werden und erben deren Attribute (Specialization). Mit diesem Konzept läßt sich z.B. ein handheld Device darstellen, mit entsprechendem Icon.

Wer mehr über die Modellierung mit ArchiMate® erfahren möchte kann hier weitere Beiträge lesen.

Zu empfehlen ist auch die Dokumentation von The Open Group.

ArchiMate® ist eine eingetragene Marke von The Open Group

Modellieren mit ArchiMate (Teil 3)

Von Joost Bleijenberg – The Unit Company
(Übersetzung von René Hamacher)

VERÄNDERUNGSINITIATIVEN ABWÄGEN

In diesem Blog geht es um die Anwendung von ArchiMate um die Treiber (Drivers) und Ziele (Goals) der Stakeholder zu verstehen und aufzuzeigen. Falls Sie die vorherigen Teile verpasst haben: Hier geht es zum ersten Teil und hier zum zweiten Teil der kleinen Reihe.

Organisationen verfolgen unterschiedliche Ziele, die sich auf einer strategischen Ebene vereinen. Schauen wir uns den Fall Starbucks an, der in den vorherigen Blogs vorgestellt wurde. Hier hat der COO zum Beispiel als Treiber Kundenzufriedenheit, Kostenoptimierung und Ressourcenoptimierung. Diese Treiber bestehen oft unabhängig voneinander und es müssen teilweise Kompromisse eingegangen werden.

In Archimate können wir die Treiber und deren Stakeholder wie folgt modellieren.

 

EINFLUSS VON VERÄNDERUNGSINITIATIVEN

Wir können jetzt auch untersuchen, was wir verbessern können, um einen positiven Beitrag zu diesen drei Treibern zu leisten.

Bevor wir zu dem Schluss kamen, dass wir zu einem „Self Serivce Kiosk“ übergehen sollten, gab es noch einen weiteren Vorschlag: Kaffeemaschinen aufstellen und die Kunden ihren eigenen Kaffee zusammenstellen lassen. Dieses Konzept mit dem Namen „Self Service Coffee Machine“ ist daher eine alternative Lösung. Um den Einfluss der beiden Lösungen auf die Treiber zu untersuchen können wir auf sogenannte „Motivation Elements“ von ArchiMate zurückgreifen:

Die beiden Optionen (Option 1 und Option 2) und ihre Auswirkungen auf die Treiber werden durch die gestrichelten Linien angezeigt (Influence Relationship). Man sieht, dass der Einfluss unterschiedlich ist. Option 2 hat einen positiven Einfluss auf den Ressourcenverbrauch, da nicht der Barrista die Arbeit macht, sondern der Kunde.  Es gibt einen negativen Einfluss auf die Kosten, weil sich herausstellt, dass viele Kaffeemaschinen gekauft werden müssen.

Und es gibt einen neutralen (schwarze gestrichelte Linie) Einfluss auf die Kundenzufriedenheit, da die Kunden nicht ganz zufrieden zu sein scheinen, da sie selbst eine Menge zu tun haben. Option 1 hingegen wirkt sich positiv auf alle Treiber aus.

ZUSAMMENFASSUNG

ArchiMate ist eine visuelle Modellierungssprache, die uns helfen kann die Interessen, Ziele und Treiber der Stakeholder klar aufzuzeigen. Wir können dann verschiedene Veränderungsinitiativen bewerten, indem wir ihren Einfluss auf die Treiber und Ziele abbilden. Je nach Beitrag zum Ziel und Auswirkung auf die Treiber kann eine bevorzugte Wahl getroffen werden. Dabei helfen die Motivations-Elemente von ArchiMate in der Kommunikation und übersichtlichen Darstellung.

 

MÖCHTEN SIE MEHR ÜBER ARCHIMATE® ERFAHREN? KLICKEN SIE HIER!

All content Copyright © 2018 The Unit BV/The Netherlands.

Modellieren mit ArchiMate (Teil 2)

Von Joost Bleijenberg – The Unit Company
(Übersetzung von René Hamacher)

Im ersten Teil dieser Serie haben wir uns mit der Visualisierung beschäftigt und wie ArchiMate dabei helfen kann. In diesem zweiten Teil untersuchen wir, wie Starbucks nach einer Selbstbedienungslösung sucht und welche Auswirkungen diese auf die Struktur des Unternehmens hat. Zum Beispiel folgen wir in dieser Serie Annabel und ihrem Besuch bei Starbucks.

In diesem Szenario geht es darum, dass das Starbucks Management zu dem Schluss kommt, dass Selbstbedienung ein guter Weg ist um eine höhere Kundenzufriedenheit zu erreichen. Anstatt darauf zu warten, dass Kunden in der Warteschlange ihre Bestellung aufgeben, kann der Kunde die Bestellung über einen Touchscreen-Kiosk aufgeben. Auch hier findet die Bezahlung statt und die Bestellung wird an den Barista weitergeleitet.

WIE KANN MAN ARCHIMATE NUTZEN, UM DIE AUSWIRKUNGEN DER VERÄNDERUNG SICHTBAR ZU MACHEN?

Wir beschreiben den Geschäftsprozess der Bestellung und Lieferung von Kaffee, wie im ersten Teil dieser Serie beschrieben. In Teilen des Geschäftsprozesses, muss jetzt eine Änderung vorgenommen werden. Die Prozesse des Bestellens und Bezahlens werden durch einen Kiosk ersetzt, siehe die grünen Prozesse unten:

Dieser wird durch die Kiosk-Prozesse ersetzt, die innerhalb der Anwendung des Kiosks durchgeführt werden. Kurzum, wir brauchen die Kohärenz zwischen Geschäftsprozessen und Anwendung, um weitere Entscheidungen treffen zu können.

Bevor wir dies betrachten, konzentrieren wir uns zunächst darauf, wie die Informationen erfasst werden. In ArchiMate können wir „Datensenken“ modellieren, die bestimmte Geschäftsinformationen enthalten. Siehe unten „Order Details“ und „Ticket + Name + Product“, die relevante Informationen für die Prozesse enthalten. In ArchiMate sind diese Elemente die sogenannten „Business Objects“.

In der oben beschriebenen Situation nimmt der „Order Taker“ die Bestellung an und erfasst die Bestelldaten: die Produkte und die Menge, in der sie bestellt werden.

Während des Bezahlvorgangs wird ein Ticket mit den Preis- und Produktdetails erstellt, welches wir ebenfalls speichern. Diese Informationen werden z.B. bei „Producing the coffee“ verwendet, um das richtige „Rezept“ zu ermitteln.

Da neben den Geschäftsprozessen auch IT-Systeme zum Einsatz kommen ist es gut Einblick in diese zu gewinnen. In der aktuellen Situation nimmt der „order taker“ die Bestellung über ein Point of Sale oder Kassensystem entgegen. In der Kasse gibt es verschiedene Funktionen, die den Kauf- und Bezahlvorgang unterstützen. Die Anwendungsschicht ist unten blau dargestellt. Dies wird dann wie folgt aussehen:

Wir bekommen wir nun eine Vorstellung von den Auswirkungen des Wandels, wenn wir in auf ein Selbstbedienungsmodell umsteigen wollen. Wenn wir nun sowohl den Bestell- als auch den Bezahlvorgang mit einem Kiosk automatisieren wollen, gelangen wir zum vollständigen ArchiMate-Modell:

Wir sehen, dass die Geschäftsprozesse „Ordering at Kiosk“ und „payment at Kiosk“ vollständig durch die Anwendung (blau) realisiert werden.  Sie umfasst die Prozesse, welche mit der Bestellung und Bezahlung zu tun haben. Sie sorgt auch dafür, dass nach der Bezahlung die „producing the coffee“ ausgelöst wird, die die Verbindung zu den bestehenden Prozessen herstellt.

ZUSAMMENFASSUNG

Um eine Veränderung, wie bei der Selbstbedienung vorzunehmen, ist es gut die aktuelle Situation zu verstehen. Indem wir zunächst einen Überblick über die bestehenden Geschäftsprozesse und die Anwendungskohärenz geben, gewinnen wir Einblick in das Ganze. Die neue Struktur kann dann eingefügt werden, um zu sehen, wie der Selbstbedienungskiosk eingebaut und mit Bestehendem verknüpft werden soll. Es gibt auch einen Einblick in den Umgang mit Geschäftsinformationen in der gesamten Kette.

 

Möchten Sie sich für ArchiMate zertifizieren oder möchten Sie ArchiMate als Standard in Ihrem Unternehmen einsetzen?  Besuchen Sie unsere Webseite um mehr zu erfahren: www.theunitacademy.de/archimate-kurse

All content Copyright © 2018 The Unit BV/The Netherlands.

Modellieren mit ArchiMate (Teil 1)

Von Joost Bleijenberg – The Unit Company
(Übersetzung von René Hamacher)

Im ersten Teil dieser ArchiMate-Reihe werden wir uns mit der Visualisierung beschäftigen und wie ArchiMate Ihnen helfen kann Einblick in den Unternehmenswandel zu gewinnen.

Diese Einsicht hilft bei der Entscheidungsfindung im Hinblick auf diese Veränderungen.

Visualisierung ist ein wirksames Mittel um Veränderungen aufzuzeigen und zu managen. Dies ist besonders wichtig für die beteiligten Akteure, um sicherzustellen, dass ihre Interessen in der Veränderung berücksichtigt werden.

Stakeholder (Interessenträger)

Jeder Stakeholder betrachtet die Veränderung auf seine Weise und interessiert sich meist nur für bestimmte Aspekte der Planung.

Es gibt viele Visualisierungsmöglichkeiten. Denken Sie an Comics, Infografiken usw. ArchiMate ist einer davon. ArchiMate ist eine visuelle Sprache, die den Business- und IT-Architekten in die Lage versetzt die Änderung transparent zu machen.

WARUM ARCHIMATE?

Der Vorteil von ArchiMate ist, dass es eine standardisierte Modellierungs-Sprache ist. Dahinter steht die Open Group. Ein Hersteller- und Technologie-Neutrales Konsortium aus über 500 namhaften Unternehmen. Die Open Group steht ebenfall hinter dem Framework TOGAF. Die Standardisierung für zu einer Harmonisierung der Art und Weise, wie in der IT-Industrie modelliert wird. Dies ist vergleichbar mit Prozessen in anderen Bereichen, welche am Ende zu einheitlichen Standards führte. Ein Beispiel ist die Notenschrift, wie wir sie heute kennen. Diese Notenschrift wird von allen verstanden und einmal gelernt, kann sie gelesen werden auch wenn die Quellen sehr unterschiedlich sind.

ArchiMate ermöglicht es, nicht nur die Geschäftsseite (Prozesse, Services, Personen, welche Geschäftsaktivitäten ausführen), sondern auch die IT, d.h. die Anwendungen und die Infrastruktur, zu modellieren. Mit der neuesten Version von ArchiMate ist es sogar möglich, Produktionsunternehmen und logistische Abläufe zu modellieren (Stichwort: Industrie 4.0).

Die Stärke von ArchiMate liegt auch darin, dass man nicht nur die Struktur, d.h. die Kohärenz zeigen kann, sondern auch, wie Informationen z.B. einen Prozess durchlaufen oder wie ein Prozess Informationen in Anwendungen speichert. Kurzum, alle Arten von dynamischem Verhalten.

Bei nicht trivialen Änderungen im Unternehmen, werden wahrscheinlich verschiedene Domänen betroffen sein: Geschäftsprozesse, Anwendung und die Infrastruktur. Deshalb gibt es in ArchiMate genau diese drei Ebenen, in denen Sie die Business-, Application- und Technology-Architekturen modellieren können.

WIE KANN ICH DIESE VERÄNDERUNGEN VISUELL ERKENNEN?

Es ist sehr sinnvoll in der „Sprache“ des Stakeholders zu sprechen und ihm das zu zeigen, was ihn auch tatsächlich interessiert. So sind Netzwerk- und Server-Beschreibungen, meist für den CFO nur von geringem Interesse und führen sogar zu einer ablehnenden Haltung, wenn er damit konfrontiert wird („viel zu kompliziert“, „ich weiß nicht was die da treiben“).

Werfen wir einen Blick auf ein Beispiel. Dazu schauen wir uns die Prozesse in Starbucks näher an. Wir wollen visualisieren, wie der Prozess bei einer Kaffeebestellung funktioniert. Später, in dieser kleinen Serie von Artikeln, werden wir diesen Prozess verändern.

Stellen Sie sich vor, Annabel ist eine Kundin und besucht Starbucks. Sie kommt herein, der Service-Mitarbeiter begrüßt sie, sie bestellt einen Kaffee. Nach der Bezahlung holt sie ihren Kaffee an der Ausgabe ab.  Die Mitarbeiter nutzen das Kassensystem zur Bestellung und Bezahlung. Diese Prozessschritte, die Beteiligten und die IT-Komponenten können visualisiert werden. Wir können das in einem freien, nicht standardisierten, Stil machen. Das könnten dann so aussehen:

Wenn wir es in ArchiMate visualisieren, könnte es so aussehen:

Hier sehen wir die Akteure und Prozesse. Die Akteure führen die Prozessschritte aus. Durch diese Beschreibung sehen wir mehr Details als im freien Stil. Hier sehen wir unter anderem, dass der Auftraggeber bestimmte Schritte im Prozess durchführt und der Barista andere Schritte unternimmt. Wir sehen auch, dass der Kunde (Annabel) der Initiator der Prozessreihe ist.

Später in der Serie werden wir diesen Teil des Prozesses oder der Geschäftsarchitektur auch in Bezug auf die Nutzung von Anwendungen, wie dem Kassensystem betrachten.

Dies zeigt dann wie die Informationen sowohl von Prozessen als auch von Anwendungen verwendet werden. Mit anderen Worten, die Modellierung der Kohärenz.

Die Symbole (Elements) sowie die Pfeile (Relationships) die wir in ArchiMate verwenden sind standardisiert und somit für jeden, der die Sprache kennt, sofort lesbar.


Ein Business Actor ist eine Person oder eine Organisationseinheit, welche ein sogenannten Geschäftsverhalten ausübt.

 


Dies ist ein Geschäftsprozess. Ein Geschäftsprozess stellt eine Abfolge von Geschäftsverhalten dar, die ein bestimmtes Ergebnis, wie z.B. ein definiertes Set von Produkten oder Dienstleistungen, erzielt.


Assignment Relationship: Drückt die Zuordnung von Verantwortung, Verhalten oder Ausführung aus.


Triggering Relationship: Beschreibt eine zeitliche oder kausale Beziehung zwischen Elementen.


In diesem Beispiel zeigen wir, wie ein einfacher Geschäftsprozess standardisiert modelliert werden kann.

 

ZUSAMMENFASSUNG

ArchiMate ist eine grafische Modellierungssprache. Sie stellt einen herstellerunabhängigen Standard zur Verfügung.  Sind die Elemente und Relationen einmal gelernt können die Modelle, unabhängig von der Quelle, von jedem gelesen werden.

Wir können sowohl die Geschäftsseite (Prozesse, Services, Personen, Abteilungen) als auch die Applikations-/Infrastrukturseite (IT) beschreiben, um Kohärenz zu zeigen und Entscheidungen über Veränderungen zu treffen.

Im nächsten Teil dieser Serie werden wir uns ansehen, wie Starbucks nach einer Self Service Lösung sucht und welche Auswirkungen diese auf die Struktur des Unternehmens (Business-Architektur) hat.

 

All content Copyright © 2018 The Unit BV/The Netherlands.

Das Architecture Charter

Wofür braucht man es und was sollte drin stehen?

Das Architecture Charter ist weniger bekannt als das Project Charter, erfüllt aber einen sehr ähnlichen Zweck. Es begründet den Aufbau, und definiert wichtige Ecksteine, der Enterprise Architecture (EA) Organization im Unternehmen. Es ist notwendig damit Schlüssel-Akteuren frühzeitig der Durchführung und den Ergebnissen der Maßnahme zustimmen können. Des Weiteren hilft es dabei ein gemeinsames Verständnis zu schaffen und falschen Erwartungen vorzubeugen.

Inhalt des Architecture Charters

TOGAF® kennt zwar das Architecture Charter, gibt aber nicht viele Unterstützung beim konkreten Inhalt. Einzig zum Thema Leistungsmessung der Architektur Funktion gibt es ein paar Sätze im Abschnitt über das Architecture Repository (Part V). Die folgende Struktur bildet den Querschnitt aus Publikationen zum Thema und meinen eigenen Erfahrungen.

  • Übersicht
    • Mandat und Motivation für Aus-/Aufbau der EA-Organisation
    • Welche Unternehmensziele werden dabei, wie unterstützt
    • Die wichtigsten Anforderungen an die EA
    • Zusammenfassende Erklärungen zum nachfolgenden Inhalt
  • Umfang (Scope)
    • Welche Teile des Unternehmens bilden die Enterprise
    • Die wichtigsten Stakeholder-Gruppen und deren grundlegende Aufgaben
    • Die wichtigsten Anwendungs- und Infrastruktur-Elemente (Software / Hardware)
    • Roadmap bei stufenweiser Einführung/Ausbau.
  • Steuerung (Governance)
    • Organisations-Struktur
    • Übersicht der Akteure, Prozesse, Funktionen
    • Architecture Board – Zusammensetzung und Verantwortungsbereich
    • Ziele und Metriken (Key Performance Indicators)
  • Referenzen
    • Verweis auf Kommunikationsplan
    • Verweis auf Detail-Planung (ADD, ARS, I&M Plan)

Tipps zur Erstellung

Bei allen nicht-trivialen Maßnahmen zum Aus-/Aufbau der EA-Organisation, empfiehlt TOGAF® die Durchführung eines ADM-Cycles. Dadurch wird folgendes gewährleistet:

  • Stakeholder sind identifiziert und einbezogen.
  • Chancen und Risiken der Änderung sind bewertet und managed.
  • Definition und Abstimmung von Anforderungen für
    • Akteure, Funktionen und Prozesse
    • Datenhaltung, Werkzeuge und Schnittstellen
    • Infrastruktur
  • Anschaffungen, Implementierungen und Aus-/Weiterbildung wird koordiniert.
  • Gewährleistung der Fitness und Begleitung der Evolution der EA-Organisation.
  • Vollständigkeit der wichtigsten Dokumentationen

Das Architecture Charter übernimmt dabei die Rolle der „Architecture Vision“ aus der Phase A der ADM. Es ist eines der ersten Dokumente, dass an die Stakeholder kommuniziert und genehmigt wird.

Im wesentlichen bleibt das Architecture Charter auf einer strategischen Abstraktionsebene mit großer Übersicht und wenigen Details. Dies unterstützt die gewünschte Langlebigkeit und Stabilität des Architecture Charters. Details sind in den Ausarbeitungsdokumenten, wie dem Architecture Definition Document und dem Implementation and Migration Plan, zu finden. Die Beschreibungen sollten vorwiegend Diagramme, Tabellen und Listen sowie kurze, erklärende Texte beinhalten.

Quellen:

Communities

Die Gemeinschaft der Menschen besteht nicht von Natur, sondern um des Zuträglichen und des Bedürfnisses Willen. – Epikur von Samos (341 – 271 v. Chr.), griechischer Philosoph

Die Enterprise Architecture ist, wie schon erwähnt, eine vergleichsweise neue Disziplin. Um so wichtiger ist es sich zu Orientieren und von den Erfahrungen anderer zu profitieren. Soviel zu den Bedürfnissen der, nennen wir sie mal Konsumenten, in den Communities. Was ist den Autoren der Communities zuträglich? Nun, zum einen ist es der Wunsch sich mit anderen Auszutauschen und nützliche eigene Erkenntnisse zu teilen, zum anderen ist eine Community auch eine Platform für die Eigen- oder Produktdarstellung. Nicht zuletzt können Communities auch eine Rolle spielen als Job-Portal.

Ich werde im folgenden einige Communities aus dem Bereich der Enterprise Architecture vorstellen.

Association of Enterprise Architects

Die Ziele der AEA sind für das einzelne Mitglied die Beschäftigungsmöglichkeiten und Marktwert zu erhöhen sowie den gesamtem Berufsstand der Enterprise Architekten zu profilieren.

Die Mitgliedschaft ist, für nach TOGAF zertifizierte Architekten, zunächst kostenfrei und beträgt später 75$ pro Jahr.

Geboten werden das „Journal of EA“, regelmäßige Webinare zu spannenden Themen, wie zum Beispiel Innovations Management, sowie die Mitarbeit in verschiedene Foren und Interessengruppen. Im Karriere-Bereich kann man sein Profil mit anderen teilen oder nach möglichen Mitarbeitern suchen.

Die AEA ist global ausgerichtet, es gibt aber auch regionale Gruppen, sogenannte Chapter. Leider gibt es zur Zeit keine deutsche Sektion. Aber was nicht ist, kann ja noch werden.

Hier der Link: https://www.globalaea.org/

The Open Group

Die Open Group ist eine globales, herstellerunabhängiges Konsortium und bietet Mitgliedschaft auf verschiedenen Ebenen an. Zum einen für natürliche Personen (Professionals) als auch für Unternehmen (Member Organisation).

Ziel der Open Group ist die Unterstützung der Mitglieder bei der Erreichung ihrer Unternehmensziele mit Hilfe von Vorgehens- und Technology-Standards, welche gleichzeitig die Best-Practice formulieren.

Momentan hat die Open Group über 580 Mitglieds-Organisationen aus unterschiedlichsten Bereichen, wie Tool-Hersteller, Entwickler von System-Lösungen, Behörden und  Unternehmen, sowie Forschung und Bildung. Namhafte Mitglieder sind: Fujitsu, IBM, Oracle Corporation, Accenture, Boing, US Ministry of Defense, Apple, Deloitte Consulting, Munich Re (Münchner Rück), Red Hat, Software AG, Carnegie Mellon University – Software Engineering Institute, uvm.

Als Mitglied ist es möglich sich an der Weiterentwicklung der OG-Frameworks, wie TOGAF® und ArchiMate® zu beteiligen. Dies geschieht in sogenannten Foren meist über Collaboration Tools aber auch bei den weltweit stattfindende Treffen und Kongressen in persona.

Ähnlich wie die AEA gibt es für individuelle Mitglieder die Möglichkeit ein Job-Profil zu hinterlegen und sich an den Diskussionen in den verschiedenen Foren zu beteiligen.

Hier der Link: http://www.opengroup.org/

LinkedIn

Innerhalb des sozialen Netzwerks LinkedIn gibt es einige Gruppen, die sich mit dem Thema der Enterprise Architecture befassen. Die Größte davon ist die Gruppe „The Enterprise Architecture Network“ mit momentan über 160.000 Mitgliedern. Die Mitgliedschaft bei LinkedIn sowie die Freigabe des Gruppenverantwortlichen sind Voraussetzung für die Teilnahme an dieser Community. In der Gruppe befinden sich nicht nur Enterprise Architekten, sondern einen Vielzahl von Personen unterschiedlicher Rollen, wie CIO, CTO, IT-Strategen, Business-, Anwendungs- und Technolgie-Architekten, sowie Corporate- und IT-Governance.

Ebenfalls mit EA befasst sich das Enterprise Architecture Forum. Hier geht es vor allem um Vorgehensmodelle, also die Best Practice. Überschneidungen mit der EA Network Gruppe gibt es, allerdings Bedarf es für die Mitgliedschaft im EA Forum keine Freigabe des Gruppenverantwortlichen. In LinkedIn gibt es aber noch weitere Gruppen zu spannenden Themen wie TOGAF® und ArchiMate@. Die Gruppen bieten jeweils ein Forum zum Austausch und zum Fragen stellen.

Gruppe „The Enterprise Architecture Network“: https://www.linkedin.com/groups/36781/profile

Gruppe „Enterprise Architecture Forum“: https://www.linkedin.com/groups/36248

Gruppe „TOGAF®“: https://www.linkedin.com/groups/60545

Gruppe „ArchiMate®“: https://www.linkedin.com/groups/50758

Deutsche EA-Communities in Meetup

Meetup ist ein Social-Networking-Service, der für die Organisation und/oder Teilnahme an Gruppentreffen im realen Leben (IRL) gedacht ist.

Auch im Umfeld der EA werden regelmäßige, meist monatliche, Treffen organisiert. So gibt es derzeit Gruppen in Berlin, Frankfurt, Hamburg, Köln und Stuttgart, welche sich mit Themen der EA, Microservice Architekturen und Domain Driven Development (DDD) beschäftigen.

Hier der Link: https://www.meetup.com/de-DE/topics/entarchitecture/