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/

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.