Was ist neu in ArchiMate 3.1

Seit Anfang November gibt es eine neue Version von ArchiMate. Was hat sich geändert und was ist neu? 

Das es sich um keine umfangreiche Änderung handelt, erkennt man schon an dem kleinen Sprung in der Version von 3.0.1 auf 3.1. Die größte Neuerung ist dabei das zusätzliche Element für Value Streams im Strategy Layer. Wer mehr über Value Streams erfahren möchte, kann sich hier einlesen.

Value Stream-Element

Die Definition in der ArchiMate-Referenz sagt folgendes: „Ein Value Stream stellt eine Abfolge von Aktivitäten dar, die für einen Kunden, Stakeholder oder Endverbraucher ein Gesamtergebnis ergeben.“ Eine Abfolge von Aktivitäten kennen wir bereits aus den Core-Layers z.B. als Business Process. Der Unterschied zum Prozess ist die Betrachtungsebene. Der Value Stream ist am meisten verdichtet und zeigt sehr abstrakte Handlungen. Der Value Stream ist agnostisch gegenüber seiner konkreten Realisierung durch z.b. Geschäftsprozesse und IT-Lösungen. Das bedeutet, das Value Streams ohne genaues Wissen oder Erkenntnis der Umsetzung auskommen. Das hat den großen Vorteil, dass man nun trennen kann zwischen sehr groben Aktivitäten wie z.b. „Produkt entwickeln“, „Produkt vermarkten“, „Produkt verkaufen“ und feiner Aktivitäten wie „Online-Werbung schalten“ oder „Kundenanfragen am Telefon beantworten“.

Wie man das Produkt genau entwickelt, vermarktet und verkauft ist hier ausserdem gar nicht von Bedeutung. Die Annahme ist, dass der Value Stream stabiler ist als die konkrete Umsetzung. Auch in Zukunft werden also Produkte entwickelt und vermarktet bevor man sie verkauft aber womöglich auf eine ganz andere Weise.

Value Stream Element

Die Notation des Elements ist ein Pfeilsegment. Es ist ähnlich zu dem Funktions-Symbol, hat aber eine andere Richtung, nämlich von Links nach Rechts. An den abgerundeten Ecken kann man erkennen, daß es sich um ein Verhaltenselement (Behavior) handelt.

Es ist auch erlaubt, das Pfeilsymbol selbst als Element zu nutzen. Das Element würde dann so aussehen:

Das Symbol für Value Stream

Beispiel Value Stream

Üblicherweise bilden die Elemente eine Kette um auszudrücken, welche Zuarbeiten und Voraussetzungen für das erreichen des Endresultats benötigt werden. Dabei stellt dann ein Element eine Stufe (Stage) des Value Streams dar.

Beispiel eines Value Streams

Das Beispiel zeigt, welcher Geschäftswert (Value) von den Stufen des Value Streams erzeugt werden. Zusätzlich zeigt es Fähigkeiten (Capabilities) und Ressourcen, welche an den jeweiligen Stufen beteiligt sind. Dies ist eine Betrachtung des Geschäftsmodells auf höchster Ebene. Andere Value Streams sind sinnvolle Ergänzungen um für bestimmte Stakeholder und Organisationseinheiten mehr Transparenz und Kontext zu erzeugen. So könnte für die Fertigung zusätzliche Wertschöpfungsströme visualisiert werden.

Gerichtet Assoziationen

Ebenfalls neu in ArchiMate 3.1 sind gerichtete Assoziationen:

Gerichtete Assoziation

Das Beispiel zeigt, dass Schriftwechsel und Bestellungen eine Verbindung mit Kundendaten haben. Die Richtung hilft später im Design der Schlüssel- und Fremdschlüssel-Verbindungen.

Damit die gerichtet Assoziation (directed association) nicht mit der Serving-Beziehung verwechselt werden kann, hat sie nur eine halbe Pfeilspitze. Je nach Ausrichtung des Ursprungs- und Zielelements, liegt die Pfeilhälfte über oder unter dem Graphen bzw. recht oder links davon. Natürlich kann man auch weiterhin die nicht-gerichtete Assoziation ohne Richtungspfeil verwenden.

Die gerichtete Assoziationsbeziehung kann nun noch besser verwendet werden um erste, grobe Entwürfe zu erstellen. Man kann Beziehungen zunächst generisch erfassen und später durch besser passenden ersetzen. Die Richtung von Sequenzen oder Informationsflüssen bleibt dabei nun erkennbar

Der Formhalber sollte ich erwähnen, dass die Assoziation in eine andere Kategorie gewandert ist. Sie ist jetzt den Dependency-Relationships (Abhänigkeitsbeziehungen) zugeordnet.

Ableitungsregeln

Der Bereich der abgeleiteten Beziehungen ist in ArchiMate 3.1 umfangreicher beschrieben und formaler in Regeln gefasst. Dies dürfte es den Tool-Herstellern erleichtern die Ableitungsregeln zu implementieren. Das wiederum verbessert die Analysemöglichkeiten der Modelle.

Was Ableitungen sind, möchte ich auch noch kurz zeigen:

Modell und Ableitung

Im linken Bereich sehen wir das Modell: Die Banking App realisiert das Online-Banking und dies dient dem Hans. Jetzt kann man Fragen: Welche Beziehung besteht zwischen der Banking App und Hans. Diese Beziehung ist im Modell nicht explizit vorhanden, kann aber abgeleitet werden. Der rechte Teil des Bildes oben, zeigt die abgeleitete Beziehung: Serving. Wie gesagt, diese wurde nicht modelliert sondern ergibt sich aus den Regeln. Dies ist nur ein kleines Beispiel aus den vielfältigen Möglichkeiten nicht modellierte Beziehungen abzuleiten.

Das waren die Änderungen und Neuerungen von ArchiMate 3.1. Am Rande sei noch bemerkt, dass die Zertifizierungsprüfungen noch bis in das Jahr 2021 auf der Version ArchiMate 3.0.1 basiert bleiben.

Quelle: ArchiMate 3.1 Online-Referenz (Englisch)

Was ist ein Value Stream und wo liegt der Unterschied zur Value Chain?

Sowohl Value Stream als auch die etwas älter Value Chain dienen der Modellierung auf der Ebene der Business Architektur. Es gibt Ähnlichkeiten, schon in der Definition:

Value Chain:

Eine Value Chain ist eine Reihe von Aktivitäten, die ein Unternehmen in einer bestimmten Branche durchführt, um ein wertvolles Produkt oder eine Dienstleistung für den Markt zu liefern.

und

Ein Klassifizierungsschema für die gesamte Palette der primären und unterstützenden Aktivitäten, die zum Lebenszyklus der Nettowertschöpfung eines Marktangebots beitragen.

(Aus dem 1985 veröffentlichen Buch „Competitive Advantages: Creating & Sustaining Superior Performance“ von Michael Porter)

Value Stream:

Die Maßnahmen, die erforderlich sind, um ein Produkt oder eine Dienstleistung durch die drei kritischen Managementaufgaben eines jeden Unternehmens zu bringen:

  1. Problemlösung (z.B. Design)
  2. Informationsmanagement (z.B. Auftragsabwicklung)
  3. Physische Transformation (z.B. Herstellung eines physischen Produkts oder Erbringung einer Dienstleistung)

(Aus dem Buch „Lean Thinking“ von James Womack & Dan Jones aus dem Jahre 1996)

und

Eine Darstellung einer durchgängigen Sammlung von wertschöpfenden Aktivitäten, die ein Gesamtergebnis für einen Kunden, Stakeholder oder Endanwender schaffen.

(Aus TOGAF® 9.2)

Beiden gemeinsam ist die Betrachtung der Aktivitäten, die es braucht um ein Produkt oder Service erfolgreich und nachhaltig anzubieten.

Was kann ich damit anfangen?

Der Value Stream zeigt auf eine business-zentrischen Weise, welche Aktivitäten nötig sind um den eigentlichen Nutzen oder das eigentliche Ziel zu erreichen. Sehr hilfreich ist dabei, dass zu den Phasen des Value Streams bestimme Fähigkeiten (Capabilities), Kenntnisse und Ressourcen zugeordnet werden können. Hier ein Beispiel:

Das Ziel ist es einen leckeren, regionalen und frisch zubereiteten Fisch zu essen. Bevor es aber soweit ist, muss der Fisch gefangen und zubereitet werden. Dies zeigt der Value Stream.

Darunter sehen wir welche Fähigkeiten (Capabilities) wir dazu benötigen. Diese Betrachtung alleine ist schon sehr hilfreich, besonders auf einem strategischen Level. Dort sind (Business-) Capabilities schon lange bekannt. Sie sind allerdings eine statische Betrachtung. Dank des Value Streams können wir die Capabilities in eine logische Reihenfolge bringen, wobei am Ende der Reihe das eigentliche Ziel steht. In unserem Fall, den Fisch zu essen. Wir können sogar noch weiter gehen und Ressourcen aufzählen, welche wir in den jeweiligen Schritten benötigen. Dies ergibt eine Ansicht, welche für den Exekutivbereich und zum Verständnis der Wertbeiträge sehr nützlich ist.

Quellen:

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

http://pubs.opengroup.org/it4it/refarch20/

https://www.systems2win.com/LK/lean/VSMsegments.htm

http://pubs.opengroup.org/architecture/togaf92-doc/arch/

Was ändert sich mit TOGAF® 9.2?

Bevor ich zu den Details komme noch eine beruhigende Nachricht an alle nach TOGAF® 9 zertifizierten Personen. Es ist keine neue Zertifizierung notwendig! Bestenfalls ist nur am Datum erkennbar, ob die Zertifizierung nach Version 9.1 oder 9.2 vorliegt. Dennoch wird es einen Übergang der Prüfungsfragen auf Version 9.2 geben. Die Übergangszeit ist nötig damit Schulungsinstitute und Verlage ihre Unterlagen auf die neuen Inhalte und Prüfungsfragen auszurichten können.

Die größte strukturelle Änderung sollte sich in der Dicke des TOGAF-Buches ablesen lassen. Viele Inhalte des 9.1er-Buches werden in die TOGAF Library ausgelagert. Der normative TOGAF-Kern wird von den Guidelines, Tools und Techniken getrennt. Dies ist eine cleverer Zug, da sich Erfahrungsgemäß weniger die Ansprüche an die Enterprise Architecture ändern, als die Mittel die Ansprüche zu befriedigen. Dies erlaubt nicht zuletzt eine größere Dynamik bei der Weiterentwicklung von TOGAF.

Ebenfalls neu ist der Begriff des Architecture Style. Hierbei wird Rechnung getragen, daß sich eine Architektur auf unterschiedliche Weiße erstellen läßt und eigene Prinzipen und Charakteristiken der Steuerung existieren. Die Bandbreite geht hier von wenig gesteuerten bis stark gesteuerten sowie service-orientierten Ansätzen.

Ebenfalls neu sind Betrachtungen der Business Capabilities, Value Streams und Course of Actions besonders bei der Business Architecture (Phase B).

Die Abstimmung mit dem ISO-Standard 42010 zum Thema Architektur Beschreibung wurde aktualisiert, da die letzte Änderung des Standards von 2011 zu spät kam um in TOGAF 9.1 integriert zu werden. Dies ist nun erfolgt.

Auch im Meta-Model des Content-Frameworks hat es Änderungen gegeben. Neu im Model sind besagte Business Capability, Value Stream und Course of Action. Die Location wurde aus der Extension in den Core gezogen. Selbstverständlich gibt es auch neue Artifacts/View Points, welche die neuen Entitäten beinhalten.

Das Thema Enterprise Security hat einen größeren Stellenwert erhalten und ist nun ausführlicher Beschreiben. Auch der Begriff Risiko erhält einen frischeren, weniger düsteren Anstrich. Das liegt daran, daß ein „gesundes“ Maß an Risiko dazugehört und Chancen auf Erfolg, wie Misserfolg birgt.

Soweit zu den wichtigsten Neuerungen. Wer Lust bekommen hat Tiefer einzutauchen kann TOGAF 9.2 online lesen!

Welchen Ansatz würden Sie in den ersten drei Monaten der ersten EA-Implementierung wählen?

Da Sie nicht auf einer grünen Wiese starten, gibt es bereits heute Prozesse und Funktionen auf dem Weg von der Planung zum Betrieb. Der Fokus sollte am Anfang auf Bottle-Necks dieser vorhandenen Arbeitsweise liegen. Auch die EA muss ihren „Business Value“ so schnell wie möglich realisieren, nicht erst in Jahren. Konzentrieren Sie sich auf die tief hängenden Früchte, um zu zeigen, dass Sie auf dem richtigen Weg sind und dass die neue EA-Capability einen Mehrwert bietet. Beachten Sie, dass es zwei Kräfte gibt, welche die Betriebsmodi definieren: Top-Down- und Bottom-Up-Kräfte. Klassischerweise ist EA eher ein Top-Down-Ansatz, während agile Prozessmodelle oder „ungesteuerte“ Unternehmens-Architekturen auf Bottom-up-Kräfte setzen: Je besser ein Ansatz / eine Technologie ist, desto mehr Menschen nutzen diesen Ansatz / diese Technologie. Gravitation ist übrigens eine Bottom-Up-Kraft. Der Trick besteht darin, genügend Platz für ein Bottom-up-System zu lassen und dann die sich entwickelnden Best Practices in die EA-Guidelines aufzunehmen. Dies unterstützt sehr gut das Innovationsmanagement.

Haben Enterprise Architekten einen Gott-Komplex?

Neulich beim Treffen mit einem Freund stand diese Frage plötzlich im Raum. Der Freund arbeitet bei AWS, leitet Boot Camps und verdingt sich ansonsten im Bereich Deep-Learning.

Nach seiner Meinung wollen die Enterprise Architekten alles im Vorfeld planen und später alles kontrollieren. Das kann man nicht verneinen, denn das ist es was Enterprise Architekten tun. Doch jeder (gute) Enterprise Architekt weiß auch, daß die Planbarkeit Grenzen hat.

Aber ich vermute es geht nicht nur um die Planung sondern auch um die „Schöpfungshöhe“.
Schon während des Studiums ist mir aufgefallen, daß sich viele Kommilitonen als Künstler fühlten. Vielleicht lag es daran, daß ich Musiker bin und in einer Band damals eigene Songs spielte, um zu erkennen, daß Informatik soviel mit Kunst zu tun hat, wie Machinenbau oder Elektrotechnik. Es liegt ein wenig Chauviniesmus in der Luft, wenn die IT sich als die künstlerische Ausnahmeerscheinung der Ingeniers-Diziplinen wähnt.

Alles eine Frage der Zeit.

Die „Nerds“ vor 100 Jahren haben die ersten Flugzeuge in den Himmel gebracht. Würdest Du heute eine Linienmaschinen besteigen, wenn diese ohne Planung und Kontrolle gebaut oder betrieben wird?
Die „Nerds“ vor 1.000 Jahren haben die ersten Kathedralen konstruiert und bauen lassen. Zur damaligen Zeit unglaublich komplexe und große Konstruktionen, die man heute noch bestaunt. Heute erstellen, bis auf einige Ausnahmen, namenlose Architekten größere, funktionalere und komplexere Gebäude. Halten sich dabei an Standards bei der Planung und Erstellung und kontrollieren den Baufortschritt.

Würde man den Gebäude-Architekten und Flugzeug-Ingenieuren von heute einen Gott-Komplex unterstellen? Ich denke, daß man in einigen Jahren oder Jahrzehnten eher verwundert ist, wie man „digitale Kathedralen“ ohne Planung und Prüfung bauen konnte.

Enterprise Architekten sollten deshalb aber keinen Gott-Komplex haben oder ausbilden. Es ist eben nicht alles im Detail planbar. Mut zur Lücke ist gefragt. Aktuelle Praktiken haben das längst partizipiert und können mittels Interationen und agilen Prozessen mit einer guten Portion anfänglicher Ungewissheit umgehen. Umgekehrt sollte man als „IT Künstler“ keine Angst oder Feindseligkeiten ausprägen. Die IT-Industrie folgt hier nur einer Entwicklung, welche andere Industrien schon vollzogen haben.

Es wird viel erzählt über MicroServices. Wo finde ich hilfreiche Information, wie das wirklich funktionieren kann?

Wie das wirklich funktionieren kann, ist von vielen Faktoren abhängig, nicht nur technischen.

Für Dein Grundlagen-Verständnis über Micro Services sollte Wikipedia ausreichen:
https://de.wikipedia.org/wiki/Microservices

Martin Fowler ist ein Pioneer der Micro Services und veröffentlich gute Artikel zum Thema:
https://www.martinfowler.com/articles/microservices.html
https://martinfowler.com/articles/microservice-trade-offs.html

Wie alle Service-Orientierten Paradigmen verlangen Micro Services ab einer gewissen Projekt- oder Portfolio-Größe ein gutes Informations-Management und eine reife Architektur-Fähigkeit der Organisation.

Durch die höhere Anzahl an Komponenten entstehen mehr Architekturbausteine als bei anderen Architekturstilen. Micro Services gehen deshalb einher mit anderen, unterstützenden Praktiken, insbesondere DevOps. Die Forderung von DevOps alles zu automatisieren und häufig zu liefern, ermöglichen erst die effiziente Entwicklung und Betrieb von Micro Services.

Eine schnelle, robuste Infrastruktur wird benötig. Generell ist HTTP und Restful-API die Basis der Kommunikation zwischen den Komponenten. Weil jede Komponente nur eine einzige, meist sehr dezidierte Aufgabe erfüllt, wird bei der Abarbeitung der Geschäftsprozesse mehr Kommunikation erforderlich als bei klassischer Service Oriented Architecture (SOA) oder Monolithen.

Die Best Practice dieses Architekturstils zielen darauf die Parallelität von Komponenten dynamisch den Anforderungen anzupassen. Dies geschieht durch die automatische Installation und Konfiguration oder Deinstallation der Services. Das flexible Kombinieren mehrerer Services zu einer Komposition bezeichnet man als Orchestrierung.

Insgesamt stellen Micro Services ab einer gewissen Komplexität, hohe Anforderungen an die Architektur-Fähigkeit im Unternehmen. Wer keine Erfahrungen hat, sollte ein Business Transformation Readiness Assessment durchführen. Hierbei werden nicht nur technische Aspekte betrachtet sondern weitere Faktoren wie Motivation und Kompetenzen.

Ab welcher Unternehmensgröße braucht man eine EA?

Aufgaben der Enterprise Architektur werden auch in kleineren Unternehmen wahrgenommen ohne das dabei eine eigene Abteilung bzw. EA-Organisation besteht.

Die Definition einer Enterprise gibt keinen Hinweis auf die Unternehmensgröße. Die kleinste Organisationseinheit einer Enterprise die TOGAF kennt ist die Abteilung.

Wir raten zu einer dezidierten EA-Organisation  in Unternehmen mit

  • über 300 Mitarbeitern, welche direkt oder indirekt an der Architektur-Landschaft mitwirken
  • einem Investitionsvolumen der Architektur-Landschaft im zwei-stelligen Millionenbereich