Blockchain, Digitalisierung und Enterprise Architektur Management – wie kommt man aus der Wasser-Falle?

Eine 100 Tage EAM Reise - Teil 4 zu Enterprise Architektur Management mit Blockchain

Dieser Artikel ist Teil einer Serie, der einen roten Faden von der Theorie bis zur Praxis rund um das Thema Enterprise Architektur Management (EAM) spannen möchte. Denn irgendwie hängt alles zusammen! Die Frage ist, können wir einfach weitermachen wie bisher (insb. Hierarchie, fremdbestimmtes Arbeiten, Glaube an mechanistische Organisations-Metaphern wie Prozessmanagement), oder braucht die Digitalisierung und der damit einhergehende digitale Wandel nicht ein ebenso radikales Umdenken?

Hier geht’s zu den Artikeln der Serie:

  • EAM im digitalen Wandel
    Was ist eigentlich EAM, und wie kann man EAM in Zeiten des digitalen und krisengeschüttelten Wandels ge-win-win-bringend einsetzen?
  • 5 Erfolgsfaktoren bei der Einführung von EAM
    Welche Erfolgsfaktoren konnte ich aus meiner fast 20 jährigen Erfahrung in der IT Branche für EAM herausdestillieren?
  • 10 Tipps Für Die Ersten 100 Tage Einer EAM Reise
    Welches sind die wichtige und vor allem konkrete Themen, wenn man mit EAM selbst oder im Unternehmen neu startet?
  • Blockchain, Digitalisierung und EAM: passt das zusammen?
    Im aktuellen Artikel kommt der Praxistest: wie gehe ich „richtig“ und erfolgreich mit neuen und disruptiven Technologie „Blockchain“ um? Kann das überhaupt in klassischen Wasserfall-organisierten Konzernen funktionieren?

Do you (know how to) „Blockchain“?

Es gibt noch ganz wenige Anwendungsfälle der Blockchain. Sogar manche Startups haben sich bewusst dazu entschieden, dem Thema noch auszuweichen, zu disruptiv und revolutionär ist das neue Wunder der digitalen Persistierung von Daten jeglicher Art.

Fehlen die Use Cases?

Fehlt der Mut, wirklich etwas radikal Neues zu machen?

Ist die „Organisation Menschheit“ nicht auf dezentrale Steuerung ausgelegt?

Oder fehlt auch schlicht das Verständnis, was die Blockchain eigentlich ist?

Vor einigen Jahren, als ich selbst über das Thema gestolpert bin, habe ich endlose Gespräche mit meinen informatisch gebildeten FreundInnen geführt, und wir sind nie auf einen grünen Zweig gekommen. Zugegeben – wir haben natürlich immer den Use Case „Crypto Währung“ gesprochen, also einer zusätzlich komplexen Sache, trotzdem war es nicht leicht für uns, darüber zu philosophieren. Wie bei vielen theoretischen Ansätze fehlt einfach die Idee zur Anwendung.

Ein interessanter Einsatzbereich wäre darüberhinaus im Feld der Demokratie zu finden. Denn Transparenz, Sicherheit und damit der Besitz der eigenen Daten und Datenschutz bringt die Blockchain von selbst mit.

Weitere Beispiele neben Blockchain sind Quantencomputing, Künstliche Intelligenz, etc.

Blockchains und Crypto Währungen, Quantencomputing – gibt es überhaupt schon von Menschen begreifbare Anwendungen? Interessant wäre der Einsatz im Bereich der direkten digitalen Demokratie

Bei der Blockchain kommt vielleicht noch etwas dazu: man könnte meinen, die Art der dezentralen Speicherung von sensiblen Informationen ohne Intermediär (beim Use Case „Crypto Währung“ sind das die Banken), ist eine Revolution im Mindset, mit der das derzeitige „Establishment“ vielleicht nichts anfangen kann. Wenn sich die Beteiligten ihre Sachen selbst(verantwortlich) regeln, warum braucht es dann eine zentrale Stelle zur Koordination?

Blockchain: eine Revolution für den aktuellen gesellschaftlichen Mindset?

  • Viva la Revolución!

Klar ist, dass durch Einsatz von Blockchains erst wirklich digitale Anwendungen entstehen werden, weil die Daten egal von wo man sie aufruft immer in derselben Qualität bei gleichzeitiger Sicherheit abrufbar sind. Und wie bei der Crypto Währung ist der Clou, dass die Daten keine Intermediäre wie Banken oder Regierungen brauchen, also, eigentlich niemandem gehören. Anders gesagt, es könnte sein, dass zukünftig jeder wieder vielmehr Hoheit über ihre/seine persönlichen Daten bekommen könnte oder zumindest ganz genau weiß, was damit geschieht. Vielleicht gibt es auch deswegen keine Use Cases.

ZUM NACHLESEN: BLOCKCHAIN, SMART CONTRACT, etc.

EAM in Zeiten der Digitalisierung und des Wandels

Mein Cliffhanger und somit der rote Faden aus dieser EAM Serie:

Klassisches Wasserfall-getriebene IT-Systementwicklung mit einem ebenso klassischen EAM ist nicht in der Lage, digitale Szenarien abzubilden. Um zu erklären, wie ein Unternehmen hinsichtlich seiner Kultur, Organisation (und somit auch hinsichtlich EAM) und dem Umgang mit Menschen gestrickt ist, kann man ein Erklärungsmodell heranziehen, wie es Fredéric Laloux im Buch „Reinventing Organizations“ beschreibt.

Developmental Perspective on Organizations

Je nach Einstufung eines Unternehmen in dieses Modell kann man ableiten, ob Werkzeuge, Arbeitsweisen oder Technologien dazu passen, oder nicht. Hinsichtlich Technologie wäre die Blockchain eine, bei der die Stufe des Unternehmens bereits sehr fortgeschritten sein sollte.

Fazit: disruptive Technologien wie die Blockchain entfalten ihre Wirkung erst, wenn Unternehmen auch hinsichtlich ihrer evolutionären Stufe bereit dazu sind; falls das nicht so ist, so wird sich das Unternehmen mit der Technologie nicht „anfreunden“ können. Die Technologie ist quasi ein Indikator für die Stufe des Unternehmens.

Sind klassisch hierarchisch strukturierte Unternehmen überhaupt bereit für die digitale Revolution und disruptive Technologien wie die Blockchain?

Dieser 4. Teil der Serie über EAM beschäftigt sich mit der praktischen Frage, wie EAM aufgesetzt sein muss, um die digitalen Herausforderungen wie eine disruptive Technologie wie Blockchain oder neue Vorgehensmodelle wie Agilität zu meistern.

Nocheinaml wiederholen möchte ich, dass ich diesen Artikel im Lichte großer Unternehmen beleuchte, in dem starre alte hierarchische Mechanismen („Wasser-Falle“) auf neue disruptive Technologien treffen.

Beispiel Bankensektor: ein Kunde hat ein Konto bei einer Bank seines Vertrauens und einen persönlichen Berater in einer Bankfiliale. So sieht der Standard Use Case heute aus. Das ist einerseits sehr bequem, lokal und vor allem persönlich, bringt aber Herausforderungen bei allen Use Cases, die die Bankfiliale verlassen … also eigentlich alles Spannende wie Überweisungen auf Konten anderer Banken, Wertpapiergeschäfte, … denn dann müssen die IT-Systeme unterschiedlicher Bankfilialen miteinander sprechen. Und wahrlich Welt-umspannende digitale Use Cases in Echtzeit sind noch in weiter Ferne (Stichwort „Tagensendverarbeitung“, Monolithen am Host, …)!
Potential dezentrale Blockchain: spielt man das Gedankenexperiment durch, so wären diese Use Cases und vor allem der Echtzeitanspruch überhaupt kein Problem, wenn sich jede Bankfiliale jeder Bank als Teil eines Blockchain Netzwerks sehen würde. Auch hier gilt: das ist nicht nur technologisch sondern auch für den Banken-Mindset disruptiv!
Organisatorische Herausforderung Blockchain: wie funktioniert der Demand Prozess, um diese neue Technologie einzuführen? Wer bezahlt so etwas? Der Auftraggeber, der Auftragnehmer? Wenn produktiv, wie bringt man die ganze Legacy dazu, das neue „Shared Service“ Blockchain zu verwenden, die Applikationen zu migrieren? Ist der agile Mindset nur ein Feigenblatt in der IT-Strategie?

Aber was bedeutet das für die Organisation von IT-lastigen Unternehmen und für EAM, die noch in der schönen Welt des Wasserfalls leben? Ist es denn möglich, diese beiden Welten zu vereinen, oder prallen diese Welten mit Lichtgeschwindigkeit aufeinander und Anti-Materie ist das Ergebnis? Denn wenn auf Userseite alles schnell geht, dann muss es auch im Hintergrund bei der Entwicklung der IT-Systeme fetzen.

Die klassische Wasserfall-Vorgehensweise, die für hierarchische Organisationen maßgeschneidert ist, packt das einfach nicht:

  • große Arbeitsgruppen mit Einstimmigkeit zur Lösung von Konflikten
  • Prozess-Mentalität bei Anforderungen und System-Entwicklung
  • Projekt- bzw. Budget-Paradigma
  • keine wirklichen Produkt-Verantwortungen
  • keine durchgängige DevOps-Mentalität (z.B. starkes „Experten-Testing“)
Wieder Fredéric Laloux – Maschine und Organismus: er vergleicht Wasserfall Unternehmen gerne mit Maschinen mit ausgeklügelten mechanistischen Steuerungshebeln und Rechenlogiken. Als Kontrapunkt zur Maschine stellt er einen Organismus vor, also eine Menge von gleichgesinnten Menschen, die ähnlich einem menschlichen Körper mit seinen Organen funktionieren: adaptiv, schnell, dezentral, mit echter Arbeitsteilung. In dieser Analogie könnte man einen klassischen Persistierungsmechanismus wie eine Datenbank gar nicht einordnen, und die Blockchain könnte als Teil des Organismus die Rolle eines Organs haben, etwa dem Gedächtnis.

Wie kommt man denn nun aus dieser Wasser-Falle?

Zunächst möchte ich folgendes sagen: wenn ein Unternehmen in eine neue Richtung will, und hier dient die Frage „wollen wir eine Blockchain einsetzen“ als Beispiel, sind Authentizität, Hingabe und die Bereitschaft wirklich wichtig. Das war in der Vergangenheit vielleicht nicht so, am Beispiel Blockchain läßt sich jedoch gut zeigen, dass es hier nicht nur um eine x-beliebige neue Technologie handelt, sondern auch um eine Einstellung: Transparenz, Föderalismus, dezentrale Steuerung, geteiltes Eigentum, gänzlich andere Arbeitsweise bei der Entwicklung und im Betrieb, … um nur einige Kriterien zu nennen.

Anhand dreier ausgewählter Tipps aus Teil 3 der Serie möchte ich zeigen, wie das funktionieren könnte. Die linke Textspalte beschreibt das Problem, die rechte Spalte spielt den advocatus diaboli, der Bereich „Mögliche Lösungen“ versucht Lösungsansätze zu skizzieren.

Tipp 4: Geeignete EAM Ziele leben

„Agilität fördern!“ Das könnte eines von mehreren EAM Zielen sein. Neben den pragmatischen Herausforderungen einer gemeinsamen Sprache und der Etablierung eines Shared Service Verständnisses (siehe folgende zwei Blöcke) geht es zuerst einmal darum, sich wirklich klar zu werden, was man will.

Und beim Einsatz neuer disruptiver Technologien wie der Blockchain sollte man sich das gut und ganzheitlich überlegen. Halbe Sachen und erwähnte Feigenblätter tragen eher zum Scheitern als zum Erfolg bei.

Bei einem Ziel geht es um das WARUM (Vergangenheit, was ist der Gründungsgedanke des Unternehmens) und das WOZU (in welche Richtung soll es gehen), und das muss allen klar sein, wahrscheinlich macht es heute sogar Sinn, einen gemeinschaftlichen Versuch im Unternehmen zu machen. Die „Maschine“ Unternehmen muss sich zum „Organismus“ wandlen.

In beiden Fällen, dem WARUM und dem WOZU, braucht es ein geeignetes Mindset und einen Veränderungswillen, das Unternehmen und seine Kultur bewusst in eine neue Richtung zu steuern.

Keine Ziele, keine Richtung, und ohne Ziele reagiert man nur, mit Zielen kann man die Zukunft proaktiv gestalten. Und ein gut funktionierender Organismus braucht gute Ziele. Ganz besonders stark für den Erfolg von digitalen disruptiven Ansätzen wiegen die weichen Faktoren.

Es braucht einen extrem guten Zusammenhalt (ich hätte auch dass neudeutsche Wort Resilienz wählen können), um sein Geschäftsmodell schnell ändern zu können – auch das ist Digitalisierung.

Lösungsansätze

  • Bewusste Auseinandersetzung mit den Entwicklungsstufen von Laloux, Integration von Achtsamkeit, Fehlerkultur und bewertungsfreien offenen Dialogen
  • Aufbrechen des hierarchischen Einliniensystems in der Aufbauorganisation
    EAM Perspektive: Überdenken der klassischen Gremienstrukturen auf mehreren Ebenen (Steuerung, Management, operativ)
  • Verlassen der aufgeblähten Prozessparadigmen in der Ablauforganisation
    EAM Perspektive: in der IT hat man mit Agilität/SCRUM und DevOps schon zwei Ansätze, um das selbstverantwortliche Arbeiten zu stärken
  • KISS: weniger ist mehr … Konzentration in der Steuerung auf das Wesentliche (z.B. über ein Applikationsportfolio für eine gemeinsame Sicht auf die Archtutekturlandschaft, wenn Prozesse dann nur einfache Entscheidungsabläufe mit starker Verantwortung bei den Entwicklungsteams)

Was ist eigentlich „Achtsamkeit“? Versucht es selbst zu beantworten, indem ihr am Anfang einer Besprechung ein kurzes bewusstes zielgerichtetes Innehalten macht und schaut, was sich am Ergebnis der Besprechung ändert.

Ihr könnt dabei die Atmung der TeilnehmerInnen in Stille wie folgt anleiten:

Einatmen –> Lichte Leichtigkeit

Ausatmen –> Tiefe Entspannung

Danke Hermann Stein für die achtsamen Phrasen!

Tipp 6: Einfache gemeinsame Sprache

Angenommen, es gibt keine klaren Ziele. Damit ist es auch schwierig, eine Organisation zu steuern. Das kommt in den besten Organisationen vor! Und liegt am zuvor erwähnten mechanistischen Aufbau der Maschine Organisation: wenn es eher darum geht, wer der Chef von wem ist, dann treten Ziele – also transparente Willensäußerungen für die Zukunft – bald in den Hintergrund.

Und neben den Menschen ist die gemeinsame Sprache die Leidtragende! Und die fehlende gemeinsame Sprache macht eine gemeinsame Sicht auf die Architekturlandschaft unmöglich.

Denn die beste Definition und das ausgeklügeltste Glossar reichen bei weitem nicht für die komplexe Realität aus: jede Architektur ist eine Sammlung von Artefakten, auf die man sich in der Organisation einigen muss – Flughöhe bzw. Granullatität inklusive!

Wieviele Homo- oder Synonyme einer „Applikation“ kennt ihr denn bei euch? Ich habe einmal bei 20 aufgehört zu zählen. Wisst ihr, wieviele Java Applikationen ihr bei euch habt? Kommt bei Antworten mehrerer Manager immer dieselbe Zahl raus?

Lösungsansätze:

  • Für gemeinsames Arbeiten braucht es kein riesiges TOGAF Metamodell, ganz im Gegenteil: findet die Begriffe, die bei euch üblich sind und spielt es gemeinsam und konkret durch („eine Applikation kann aus Komponenten mehrerer Technologiestacks bestehen und hat eine ein-eindeutige Beziehung zu einem verrechenbaren Service“)
  • Aktualisierung der Architektur-Informationen gemeinschaftlich erarbeiten
  • Bekannte Artefakte oder Dokumente (z.B. Architekturdokumente, Architektur Onepager im Geschäftsbericht) sollten die Begriffe einheitlich verwenden; da kann man schon einmal freundlich insistieren

Tipp 8: Shared Services identifizieren

Große Konzerne reagieren behäbig und sind nach wie vor in Silos aufgebaut. Wiederverwendung als ein zentrales EAM Konzept ist da schwierig umzusetzen. Meist gibt es kein gemeinsames Verständnis, was ein Shared Service ist, und damit steht die Verantwortung nicht fest, oft gibt es kein Cost-Center, und somit gibt es auch keinen, der das Shared Service professionell wie ein Produkt entlang eines Lebenszyklus „vertreibt“. Und außerdem wäre das ja „not invented here“.

Und ich sage einmal, eine Blockchain ist nichts anderes als ein sehr verteiltes Shared Service mit einem sehr offenen Cloud Vertriebsmodell. Achtung Wasser-Falle!

Wie muss eine Organisation aufgestellt sein? Offentheit, Transparenz und Vertrauen sollten in der DNA enthalten sein. Daneben müssen die Struktur und die Governance aber vollkommen klar sein. 

Lösungsansätze:

  • Must have: Applikations-Portfolio mit Sicht auf die Shared Services und deren „Verbreitung“ (wieviele Applikationen müssten das Shared Service verwenden, wieviele verwenden es schon, daraus ergibt sich die Roadmap)
  • Ein Shared Service ist ein Asset, man erwartet sich Vorteile, daher braucht das Shared Service auch eine Dotierung (wenn man mit dem Budget-Mechanismus arbeitet) und eine/n Verantwortlichen, die/der auch Produktmanagement und Kundengewinnung und -betreuung erledigen

Mehr davon wenn ihr mich wiederseht, ihr müsst unbedingt gucken, wie’s weitergeht!

Dies ist der letzte Teil meiner vierteiligen Serie zum EAM im digitalen Wandel! Vielleicht habt ihr Gefallen daran gefunden, dass klassische Managementansätze wie EAM auch im digitalen und agilen Zeitalter ihre Bedeutung und auch beim New Work haben können. Das ist nämlich meine Überzeugung! Agil geht nämlich nur, wenn man seine sieben Sachen gut im Blick hat. Denn dann erst kann man zielgerichtet arbeiten und die agilen Früchte ernten!

Also, wenn ihr daran Gefallen gefunden habt, dann freut mich das, denn es gibt noch eine lange Liste weiterer Themen, die sich mit der zeitgemäßen Interpretation EAM beschäftigen! Ein paar Beispiele:

  • Zusammenarbeit EAM und Information Security (gemeinsam auf die Anwendungsverantwortlichen zugehen)
  • Tiefergehende Auseinandersetzung mit der Etablierung einer Shared Services Organisation (z.B. Scanning, Logging, CMS)
  • Verknüpfung von IT-Management Datentöpfen (z.B. EAM Tool und CMDB)
  • Strategische Kommunikation und Marketing von EAM Informationen (z.B. Geschäftsberichte)
  • EAM als Hebel für die wahre Agilität (exzellente Kenntnisse über das Inventar ermöglichen rasches Handeln und reduzieren Overhead)

Ich freu mich auf eure Meinungen und Kommentare und natürlich auf euch!

Aufgewachsen in Wien genoss Hannes Lischka eine akademische Ausbildung in Wirtschaftsinformatik. Seine mittlerweile 20 jährige Laufbahn führte ihn beinahe durchs gesamte IT-Management, der Fokus lag seit 2007 auf Enterprise Architektur Management (EAM). In den letzten Jahren erkannte er, dass nachhaltiger Erfolg weniger durch technokratische Prozesse als vielmehr durch die beteiligten Menschen entsteht. Seine Brücken baut er seitdem zwischen EAM und New Work.

Die Kommentarfunktion ist geschlossen.

MoreThanDigital Newsletter
Subscribe
Join the #bethechange community
close-image