Innovative Architektur als Teil der IT-Strategie

Innovation im Enterprise – geht das?

Stefan von Brauk
©Shutterstock/ ra2studio

Architektur bewegt sich in einem komplexen Spannungsfeld von einander zum Teil widersprechenden Anforderungen und Wünschen einer Vielzahl von Stakeholdern. Während es für den Architekten schon schwierig genug ist, diese Interessen in der Architektur , d. h. Daten-, Applikations- und technische Architektur, so auszubalancieren, dass die Businessanforderungen angemessen umgesetzt werden können, ist der Wunsch nach (oder Zwang zur) Innovation eine zusätzliche Herausforderung.

Der Begriff der Innovation ist in der IT durchaus positiv besetzt: neue Produkte, neue Technologien, neue Serviceangebote, selbst neue IT-basierte Geschäftsmodelle werden schnell mit „Innovation“ assoziiert. Für viele Menschen gilt die IT sogar als Innovationsmotor schlechthin. Aber was bedeutet Innovation in Bezug auf Architektur und Architekturmanagement? Und welchen Einfluss hat das Thema auf die Arbeit des Architekten? Um sich diesen Fragestellungen zu nähern, ist es hilfreich, erst einmal einen genaueren Blick auf den Begriff der Innovation zu werfen. Wikipedia.com skizziert eine Innovation wie folgt: „Innovation is the development of new values through solutions that meet new requirements, inarticulate needs, or old customer and market needs in value adding new ways.“

In dieser generischen Beschreibung deuten sich einige Merkmalszüge einer Innovation an, die für die Bewertung von Architekturen hinsichtlich ihrer Innovationsfreude von Bedeutung sind:

  • Innovation ist wertsteigernde Verbesserung: Die Erstellung einer alternativen Lösung, die keinen zusätzlichen Nutzen beinhaltet, ist somit keine Innovation. Ebenso wenig ist die Nutzung neuer technischer Produkte ohne korrespondierenden Business Value eine Innovation.
  • Innovation kann auf verschiedene Dimensionen der Verbesserung abzielen. Hierbei ist in Bezug auf Architektur insbesondere an Schnelligkeit der Produkterstellung, Wirtschaftlichkeit, Kundenzufriedenheit, Qualität usw. zu denken.
  • Innovation ist relativ (bezogen auf den aktuellen Zustand): Was in einem Unternehmen ein alter Hut ist, kann also in einem anderen Unternehmen immer noch eine Innovation darstellen.
  • Innovation geht über bloße Optimierung und Verfeinerung hinaus: die Neuartigkeit ist signifikanter Teil der Definition.
  • Innovation ist konkret: Innovation zielt auf die Implementierung von Lösungen, Produkten und Prozessen ab und ist damit auch von einer Erfindung abzugrenzen.

Innovativ oder innovationsfreundlich?

Nachdem diese Kriterien entwickelt sind, kann die Frage, was denn nun eine innovative Architektur ist, etwas konkreter angegangen werden: Unter einer innovativen Architektur wird im Folgenden insbesondere eine Architektur verstanden, die aufgrund ihrer Struktur, der verwendeten Produkte, Technologien und Werkzeuge und/oder der in ihr verankerten Produktionsprozesse die oben genannten Kriterien erfüllt. Noch vor wenigen Jahren galten beispielsweise serviceorientierte Architekturen, Architekturen auf Basis von offenen Plattformen wie JEE oder .NET, aber auch produktorientierte strategische Plattformen (Stichwort SAP) oder die Verwendung von 4GL-Werkzeugen als innovativ. Diese kurze Liste verdeutlicht schon recht gut, dass der innovative Charakter einer Architektur an einen zeitlichen Kontext gebunden ist. Jede innovative Architektur hat ihre Zeit – war die Innovation erfolgreich, wird sie zur Commodity.

Weiterhin lassen sich innovative Architekturen von solchen Architekturen differenzieren, die „bloß“ innovationsfreundlich sind. Wo ist der Unterschied? Zuerst einmal ist festzuhalten, dass eine innovationsfreundliche Architektur noch keinen neuen Business Value erzielt. Aber eine innovationsfreundliche Architektur zeichnet sich dadurch aus, dass auf Basis dieser Architektur technische oder Businessinnovationen ermöglicht werden, ohne notwendigerweise andere Architekturziele und -treiber zu vernachlässigen. Typische Architekturprinzipien einer innovationsfreundlichen Architektur können beispielsweise sein: Serviceorientierung, Nutzung leichtgewichtiger Architekturkonzepte, lose Kopplung usw.

Demgegenüber weisen innovative Architekturen alle Merkmale einer Innovation auf – allerdings bedeutet dies nicht, dass sie auch selbst zwangsläufig innovationsfreundlich sind. Je nach Kontext können beispielsweise auf 4GL-Sprachen basierende Architekturen oder produktorientierte Architekturen innovativ sein, aber mittelfristig auch weitere Innovationen verhindern. Ebenso besteht das Risiko, dass durch einen Lock-in-Effekt – also der engen Bindung der eigenen Architektur an bestimmte Produkte oder Frameworks – die eigene Innovationsgeschwindigkeit von Dritten (das kann ein Softwarehersteller, aber auch eine Open-Source-Community sein) determiniert wird.

Führt man sich die Differenzierung von innovativer und innovationsfreundlicher Architektur vor Augen, ergibt sich für den Architekten natürlich das Idealziel, bezogen auf den konkreten Anwendungsfall, diejenige Architektur zu finden, die sowohl innovativ als auch innovationsfreundlich ist. Angesichts der vielen, oftmals sich widersprechenden Anforderungen, die an eine IT-Architektur gerichtet werden, stellt dies eine echte Herausforderung für den Architekten dar. Im Folgenden wird deshalb unter einer innovativen Architektur auch der Aspekt der Innovationsfreundlichkeit eingeschlossen (Abb. 1).

Aufmacherbild: Woman holding a glowing lightbulb in her hand von Shutterstock / Urheberrecht: ra2studio

[ header = Seite 2: Treiber innovativer Architekturen ]

Treiber innovativer Architekturen

Ausgehend von einem solchen Verständnis von Innovationen und Architektur stellt sich die Frage, warum in verschiedenen Organisationen der Innovationsgrad von IT-Architekturen völlig unterschiedlich ausgeprägt ist? Die Entwicklung oder Nutzung von Innovationen erfolgt offensichtlich nicht bei allen IT-orientierten Organisationen in gleicher Weise. Naheliegend ist, dass der Umgang mit IT-Innovationen sehr verschiedenen Voraussetzungen und Zwängen unterliegt:

  • Wirtschaftliche Notwendigkeiten sind eine starke Motivation, sich mit Innovationen auseinander zu setzen. Das Hervorbringen von Innovationen kann aber auch der Unternehmenszweck selbst sein (wie beispielsweise beim legendären Xerox PARC).
  • Die Unternehmenskultur kann von einer tiefen Innovationsfreude (wie bei vielen Start-ups) bis hin zu einer ausgesprochenen Innovationsfeindlichkeit ausgeprägt sein. Dies korrespondiert oftmals mit entsprechenden organisatorischen und regulativen Vorgaben. Eine restriktive Governance oder eine dokumentenorientierte IT-Bürokratie bringen nur selten mehr Innovationen als agile, an selbst erschaffenen Produkten orientierte IT-Abteilungen hervor.
  • Ebenso ausschlaggebend für die Nutzung oder Entwicklung innovativer Architekturen sind die personellen Befähigungen innerhalb einer IT-Abteilung. Ohne Offenheit gegenüber neuen Entwicklungen, beständigen Wissenstransfer aber auch Experimentierfreude erfolgt kein entscheidender interner Impuls zur innovativen Weiterentwicklung.
  • Zu guter Letzt werden häufig die für Innovationen zu Verfügung stehenden (bzw. fehlenden) finanziellen Mittel als limitierender Faktor angeführt. Der Einwand ist gewiss insoweit richtig, als dass Innovationen immer mit Investitionen verbunden sind. Allerdings beweist gerade die Start-up-Szene, dass Wettbewerbs- und Kostendruck durchaus geeignet sind, Innovationen hervorzubringen – ja geradezu überlebenswichtig sein können. Vor diesem Hintergrund kann der Eindruck entstehen, dass das Argument der fehlenden finanziellen Mittel oftmals nur als Platzhalter für andere Gründe dient.

Abb. 1: Innovationstreiber bei Architekturen

Impediments entfernen – Innovationen ermöglichen

Sollen innovative Architekturen hervorgebracht oder eingeführt werden, ergeben sich auf der strategischen wie operativen Ebene des Architekturmanagements verschiedene Aufgaben und Herausforderungen. Zum einen ist die Frage zu beantworten, wie in der eigenen Organisation Innovationen hervorgebracht werden (sollen). Ein in der Literatur oft skizzierter Top-down-Ansatz ist die Implementierung eines differenzierten Innovationsmanagements, das als zusätzliches Element der Aufbauorganisation Innovationen im Unternehmen entwickeln und fördern soll [1], [2].

Dieser Ansatz wird z. T. eingesetzt, ohne zu hinterfragen, warum ein Unternehmen nicht in der Lage ist, ohne solche expliziten Strukturen Innovationen zu kreieren oder einzuführen. Betrachtet man die Geschichte der menschlichen Technologieentwicklung, scheint doch das Bestreben, Innovationen hervorzubringen, der menschlichen Kultur immanent – motiviert durch die Notwendigkeit, begrenzte Ressourcen immer besser auszunutzen, oder motiviert durch den Drang nach wissenschaftlicher Erkenntnis. Warum funktioniert dies nicht mehr in einem ausdifferenzierten sozialen System wie einem großen Unternehmen?

Fokussiert man diese Fragestellung wieder auf das enge Gebiet der IT-Architektur, kann man klar benennen, welche konkreten Hindernisse (im Folgenden in Anlehnung an den agilen Sprachgebrauch auch Impediments genannt) einem aktiven Umgang mit Innovationsthemen entgegenstehen. Tabelle 1 zeigt einige typische Impediments, denen sich ein Unternehmen bei der Entwicklung und Einführung von Innovationen stellen muss.

Domäne

Impediment

Strategische Ausrichtung

  • Stark reglementierender Governance-Ansatz
  • Restriktive Standardisierung
  • Fehlende Feedback- und Mitgestaltungskultur
  • Best-of-Suite- vs. Best-of-Breed-Ansatz [3]

Kommunikation und Unternehmenskultur

  • Politisch motivierte Einflussnahmen (Betriebsrat, regulative Vorgaben durch Gesetzgeber)
  • Bürokratisierung der IT

Operative Prozesse

  • Starre Vorgehensmodelle
  • Dokumentenzentriertes Entwicklungsmodell

Priorisierung und Kostenorientierung

  • Kurzfristige Umsetzung von Features höher priorisiert als strategische Architekturverbesserung
  • Fehlende Investitionsbereitschaft für Werkzeuge, Produkte, Ausbildung usw.

Tabelle 1: Typische Impediments

[ header = Seite 3: Innovation trotz oder durch Standardisierung? ]

Innovationen trotz oder durch Standardisierung?

Am Beispiel von „Standardisierung“ soll untersucht werden, wie solche Impediments ausgeräumt werden können und eine erhöhte Innovationsfähigkeit im Bereich der Architektur und des Architekturmanagements ermöglicht werden können.

Standardisierung ist ein notwendiger Baustein für professionelle Softwareentwicklung und IT-Architektur. Ohne Standardisierung ist die Entwicklung bis hin zum heutigen Status Quo nicht denkbar. Ebenso ist Standardisierung ein hervorragendes Mittel, Innovationen in die Fläche zu tragen. Nichtsdestotrotz wird in vielen Unternehmen Standardisierung als Impediment empfunden, Standardisierung konnte in verschiedenen Organisationen sogar als wesentlicher Grund für einen erheblichen Innovationsstau identifiziert werden. Die Fragestellungen in Tabelle 2 helfen, Impediments konkret zu erkennen. Sind diese erkannt, können sie leicht durch konkrete Änderungen adressiert oder schlichtweg im Sinne des Lean Managements entfernt werden [6].

Fragestellung

Bedeutung

Wer standardisiert?

  • Wer ist zuständig und kompetent, eine Standardisierung im Bereich Architektur durchzuführen (z. B. eine Abteilung „Enterprise-Architektur“)?
  • Ist eine solche Rolle identifiziert: Ist diese institutionalisiert und ist diese auch tatsächlich mit der Aufgabe betraut?
  • Wird die Rolle effektiv und effizient ausgefüllt?

Anhand welcher Kriterien wird standardisiert?

  • Wird anhand von konkreten Business-Needs standardisiert?
  • Wie gelangen diese an die Standardisierungsorganisation?
  • Wird ein Standard oder Blueprint entwickelt, um den konkreten Bedarf zu befriedigen – oder werden möglichst perfekte Lösungen gesucht (Stichwort „satisfying“ [5])?
  • Dient die Standardisierung der Innovationsentwicklung oder ist sie ein Mechanismus zur Kostensenkung?
  • Existiert im Hinblick auf Innovationen eine Priorisierung (ist die Standardisierung von Technologie wichtiger oder die Standardisierung von Prozessen)?

Wie erfolgt das Deployment?

  • Wie gelangen die Standards in die Produktentwicklung und den Betrieb?
  • Wie erfolgt die Rückkopplung (z. B. Messung, ob ein Standard erfolgreich im Sinne seiner Innovationskraft ist oder ob dieser modifiziert oder gar abgeschafft werden muss)?

Welche Mitwirkung ist möglich/wird gefordert?

  • Wie gelangen Informationen über erzielte Innovationen aus der Produktentwicklung und dem Betrieb in den Standardisierungsprozess?
  • Welche Mitwirkungsmöglichkeiten existieren für Architekten, Entwickler, IT-Manager?

Wie lange dauert der Standardisierungsprozess?

  • Was ist höher: die Standardisierungsgeschwindigkeit oder die Innovationsgeschwindigkeit (im zweiten Fall ist der gesamte Standardisierungsprozess zu hinterfragen)?

Welches Governance-Modell wird angewandt?

  • Welche Verbindlichkeit besitzen Standards?
  • Müssen Abnahmeprozesse durchlaufen werden?
  • Muss die Verwendung von Standards nachgewiesen werden und welche Dokumentationsnotwendigkeiten ergeben sich?
  • Welche offenen und verdeckten Kosten erzwingt das Governance-Modell?

Welcher Wert wird durch die Standardisierung erzielt?

  • Werden z. B. Referenzarchitekturen [4] definiert – und ergeben diese einen konkreten Wertbeitrag?
  • Wenn dies nicht der Fall ist – wie legitimieren sich die Aufwände der Standardisierung?

Tabelle 2: Fragestellungen zur Analyse der Standardisierungsbemühungen

[ header = Seite 4: Fazit ]

Fazit

Der Anspruch und die Notwendigkeit, innovativ zu sein, kontrastiert in der täglichen Praxis allzu oft mit innovationsunfreundlichen Architekturen, Prozessen und Organisationsstrukturen. Ein – im Vergleich zur Etablierung von expliziten Innovationsorganisationen – schlanker und kostengünstiger Ansatz ist es, Strukturen und Verfahren unter dem Blickwinkel der Innovationsfreude zu entschlacken, um so die Entwicklung von Innovationen zu fördern. Bezogen auf Architektur bedeutet dies, ausgehend von einer entsprechenden Priorisierung IT-Strategie und Governance neu zu tarieren und die Innovationsfreude der eigenen Organisation zu stärken. Dem Enterprise Architecture Management kann dabei eine zentrale Rolle zukommen, auch indem dieses einen aktiven – nicht auf Dokumentenaustausch beschränkten – Dialog mit der Produktentwicklung und Betrieb pflegt, um einen wesentlichen Beitrag dafür zu leisten, Innovationen organisationsweit zu entwickeln und anzuwenden.

Geschrieben von
Stefan von Brauk
Stefan von Brauk
Dr. Stefan von Brauk ist Management Consultant und Team Manager bei Cassini Consulting und berät u. a. Blue Chips in den Bereichen IT- und Architekturmanagement sowie Methoden der Softwareentwicklung.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: