Best Practice: 5 Schritte zur Minimum Viable Enterprise Architecture

Das richtige Maß finden: Viele IT-Führungskräfte versuchen, die Balance zu halten zwischen komplexen Architekturanalysen, die ungenutzt bleiben, und einfachen EA-Reports, denen es an Umfang und Tiefe fehlt.


Foto: Jelena Zelen – shutterstock.com

Beim Tele-Health-Anbieter Vault Health begann CTO Steve Shi die Arbeit an der Enterprise Architecture (EA) mit einer Bestandsaufnahme der gesamten IT-, Anwendungs-, System- und Dateninfrastruktur. Allerdings beschränkte er sich auf eine Dauer von zwei Wochen und einstündige Interviews zu jeder Funktion. Die Abnehmer, ob Mitarbeiter oder zahlende Kunden für Produkte oder Services, müssten das Ergebnis dieses Minimum-Viable-Ansatzes der EA “lieben”, behauptet Shi. “Wenn man nicht die Zustimmung der Kunden erhält, verliert man den Schwung, und wenn man den Schwung verliert, ist es schwieriger, nach dem Minimum Viable Launch weitere Schritte zu gehen”, sagt er.

Wie viele IT-Führungskräfte versucht auch Shi, die Balance zwischen komplexen Architekturanalysen, die ungenutzt bleiben, und einfachen EA-Reports zu halten, denen es an Umfang und Tiefe fehlt, um einen dauerhaften Wert zu schaffen. Für dieses Gleichgewicht muss man sich eng an den Business-Anforderungen orientieren, den Arbeitsaufwand reduzieren, das Projekt richtig einteilen und die passenden Architekturstandards und -prinzipien festlegen sowie durchsetzen. Erfahrene CIOs empfehlen dazu fünf Schritte, die im Folgenden erläutert werden.

Nur durch eine enge Kommunikation mit den Stakeholdern des Unternehmens lässt sich herausfinden, wo eine Minimum Viable Enterprise Architecture dem Business am besten helfen kann. Bei der Firma Carrier Global Corp. misst CIO Joe Schulz den Erfolg von EA anhand von Geschäftskennzahlen, beispielsweise wie sich die Anwendungsqualität oder Serviceausfälle auf die Produktivität der Mitarbeiter auswirken.

“Wir betrachten die Enterprise Architecture nicht als eine einzelne Gruppe von Leuten, die als Torwächter fungieren und eher theoretisch darüber nachdenken, wie etwas funktionieren sollte”, berichtet Schulz. Er nutzt Reports und Erkenntnisse, die das EA-Tool “LeanIX” generiert, zur Beschreibung der Interkonnektivität des Gesamtsystems sowie der Systemfähigkeiten im Portfolio, um Redundanzen oder Lücken zu erkennen. Dies ermögliche es dem Unternehmen, “einen Großteil der Entscheidungsfindung zu demokratisieren und die besten Kapazitäten für Innovationen und Investitionen innerhalb unserer Organisation zur Anwendung zu bringen”.

George Tsounis, Chief Technology Officer bei Stretto, einem Technologie- und Serviceanbieter für Konkursfälle, empfiehlt den Einsatz von EA, um “Vertrauen und Transparenz zu schaffen”. So informiert er die Unternehmensleitung über aktuelle IT-Ausgaben und diejenigen Bereiche, in denen IT-Plattformen nicht mit der Unternehmensstrategie abgestimmt sind. Das mache künftige EA-bezogene Gespräche “viel einfacher, als wenn der Unternehmensarchitekt in einem Silo arbeitet und diesen Draht nach oben nicht hat”, sagt er.

Langwierige Fragebögen und schablonengesteuerte Interviews sind ein vertrauter und oft unwillkommener Bestandteil von EA-Initiativen. Praktiker empfehlen, alle Fragen zu streichen, die keine wesentlichen Informationen liefern und kein echtes Feedback von den Anwendern zulassen. Gregor Hohpe, Director of Enterprise Strategy bei Amazon Web Services, empfiehlt beispielsweise, von “schwerfälligen, weitgehend einseitigen” EA-Prozessen zu einfacheren, schnelleren und iterativen Gesprächen mit Geschäftsanwendern überzugehen.

Beim Finanzdienstleister State Street strafft Global Chief Architect Aman Thind den EA-Prozess, indem er nur präzise und relevante Fragen stellt und nicht alles in ein starres EA-Template stopft. Die Konzentration auf die wichtigsten Fragen könne den Zeitaufwand für die Überprüfung der Architektur und die Einreichung mindestens um die Hälfte reduzieren und den Prozess wesentlich effektiver machen.

Neben dem Einsatz automatischer Compliance-Prüfungen und Self-Service-Plattformen empfiehlt Hohpe die Abschaffung “endloser Listen von Standards, die größtenteils ignoriert werden, von Review-Meetings, bei denen alle Dokumente auf der Grundlage des bevorzugten Ergebnisses entwickelt werden, von ‘Alignment'-Meetings zu nicht wertschöpfenden Themen sowie von riesigen Wandteppichen aus schwergewichtigen EA-Tools, die nie zur Entscheidungsfindung verwendet werden”.

Bei Vault, einem Unternehmen für digitale Gesundheitsfürsorge, findet CIO Shi das Application-Control-Tool “New Relic” nützlich, um die EA-Arbeit zu beschleunigen, weil es einen umgehenden Einblick in die Performance der gesamten Architektur bieten kann. Er verwendet zudem neue Begriffe und Prozesse, um häufige Barrieren zu umgehen und ein Bewusstsein für seinen neuen Ansatz zu schaffen. Als Beispiel verweist er auf den “Site Report”, der die Benutzer auffordert, sich das finale EA-Produkt vorzustellen. Auf diese Weise können kritische Anforderungen wie die Anzahl der Transaktionen und die Art der Prozesse, die eine Anwendung unterstützen muss, definiert werden, “ausgehend von der Kundenseite und rückwärts arbeitend”.

Anstatt die Benutzer zu bitten, einer kritischen technologischen Entscheidung von vornherein zuzustimmen, fordert Shi sie auf, “Entwicklungshypothesen” zu bestätigen oder zu überprüfen, beispielsweise die Anzahl der Datenbankaufrufe, die ein System pro Tag unterstützen muss. Dieser Ansatz beschleunige die Einigung über die Auswahl von Komponenten wie Datenbanken, sagt er.

Bei der Einführung von Anwendungen vermeidet Shi einen allgemeinen Projektplan zugunsten eines, wie er es nennt, “spezifischen Makro-Ablaufplans”. Dieser setzt sich aus Schritten zusammen, die auf Prüfungen wie Alpha- und Betatests und den damit verbundenen Validierungsmeilensteinen aufbauen. Zudem wird für jede Phase der Einführung der Erfolg in geschäftlicher Hinsicht definiert, beispielsweise in Bezug auf den Umsatz oder die Benutzerakzeptanzrate, und es werden Lehren aus dem Supportprozess gezogen, um die laufenden Supportkosten zu senken. Außerdem erinnert Shi alle Beteiligten daran, “dass das Projekt erst dann abgeschlossen ist, wenn wir wissen, dass die Architektur einen messbaren Kundennutzen erbracht hat”.

Nimmt man sich in einem Minimum-Viable-EA-Projekt zu viel vor, wird es überholt sein, bevor es fertig ist, und zu spät Ergebnisse liefern, um die Geschäftsleitung zufriedenzustellen und künftig Finanzmittel zu erhalten. Wird jedoch auf zu viel verzichtet, stellt das Tool nicht die umfassende Sicht auf die Technologie und das Unternehmen dar, die notwendig ist, um das Beste aus den IT-Investitionen zu machen. Das richtige Gleichgewicht entsteht häufig dann, wenn man sich auf eine Anwendung oder einen Problembereich im Unternehmen konzentriert – oder auf ein Feld, in dem sich die Anforderungen aufgrund neuer geschäftlicher oder gesetzlicher Anforderungen schnell ändern.

Nolan Hart, Associate Principal Analyst von Gartner, bezeichnet den richtigen EA-Umfang als “die geringste Anzahl von Ergebnissen wie Sichtweisen, Referenzmodelle und Entwurfsmuster, die dazu beitragen, eine rechtzeitige und konforme Bereitstellung von Produkten und Lösungen zu gewährleisten”. Anstatt zu viel Zeit damit zu verbringen, die aktuelle Architektur zu verstehen, empfiehlt er, “zuerst die gewünschten Ergebnisse zu verstehen”. Es bringe nichts, “wenn man sich in der Dokumentation der aktuellen dysfunktionalen Architektur für immer und ewig verliert”.

CIO Shi empfiehlt, dass eine Mindestarchitektur “alles berücksichtigt von der Benutzeroberfläche bis zu den APIs, die die Systeme mit der Datenarchitektur verbinden, und nicht nur eine isolierte Komponente oder einen einzelnen Dienst”. Die geplante Architektur müsse auch im Produktionsmaßstab getestet werden können und die gleichen Anforderungen in der Spitze erfüllen wie das System, das sie ersetzen soll.

Ein angemessener Scope gilt auch für die EA-Organisation selbst. Anstelle einer eigenen EA-Gruppe hat Carrier Global Corp. Kompetenzzentren für wichtige Anforderungen wie CRM, Außendienst, ERP, Analytik und digitale Produktionsfunktionen eingerichtet. Diese Zentren bieten eine einfache Basis von Kernkomponenten, die es dem Unternehmen ermöglichen, Innovationen schnell umzusetzen, ohne dass eine EA-Gruppe separate Plattformen für jede Geschäftseinheit bewerten muss, sagt Schulz.

Wenn eine Gruppe innerhalb eines Fachbereichs nicht an einem Minimum-Viable-EA-Projekt interessiert ist, “gibt es viele andere Leute, die Ihre Zeit in Anspruch nehmen werden”, sagt Hart. Er empfiehlt, die Nachfrage mit den Fähigkeiten einer EA-Gruppe abzugleichen, um “drei bis fünf Arten von Services zu bestimmen, die Sie anbieten können, um geschäftliche Resultate mit einem Minimum-Viable-Ansatz zu liefern”.

Designprinzipien und die Konzentration auf geschäftliche Anforderungen können dazu beitragen, “philosophische Diskussionen darüber, welche Lösung die beste ist, zu verkürzen”, sagt Tsounis. Zu den Prinzipien, die er empfiehlt, gehören: “Versuchen Sie immer, eine möglichst einfache Lösung zu schaffen, übertreiben Sie es nicht mit dem Engineering, ermöglichen Sie eine maximale Wiederverwendung im gesamten Unternehmen und nutzen Sie etablierte architektonische Entwurfsmuster sowie Cloud-basierende Dienste, bevor Sie etwas Neues aufbauen.”

Referenzarchitekturen und Standards in Bereichen wie Cybersicherheit, Data Governance, Produktionsmanagement und Best Practices für die Bereitstellung bieten einen “fertigen Katalog” für die effiziente Entwicklung kompatibler Anwendungen, die von vornherein robust, konform und widerstandsfähig sind, so Thind. Solche Architekturen, die aus Microservices aufgebaut und “in Bezug auf ihre APIs, ihre Skalierbarkeit und ihre Interoperabilität sehr gut definiert sind”, ermöglichen es einem Unternehmen, jeden Microservice zu ersetzen, ohne dass sich dies auf andere auswirkt. So ließe sich immer ein zukunftssicheres Design schaffen.

Hohpe ergänzt den Punkt, dass einige Standards die Innovation hemmen, während andere sie fördern. So sind beispielsweise einheitliche Schnittstellen unerlässlich, um leicht anpassbare Architekturen zu schaffen. Allzu strenge Standards können jedoch zu einer schlechten Technologieauswahl führen. Er erinnert sich an ein Anwendungsteam, das XML als Komponentenschnittstelle gegenüber schnelleren Kommunikationsprotokollen bevorzugte. Auf die Frage nach dem Grund antwortete das Applikationsteam, dass dies vom Architekturteam verlangt werde – offenbar ohne die nachteiligen Auswirkungen des XML-Parsing auf die Anwendungsleistung zu berücksichtigen.

Wenn es keine derartige Rolle gibt, so Thind, sollte man einen “Chefarchitekten” ernennen, eine Führungskraft, die übergreifende Standards, Governance, Plattformen und die Disziplin des Anwendungsdesigns von der Spitze aus beurteilt. “Allein die Besetzung dieser Position signalisiert dem gesamten Unternehmen die Bedeutung der Architektur und sorgt für die richtigen Verhaltensweisen, die wir brauchen, um effiziente und innovative IT-Organisationen zu schaffen.”

Der Start zu einer Minimum Viable Enterprise Architecture könne mit einer einfachen “Bestandsaufnahme” beginnen, sagt Thind, bei der übermäßige Ausgaben identifiziert werden. “Warum haben wir sechs verschiedene Anwendungen für denselben Prozess, fünf verschiedene Verträge für dasselbe BI-Tool, mehrere Marktdatenverträge mit demselben Scope oder Hadoop-Cluster rund um die Uhr für die monatliche Berichterstattung?” Selbst ein solcher minimaler Aufwand kann große Vorteile bringen. “Allein die Tatsache, dass das richtige Tool für die richtige Aufgabe verwendet wird und dass es eine StandardisierungStandardisierung sowie bewährte Verfahren für die Nutzung gibt, kann sich erheblich auf das Endergebnis auswirken und zu weniger technischen Schulden, geringeren Supportanforderungen und schnelleren Innovationen führen”, sagt er. Alles zu Standardisierung auf CIO.de

Dieser Artikel basiert auf einem Beitrag unserer Schwesterpublikation cio.com