Leitfaden für die Unternehmensarchitektur Gute Reise! Michael Müller, Michael Steiner Verschüttet unter der Projektruine findet man viele Artefakte der Unternehmensarchitektur (UA, siehe Kasten Enterprise Architecture ), meist großformatig ausgedruckte Visio-Diagramme mit vielen Elementen und noch mehr Verbindungslinien. Ihnen gemeinsam ist, dass sie kaum je auf dem aktuellen Stand waren sie laufend nachzuführen, war aufwendig und als das Projekt unter Druck kam, konnte man sich das sowieso nicht mehr leisten. Als Wandbehang machten sie sich zwar ganz gut, konnten aber kaum je im täglichen Projektleben ihren Nutzen unter Beweis stellen. Zum Teil ist das sicherlich darauf zurückzuführen, dass die Projekt- und Unternehmensleitung den UA-Arbeiten eher ablehnend gegenüberstand und kaum verstand, wie man sie in den Entwicklungsprozess einbinden und so ihr Potenzial hätte nutzen können. Hohe UA-Unkosten mit geringem Nutzen. UA-Artefakte unter der Projektruine Ein Unternehmen strukturiert um und die Software muss angepasst werden. Das Projektteam will genau planen und in kleinen Schritten vorgehen, der Aufsichtsrat will schnelle Resultate. Wer hier nicht aufpasst, sitzt schnell zwischen den Stühlen. Ein Acht-Punkte-Leitfaden für die Unternehmensarchitektur kann helfen. Wieder einmal wurde ein Informatik-Großprojekt gegen die Wand gefahren: Anstatt die IT-Landschaft und insbesondere die Kernsysteme zu modernisieren, Host-Systeme zu ersetzen und die Grundlagen für ein modernes digitales Business zu schaffen, steht das Projektteam vor einem teuren Trümmerhaufen. Die Kosten liefen aus dem Ruder, da die abzulösende Systemlandschaft so komplex ist, dass die Arbeit nur schleppend vorankam und man auf neue Anforderungen kaum oder nur mit großer Verzögerung eingehen konnte. Von der Fachabteilung geforderte moderne Applikationen und ansprechende Funktionen konnte das Team nicht in der gewünschten Zeit liefern, sodass die Unterstützung für das Projekt rasant dahinschmolz und es gestoppt werden musste. Dass ähnliche Szenarios immer noch weit verbreitet sind, zeigt eine großangelegte McKinsey-Studie von 2012 [1]. Sie kam zu dem Schluss, dass 45ˇ% aller IT- Großprojekte das Budget überschreiten, 7ˇ% nicht zeitgerecht beendet werden und 56ˇ% weniger Wert generieren als zuvor versprochen. Dabei kann man der Unternehmensarchitektur weder Weltfremdheit noch Praxisferne nachsagen. Architektur, ganz allgemein, soll ja per Definition Strukturen vorgeben, in deren Rahmen sich Details situationsgerecht ausgestalten lassen. In diesem Sinne ist es Ziel der UA, vorhandene komplexe Systeme zu entflechten und anhand einer klar definierten Zielarchitektur zu gliedern. Die UA-Disziplin kümmert sich nicht um die Architektur einzelner Anwendungen, sondern darum, wie die einzelnen Applikationen einer Unternehmung optimal zusammenarbeiten, um so die Geschäftsprozesse möglichst effizient zu implementieren. Viele erfolgreiche Großprojekte mit starker UA-Disziplin zeigen, dass die schrittweise Weiterentwicklung einer komplexen IT-Gesamtlandschaft machbar ist und die Ablösung einer veralteten IT- Landschaft so in kleineren, planbaren Schritten und mit weniger Risiko erfolgen kann. Richtig gelebt ist die UA-Disziplin ein unverzichtbarer Schlüsselfaktor für jedes Großprojekt. Die Schwierigkeit besteht darin, Wege zu finden, die UA-Disziplin richtig zu gestalten und dadurch ihre Wirksamkeit zu erhöhen. Um es vorwegzunehmen, Wirksamkeit und Akzeptanz der UA-Disziplin lassen sich nur verbessern, wenn man nicht primär Architektur-Artefakte generiert, sondern verständliche und konkrete Lösungen für anwendungsübergreifende 96 ix 2/2015
Problemstellungen liefert. Will beispielsweise eine Bank die Zahlungsabwicklung outsourcen, müssen Unternehmensarchitekten innerhalb kurzer Zeit mögliche Konsequenzen für die bestehenden Anwendungen und machbare Umsetzungswege aufzeigen können. Unternehmensarchitektur im Großen und Kleinen -TRACT Zwei Extrembeispiele Großfirmen mit eigenen UA-Abteilungen und Start-ups sollen verdeutlichen, wie Firmen heute Unternehmensarchitektur betreiben. Die UA-Disziplin in Großunternehmen ist meist zentral organisiert. Zum Beispiel steuern und unterhalten nur wenige Verantwortliche die UA-Modell-Verzeichnisse (falls vorhanden) zentral. Man versucht damit zu verhindern, dass ein Chaos entsteht, wenn 100 Projektmitarbeiter gleichzeitig Updates vornehmen. Häufig sind hier immer noch star re Wasserfallmodelle anzutreffen. Einige Auserwählte erarbeiten im stillen Kämmerlein ein Architekturdokument und schicken es dann in wochenlange Review- Runden. Nach diesen Reviews sind zwar alle Unterschriften unter dem Dokument und es gilt als Version 1.0, jedoch ist der Inhalt größtenteils bereits wieder veraltet. In Großunternehmen sind dedizierte Architekturteams vorhanden. Diese kennen ihre Disziplin, sind TOGAF-geschult (The Open Group Architecture Framework) und halten sich an gemeinsame Architekturvorgaben in der Ausarbeitung der UA-Beschreibungen. Die Disziplintreue und das Architekturverständnis sind Vorteile gut strukturierter, aber teilweise unflexibler Großfirmenprozesse. Es gibt wohl nur wenige KMUs, die neben dem Code-Repository eine sau - bere Beschreibung der Geschäftsfunk - tionen, der Prozesse, der Daten-, Ap - plikations- und Technologiearchitektur unterhalten. Im Start-up-Umfeld ist es üblich, mit wenigen Ressourcen viel zu erreichen. Gerade deshalb ist es spannend, dieses Umfeld als zweites Extrembeispiel heranzuziehen. Mitarbeiter solcher Unternehmen können es sich nicht leisten, Dinge zu produzieren, die nicht unmittelbar dem Unternehmenserfolg dienen. Dies ist mit ein Grund, warum sich in den letzten Jahren die Lean-Start-up-Philosophie vielerorts durchgesetzt hat. Im Vordergrund stehen hier Ausprobieren und Iterieren. Man entwickelt ein Produkt mit dem Ziel, schnell auf den Markt zu gehen und dadurch so früh wie möglich Feedback von den Kunden zu erhalten, viele Daten zu sammeln und so das Produkt Schritt für Schritt zu verbessern. Die UA-Disziplin spielt ebenfalls eine wichtige Rolle in Start-ups, hat aber oft eine andere Ausprägung als in Großunternehmen. Typischerweise ist sie ˇgenauso agil wie der Rest der Firma, ˇhäufig wenig strukturiert, ˇein Gemeinschaftswerk oft vieler Generalisten sowie ˇimplizit, das heißt, es gibt keine expliziten Vorgaben und keine dedizierte UA- Mannschaft. Tag für Tag scheitern große Softwareprojekte aufgrund massiver Planungsmängel. Eine starke, aber schlanke Unternehmensarchitektur-Disziplin ist einer der Schlüsselfaktoren für den erfolgreichen Abschluss eines großen strategischen IT-Projekts. Hilfreich dabei ist die Einhaltung eines an der Praxis orientierten Leitfadens mit klaren Prinzipien wie Agilität und Nachvollziehbarkeit. Enterprise Architecture Die Unternehmensarchitektur Zusammen mit einer Roadmap dient eine sauber spezifizierte Zielarchitektur als Basis ˇist eine Gesamtsicht auf das Unternehmen, für alle Umsetzungsprojekte. Die Zielarchitektur gibt den Rahmen vor, in dem sich die ˇlegt die wesentlichen fachlichen und IT- Strukturen fest und Projekte bewegen. Prinzipiell kann man die Form einer UA-Beschreibung frei wählen. Ob ˇdefiniert eine gemeinsame Sprachbasis für Text, Grafik, Modelle oder Kombinationen davon, spielt aus Projektsicht grundsätzlich kei- die Verknüpfung von Business und IT. Hauptziel der UA ist die Zusammenführung ne Rolle, solange Wirksamkeit und Nutzen verstreuter Funktionen, Informationen und deren Abhängigkeiten gegeben sind. zu einem Ganzen, das sich so steuern lässt, dass die Geschäftsziele optimal Strategie erreicht werden können. Geschäftsarchitektur Unter einer UA-Beschreibung versteht Informationssystemarchitektur man die Definition Technologiearchitektur einer bestehenden oder Ziel-Businessund Betriebsinfrastrukturarchitektur IT-Landschaft. Kombiniert man die vorteilhaften Aspekte beider Welten, kann man die Strukturierung von Großfirmen und die Schnelligkeit/Agilität von Start-ups vereinen und daraus einen einfachen Entwicklungsleitfaden für die Unternehmensarchitektur ableiten. Das Einhalten weniger Prinzipien kann die Wirksamkeit der UA-Disziplin erhöhen. Das Beste aus beiden Welten finden Dieser Leitfaden besteht aus den folgenden acht Punkten, die bei jeder UA-Entwicklung berücksichtigt werden sollten: 1. Starke Praxisorientierung: Das UA- Team muss Lösungen für konkrete Problemstellungen liefern, statt einen theoretischen Rundumschlag zu starten. Entwickelt es gute, pragmatische und umsetzbare Lösungen für strategische Fragestellungen, steigen der Wert der UA-Disziplin und die Akzeptanz im Management schnell an. 2. Nachvollziehbarkeit: Die Modellierung erfolgt auf einem Level, das nicht nur Softwareingenieure begreifen, sondern das für alle insbesondere auch für gestandene Manager verständlich ist. 3. Agile Entwicklung: Anstatt den einen großen Wurf mit geringen Erfolgsaussichten zu versuchen, nähert sich das Team über kurze, iterative Sprints der endgültigen Lösung an. Wie die Software selbst gilt es, die Zielarchitektur schrittweise zu definieren. Langwierige theoretische ix 2/2015 97 Sicherheitsarchitektur
externe Kanäle Te l e f o n Kundenservices Produktsuche Bezahlen Buchungsmanagement Buchungsdaten Inventarmanagement unterstützende Funktionen E-Mail Reiseplan zusammenstellen Feedback Kundendaten externes Inventar interne Kanäle Reiseberater Frontend Kommunikation / Support Buchungsprozess (inkl. Zahlung) Die erste Frage, die sich für die Zielarchitektur stellt: Welche UA-Artefakte muss das Projektteam erstellen? In diesem Fall bedient es sich eines stark reduzierten, an einer typischen UA-Pyramide ausgerichteten UA-Artefakte-Modells (Prinzipˇ7: einfache Frameworks). Der Fokus der UA-Entwicklung für MeineReise GmbH liegt auf folgenden Artefakten (Prinzipˇ4: nur benötigte Elemente): ˇGeschäftsarchitektur (Prozess- und funktionale Architektur) Ist und Soll; ˇInformationssystemarchitektur (Applikations- und Datenarchitektur) Ist und Soll. Die Architekturen für die eingesetzten Technologien und die Infrastruktur für den produktiven Betrieb lässt das Projektteam zu diesem Zeitpunkt noch bewusst offen, da es sie zusammen mit dem externen Implementierungspartner erarbeiten will. Auf die Vorgaben, die seitens der MeineReise GmbH hinsichtlich der eingesetzten Technologien bestehen, geht der Artikel jedoch unten kurz ein. Als Erstes nimmt das Team die Beschreibung der Geschäftsarchitektur in Angriff. Der Hauptzweck dieser UA-Be- Benutzeradministration Buchen Marketing Broschüre Dokumentenmanagement Generierung Reisedokumente Buchhaltung Einkauf Archivierung Personalwesen In der bisherigen Geschäftsarchitektur nehmen die Kundenservices großen Raum ein (Abb.ˇ2). Übungen entfallen. Jeder akzeptiert, dass kaum je eine vollständige Version entsteht, sondern dass die Erarbeitung kontinuierlich weitergeht. 4. Beschränkung auf benötigte Elemente: Architekten wählen lediglich solche Elemente des Frameworks, die sie wirklich für die Beantwortung ihrer aktuellen Fragestellungen brauchen. Nur so bleibt die Geschäftsarchitektur im Rahmen des Projekts pflegbar. 5. Teamarbeit pflegen: Jeder Mitarbeiter soll auf die Artefakte Zugriff haben, sie verwenden und bei Bedarf weiterentwickeln können analog zur verteilten Softwareentwicklung mit zentralem Repository und Review-Prozessen zur Sicherstellung der Qualität und Nachvollziehbarkeit. UA ist eine Teamarbeit und steht nicht in der alleinigen Verantwortung dedizierter Architekten. 6. Auffindbarkeit: Die Artefakte müssen für jeden Mitarbeiter auffindbar sein. Mittlerweile gibt es neben verbreiteter Standardsoftware spezialisierte Suchwerkzeuge wie smartfacts (siehe Alle Links am Ende des Artikels), mit denen man über verschiedene Repositories hinweg sehr einfach nach UA-Artefakten suchen kann. 7. Klar definierte, einfache Frameworks: Die meisten Projektmitarbeiter haben keine Ausbildung in Architekturentwicklung und der Verwendung der neuesten UA-Tools oder Ansätze wie Archimate, einer von der Open Group spezifizierten Modellierungssprache für Softwarearchitekturen. Dennoch gibt es Situationen während des Projekts, in denen kurzfristig eine Architekturplanung her muss, die dem Fachausschuss gezeigt wird. Genau in solchen Fällen entstehen oft wichtige UA-Artefakte. Solch weniger strukturierte und weniger formale Artefakte sind nicht minder relevant und müssen ebenfalls unterhalten werden, selbst nach Ende des Projekts. Die Erstellung einer UA-Beschreibung kann aufwendig und komplex sein, ein Frame - work wie TOGAF hilft, den Überblick zu wahren und die notwendigen Elemente zu priorisieren. Die Erfahrung zeigt aber, dass man in der Projektarbeit nicht in jedem Fall stur am gewählten Framework festhalten sollte und mit wenigen Artefakten und pragmatischen Ansätzen die Erfolgsaussichten gegenüber umfassenden und schwergewichtigen Standards deutlich erhöht. 8. Die Pflege delegieren: Es sollte Aufgabe der Projektteams und der Verantwortlichen der jeweiligen Anwendungsdomänen sein, die Architektur-Artefakte zu pflegen. Diejenigen, die am meisten unter einer schlechten Qualität der Architektur- Artefakte leiden, haben den größten Anreiz, sie auf den neusten Stand zu bringen. Zentrale Architekturorganisationen meiden diesen Schritt oft, könnten so aber von einer quasi kostenlosen Vervielfachung der UA-Kapazität profitieren. Im Folgenden soll ein Beispiel verdeutlichen, wie sich diese Prinzipien in der Praxis anwenden lassen. In der fiktiven Firma MeineReise GmbH, die ihren Kunden individuelle Reisen in exotische Länder anbietet, gibt es keine dedizierten Unternehmensarchitekten. UA-Artefakte erarbeiten die Mitarbeiter hauptsächlich im Rahmen von Projekten. Bei Bedarf aktualisieren Projektmitarbeiter oder die Anwendungsverantwortlichen diese Ar - tefakte (Prinzipienˇ5 und 7: Teamarbeit, einfache Frameworks). Jetzt hat der Aufsichtsrat die Geschäftsleitung des Reisebüros beauftragt, eine Lösung für die aktuell größte strategische Herausforderung auszuarbeiten: Vom klassischen zum digitalen Reise - büro lautet die grundlegend neue strategische Ausrichtung dieses KMUs. Zunächst ein Blick auf die Hauptpunkte dieser konkreten Problemstellung (Prinzipˇ1: Praxisorientierung). Bisher hat der Reiseberater einen Kunden im persönlichen Gespräch bedient. Jetzt will man den Beratungsprozess primär über den Onlinekanal anbieten. Zukünftig will die Firma keine Filialen mehr für eine Beratung vor Ort unterhalten, Kunden können jedoch in geringerem Umfang individuelle Auskünfte über Onlinekanäle (etwa Chat oder E-Mail) und per Telefon erhalten. Implementieren mit Leitfaden 98 ix 2/2015
schreibung liegt in der übersichtlichen Darstellung aller benötigten Funktionen und Objekte für die Geschäftslogik. Diese Funktionen werden im Rahmen der UA-Arbeiten in Geschäftsdomänen gruppiert. Funktionen lassen sich bei Bedarf später in Unterfunktionen und in Form von Anforderungen feiner strukturieren. In der ersten Phase ist primär die Gesamtübersicht gefordert (Prinzipienˇ2 und 4: nachvollziehbar, nur benötigte Elemente). Das Diagramm in Abbildungˇ2 zeigt die Ausgangslage der MeineReise GmbH in Form der bisherigen Geschäftsarchitektur (Ist-Zustand) an. Betrachtet man die aufgeführten Funktionen, fällt auf, dass die Geschäftsarchitektur eine gesamtheitliche Unternehmenssicht repräsentiert. Einige der Funktionen sind zudem wenig oder gar nicht automatisiert und beschreiben manuelle Tätigkeiten, beispielsweise die Funktion externes Inventar, die nur teilautomatisiert ist. Zum Ausgangszeitpunkt arbeitet ein Mitarbeiter der MeineReise GmbH direkt mit diversen Onlinesystemen der Lieferanten, um deren angebotene Reisekomponente (etwa ein Hotel) per Copy-andpaste in einen Reisevorschlag aufzunehmen und Buchungen durchzuführen. Eine vollautomatische existiert bisher nicht. Geschäftsarchitektur als ganzheitliche Sicht Als zweites wichtiges Element der Geschäftsarchitektur werden Geschäftsobjekte aufgelistet und den Domänen zugeordnet. Der Kompaktheit halber stellt dieser Artikel die vom Projektteam identifizierten Geschäftsobjekte hier lediglich als Liste dar, auf die er in der Informationssystemarchitektur nochmals zurückkommt: ˇKundendaten, ˇReisekomponente, ˇReiseplanvorlage, ˇReiseplan, ˇBuchung, ˇBroschüre. Die textuelle Beschreibung der Geschäftsfunktionen und -objekte entfällt hier. Sie gehört zu den priorisierten UA-Elementen, und Mitarbeiter der MeineReise GmbH haben sie im Rahmen der UA-Entwicklung bereits formuliert. Nachdem das Projektteam die Ist-Geschäftsarchitektur erarbeitet hat, folgt die Beschreibung der Soll-Version. Weil die MeineReise GmbH ihr Angebot einer persönlichen Beratung vor Ort in einen Selfservice durch den Kunden ändert, muss sie mehrere Funktionen der Geschäftsarchitektur modifizieren beziehungsweise durch weitere ergänzen. Die Prozesse der Abwicklung, nachdem ein Kunde eine Reise geplant und gebucht hat, bleiben in einer ersten Phase der Strategieumsetzung allerdings erhalten, denn man geht davon aus, dass im Rahmen der aktuellen Strategieänderungen die Wertschöpfungskette keine Anpassungen verlangt. Abbildungˇ3 zeigt das Diagramm der Soll-Geschäftsarchitektur. Die Strukturierung entstammt der Ist-Geschäftsarchitektur. Bisherige Funktionen, die unverändert bleiben, sind heller eingefärbt. So lassen sich Ist- und Soll-Situation schnell vergleichen. Beispielsweise fällt auf, dass im Marketing viele Funk - tionen dazugekommen sind. Das überrascht nicht weiter, denn mit der UmsteliX 2/2015 99
lung auf den reinen Onlineverkauf er - geben sich viele neue Möglichkeiten zur Kundenakquise und Pflege der Kundenbeziehung. Ähnlich fundamentale Änderungen gibt es in der Domäne Kundenservices, die in der Soll-Version deshalb Kunden- Selfservices heißt. Während die Funktionen dieser Domäne bisher vorwiegend manuell erfolgten, sollen sie jetzt wesentlich stärker automatisiert werden. Die zugehörigen Funktionsbeschreibungen müssen somit ebenfalls stark angepasst beziehungsweise neu geschrieben werden. Im Gegensatz zu den Funk - tionen ändern sich die Geschäftsobjekte nur wenig. Das Team musste sie lediglich um Kampagnen ergänzen, denn die MeineReise GmbH möchte dieses Marketingmittel zukünftig nicht mehr vernachlässigen. Ist- und Soll-Zustand erfassen Aus diesen ersten Modifikationen resultieren die folgenden UA-Architekturelemente für die Geschäftsarchitektur: ˇBeschreibung und Gruppierung aller Geschäftsfunktionen in Geschäftsdomänen in einer Ist- und einer Soll-Version; ˇIst- und Soll-Version der Beschreibung und Gruppierung aller Geschäftsobjekte. Die Geschäftsarchitektur ist oft statischer und weniger häufig Änderungen unterworfen als die darunterliegenden Architekturen. Größere Änderungen sind aber nötig, wenn man neue Geschäftsfelder erschließen will, wie im vorliegenden Beispiel der MeineReise GmbH. Im nächsten Schritt der Unternehmensarchitektur-Tätigkeit entsteht die erste Version der Informationssystemarchitektur. Die Funktionen und Objekte der Geschäftsarchitektur werden dabei in Ap - plikationen gruppiert, die auf dieser Ebene als logische Zusammenfassung von Funktionen zu verstehen sind. Das Team passt diese Gruppierung in vielen Fällen im Laufe des Projekts iterativ an, vor allem, weil sich die initial gewählte Gruppierung aus technischer Sicht als ungeeignet erweist (Prinzipˇ3: agil). Beispielsweise kann eine eingesetzte Software (gemäß Technologiearchitektur) nicht den vollen Funktionsumfang bieten, sodass man das Funktionsspektrum auf mehrere Applikationen verteilen muss. In der vorliegenden Situation ändert sich die Informationssystemarchitektur fundamental. Aus diesem Grund hat die Geschäftsleitung entschieden, dass die MeineReise GmbH die bisherigen Informationssysteme außer Betrieb nimmt und lediglich Kundendaten und migriert. Trotz dieser großen Änderungen er - arbeitet das Projektteam auch für diese Architekturebene zunächst eine Ist- und anschließend eine Soll-Version. Dadurch lassen sich notwendige Änderungselemente, die die Basis für die Umsetzungs-Roadmap darstellen, leicht identifizieren. Lose Kopplung und Service-Orientierung Das Diagramm der Soll-Informations - systemarchitektur zu sehen in Abbildungˇ4 zeigt, welche Funktionen welchen Informationssystemen zugeordnet werden. Es fällt auf, dass in dieser ersten Iteration eine hohe Übereinstimmung mit der Gruppierung in Geschäftsdomänen besteht. Diese Übereinstimmung ist gewollt und begünstigt eine lose gekoppelte, moderne SOA (serviceorientierte Architektur). Die Beschreibung der Daten und Schnittstellen zwischen Applikationen ist Teil der Informationssystemarchitektur. Beide Spezifikationen sind im Beispieldiagramm angedeutet, müssen allerdings in einem weiteren Artefakt der Informationssystemarchitektur noch detaillierter beschrieben werden. Im Beispiel sind die relevanten Systemschnittstellen durch Pfeile dargestellt, und die Datenelemente sind als Informationsobjekte den Informationssystemen zugeordnet. Zu beachten ist, dass diese Informationsobjekte weitgehend den Objekten der Geschäftsarchitektur entsprechen und diese teil- externe Kanäle interne Kanäle Te l e f o n E-Mail Kunden Frontend Desktop Kunden Frontend Mobile Reiseberater Frontend Administration Frontend Kunden-Selfservices Marketing Sicherheitsmanagement Produktsuche Reiseplan zusammenstellen Kommunikation / Support Buchen Web Content Management Medien IAM Bezahlen Feedback Registrierung Data Analytics Benutzeradministration Kampagnenmanagement Anmeldung Buchungsmanagement Buchungsdaten Kundendaten Buchungsprozess (inkl. Zahlung) soziale Medien Auditing Inventarmanagement externes Inventar Dokumentenmanagement Generierung Reisedokumente unterstützende Funktionen Buchhaltung Einkauf Archivierung Personalwesen Domäne bestehende Funktion neue / geänderte Funktion Die Umstellung auf Kunden-Selfservices eröffnet viele neue Möglichkeiten im Bereich Marketing und verlangt dementsprechende Funktionen (Abb.ˇ3). 100 ix 2/2015
Kunde Reiseberater Administrator Web Frontend Mobile Frontend (App) Reiseberater und Admin Frontend Kundenservices Marketing Sicherheitsmanagement Produktsuche Reiseplan zusammenstellen Kommunikation / Support Buchen Medien Bezahlen Feedback Benutzeradministration Registrierung Data Analytics Anmeldung soziale Medien Auditing Buchungsmanagement Kampagnenmanagement Kundendaten Buchungsdaten Buchungsprozess (inkl. Zahlung) Kampagnen Kundendaten Reisepläne Buchungen Web Content Management Inventarmanagement Web Content externes Inventar Dokumentenmanagement IAM externe Generierung Reisedokumente Benutzer und Rollen Informationssystem Komponente Schnittstelle / Informationsfluss Informationsobjekt Aktor Archivsystem Archivierung Die angestrebte Informationssystemarchitektur entspricht weitgehend der Einteilung in Geschäftsdomänen (Abb.ˇ4). weise ergänzen oder verfeinern. Die Informationsobjekte implementieren die Geschäftsobjekte. Ganz unten: Technologie und Infrastruktur Auf der nächsten Ebene der Unternehmensarchitektur wird den Informationssystemen eine spezifische Technologie zugeordnet. Konkret können das verfügbare Softwareprodukte sein, aber auch lediglich Entwicklungsplattformen, auf denen die Entwickler neue Softwarekomponenten implementieren. Auf der Basis dieser Architektur erstellen sie dann die Softwarearchitektur, die allerdings nicht der Unternehmens-, son dern der Solution-Architektur zugeordnet wird. Als letzte UA-Ebene definiert die Betriebsinfrastrukturarchitektur die Grundlage für das Betreiben der verschiedenen Informationssysteme. Da das Projektteam keine fixen unternehmensspezifischen Vorgaben für diese beiden unteren technischen Ebenen der Unternehmensarchitektur hat, entschied es sich, diese zusammen mit einem Software-Implementierungspartner festzulegen und sich im Rahmen der Sicherheitsanforderungen an dessen Fähigkeiten anzupassen. Rückblickend hat das Projektteam der MeineReise GmbH die Zielarchitektur dieses KMUs in wenigen einfachen Schritten erstellt (Prinzipienˇ4 und 7: nur benötigte Elemente, einfache Frameworks). Die entstandenen Artefakte dienen zur übergreifende Strukturierung und zeigen in der Soll-Version einen denkbaren Ansatz für die strategische Problemstellung Vom klassischen zum digitalen Reisebüro auf. Die dokumentierte Soll-Geschäftsarchitektur zeigt die fachlichen Domänen, innerhalb derer man die Applikationen vorwiegend unabhängig voneinander weiterentwickeln kann. Die Verantwortlichkeiten sind somit klar geregelt. Nicht unerwähnt bleiben sollte, dass für die Erstellung der UA-Artefakte eine Diagramm-Software zum Einsatz kam, die allen Projektmitarbeitern zur Verfügung stand. Der Grund dafür lag in den Prinzipienˇ3 (agil), 5 (Teamarbeit), 6 (Artefakte auffindbar) und 8 (Pflege delegieren). Dieses Vorgehen erlaubt es, dass alle direkt auf die Artefakte (gespeichert in einem zentralen Datei-Repository) zugreifen, sie auschecken, bei Bedarf anpassen und wieder einchecken können. So hat das gesamte Team die Architekturbeschreibungen kontinuierlich verwendet, iteriert und getragen. Auch Kommentarfunktionen erwiesen sich als hilfreiches Mittel im Rahmen von Reviews. Eine Gegenüberstellung der Ist- und Soll-Beschreibungen hilft nun, die Entwicklung der Firma schrittweise und systematisch voranzutreiben und entsprechende Schritte zu priorisieren. Auf Ebene der Informationssystemarchitektur lässt sich aus diesem Vergleich direkt eine Roadmap für die Umsetzung ableiten, die eine grobe Planung für die Implementierung der neuen Informationssysteme und der Migration der bisherigen Systeme zeigt. Aus der Dokumentation der Informationssystemarchitektur hat das Projektteam von MeineReise GmbH die größten Änderungsblöcke extrahiert. Abbildungˇ5 zeigt hierfür die Roadmap, die eine initiale Grobplanung der anfallenden TätigiX 2/2015 101
Abschluss Entwicklung Release 1 Go-Live Release 1 ( MVP ) Go-Live Release 2 Realisierung Phase I Fokus: Kundenerlebnis Einschränkung ( MVP ): nur teilautomatisiertes Buchungs- / Inventar-Backend externer Drittsysteme Organisationsaufbau Kundensupportservice Datenmigration (für beliebige Kundendaten und ) Realisierung Phase II a Fokus: weiterer Ausbau der Kundenservices (Priorisierung anhand von User-Tests und Web-Analysen) Realisierung Phase II b Fokus: vollständige Automatisierung des Buchungs- und Inventarmanagements Marketingkonzept (für Kampagnen, soziale Medien) Aus der Dokumentation der Informationssystemarchitektur lässt sich eine initiale Roadmap für die Umsetzung der identifizierten Änderungen ableiten (Abb.ˇ5). keiten erlaubt und ebenfalls iterativ weiterentwickelt wird. Insbesondere während der Anfangszeit der Zusammenarbeit mit dem Implementierungspartner führen Iterationen der Unternehmensarchitektur auch zu Anpassungen der Grobplanung. Auch die Roadmap muss agil bleiben Auch beim Definieren einer solchen Road map für die Realisierung neuer Systeme ist ein agiles Vorgehen zu wählen (Prinzipˇ3). Das Team entscheidet sich zudem dem Gedanken des Lean Start-up folgend, eine erste Release möglichst früh in Betrieb zu nehmen, um heraus - zufinden, ob sich die gewählte strategische Richtung bewährt hat oder gegebenenfalls eine Anpassung verlangt. Diese erste Version entspricht somit einem sogenannten Minimum Viable Product (MVP), einer produktiv einsetzbaren Lösung mit minimal praktikablem (viable) Funktionsumfang. Konkret heißt das für die MeineReise GmbH, dass sich die Entwickler in einer ersten Phase (MVP) auf die Umsetzung der Kundenservices beschränken und aus dem Buchungs- und Inventarmanagement lediglich jene Funktionen umsetzen, die sich nicht für die manuelle Abarbeitung eignen. Trotz dieser Abstriche bei der Automatisierung will man diese erste Release produktiv einsetzen. Nur so ist eine Beurteilung des neuen Geschäftsmodells möglich und das Risiko der Strategieumsetzung lässt sich erheblich reduzieren. Auch wenn sie einen Lean-Ansatz verfolgen, dürfen Entwickler Qualitätsaspekte keinesfalls vernachlässigen. Schließlich legt die erste Iteration den Grundstein für weitere Release-Iterationen, die nur effizient sein können, wenn das Team von Anfang an moderne Softwareentwicklungspraktiken anwendet (zum Beispiel Code-Reviews, kontinuierliche Integra - tion, automatisiertes Testing, User Stories). Diese Umsetzungs-Roadmap schließt den ersten Durchgang der UA-Arbeiten der MeineReise GmbH ab und die Geschäftsleitung kann mit diesen Resultaten dem Aufsichtsrat einen Lösungsansatz für die wichtigste strategische Herausforderung präsentieren. Das Beispiel der MeineReise GmbH zeigt, wie man über wenige einfache Schritte vom strategischen Problem auf eine konkrete Lösung in Form einer Zielarchitektur und einer konkreten Roadmap für die Umsetzung kommen kann. Die Roadmap identifiziert klare Meilensteine, die einen Mehrwert für das Unternehmen generieren. Genauso muss UA funktionieren, damit unternehmerisch denkende Manager sie schätzen. Im Unterschied zu KMUs wie der MeineReise GmbH haben Großunternehmen viel umfangreichere und kompliziertere Anwendungslandschaften. Das für KMU vorgestellte Vorgehen für die Erstellung der Zielarchitektur unterscheidet sich aber nicht wesentlich von dem in einer großen Firma. Wesentliches Erfolgskriterium ist im Großunternehmen genauso wie in einem KMU, dass die Entwicklung der Zielarchitektur nicht von komplizierten Modellen und Tools zentraler UA-Teams behindert wird. Im optimalen Fall definiert das interdisziplinäre Projektteam die Zielarchitektur als Teil der Projektarbeit. Die zentralen UA-Organisationseinheiten machen einfache Vorgaben für Artefakte und zentrale Verzeichnisse und führen regelmäßige Reviews durch. So lassen sich unternehmensweite UA-Prinzipien und Best Practices einhalten und gleichzeitig verhindert man, dass typische Ressourcen-Engpässe der zentralen Architektur das Projekt bremsen. Fazit Oft spielt die UA-Disziplin in Großprojekten nur eine Nebenrolle. Viele erfolgreiche Praxisbeispiele belegen aber, dass sie ein Schlüsselerfolgsfaktor in großen technologielastigen Change-Projekten sein könnte und so das eingangs erwähnte Horrorszenario jedes Unternehmers verhindert, in dem ein großes Umsetzungsprojekt fehlgeschlagen ist. Leider fehlt es aber den UA-Architekten oftmals an Praxisorientierung, komplizierte Prozesse verlangsamen die Projekte und machen klare, schnelle Entscheidungen schwierig. Der in diesem Artikel eingeführte Leitfaden fasst einige einfache Prinzipien zusammen, die die Wirksamkeit der UA-Disziplin erhöhen und so die Fehlerrate von Großprojekten massiv senken können. (ka) Michael Müller ist Partner bei der Acrea AG. Eines seiner Kerngebiete ist die Anwendung von Unternehmensarchitektur-Tools in großen Online-Business-Projekten. Michael Steiner iist Senior Consultant bei der Acrea AG in Zürich. Seine Kerngebiete umfassen unter anderem modernes Online-Business und modellgetriebene Softwareentwicklung. Literatur [1]ˇMcKinsey&Company; Delivering large-scale IT projects on time, on budget, and on value; www.mckinsey.com/ insights/business_technology/ delivering_large-scale_it_projects_ on_time_on_budget_and_on_value Alle Links: www.ix.de/ix1502096 102 ix 2/2015