IT-Unternehmensarchitektur E-Book

Wolfgang Keller

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2024

Seitenzahl: 732

Beschreibung

Das Standardwerk zur IT-Unternehmensarchitektur - Handbuch für den Aufbau eines systematischen IT-Alignments - mit Fokus auf praktischer Anwendbarkeit und vielen Beispielen aus der Praxis - aktuell zu TOGAF 10 und prominenten Themen wie Digitalisierung und Cybersicherheitsarchitekturen  Gegenstand von IT-Unternehmensarchitektur ist es, ein Portfolio aus Software und IT-Infrastruktur so auszurichten, dass ein optimaler Nutzen für das anwendende Unternehmen entsteht. Dieses Buch gibt eine systematische Einführung in die Grundlagen, die Anwendung und die Vorbereitung für den Einsatz von IT-Unternehmensarchitektur in der Praxis. Es beschreibt im Detail, wie IT-Verantwortliche dabei unterstützt werden können, das Softwareportfolio eines Unternehmens im Hinblick auf die Zielerreichung zu optimieren. Das Spektrum der Aufgaben reicht dabei von der Erarbeitung der IT-Strategie über den Bebauungsplan bis hin zur Tagesarbeit der IT-Governance und Architektur-Governance. Schwerpunkte des Buches sind: - Anpassung der Prozesse der IT-Unternehmensarchitektur an die Bedürfnisse des Unternehmens durch einen musterbasierten Ansatz. - Bezug zu gängigen Frameworks wie TOGAF, COBIT oder ITIL. - Berücksichtigung von immer wichtiger werdenden Aspekten wie Compliance und IT-Sicherheit, die einen wachsenden Anteil an der Arbeit des IT-Managements einnehmen.  Die 4. Auflage wurde vollständig überarbeitet und aktualisiert. Neue Entwicklungen im Bereich der businessorientierten Unternehmensarchitektur, z. B. das Open-Source-Tool EDGY und Muster für digitale Strategien, wurden ebenso berücksichtigt wie technologische Trends im IT-Risikomanagement und in der IT-Sicherheit.

Leseprobe

Wolfgang Keller ist freier Berater mit den Schwerpunkten Management großer Softwareprojekte und IT-Unternehmensarchitekturen. Seine Themen in diesem Umfeld sind u. a. Business-IT-Alignment, Architekturprozesse, Coaching von Architekturgruppen und IT-Bebauungsplanung für komplette IT-Landschaften. Vor seiner Selbstständigkeit war er über acht Jahre in verschiedenen Managementpositionen im Generali-Konzern in Österreich und Deutschland beschäftigt, leitete dort große Projekte und war u. a. verantwortlich für eine internationale Softwareplattform. Er hat über 30 Jahre Erfahrung mit dem Bau großer individueller Anwendungssysteme als Softwareingenieur, Berater, Projektleiter und Chefarchitekt.

Er studierte nach einer »Siemens Stammhauslehre« Informatik/BWL an der Technischen Universität München und war vor seiner Tätigkeit bei der Generali als Seniorberater und Projektmanager bei der software design & management AG (sd&m, heute Capgemini) in Hamburg und München beschäftigt. Des Weiteren hat er über lange Zeit die VAA1-Initiative des GDV beraten.

Er ist Autor des Buches »Enterprise Application Integration – Erfahrungen aus der Praxis« (dpunkt.verlag) sowie Koautor von »Digitale Transformation mit System« (Leanpub) und »TOGAF 10th Edition Quickstart Guide for IT Enterprise Architects« (Leanpub).

Unter Mitarbeit von:

Florian Oelmaier ist Geschäftsführer und CTO der IS4IT GmbH. Er war als IT-Sicherheitsspezialist bei der HypoVereinsbank tätig, konzipierte bei der msg systems ag Sicherheitsarchitekturen für IT-Projekte und war als Krisenprojektleiter für notleidende Softwareprojekte verantwortlich. In der Geschäftsleitung der Corporate Trust kam die Aufklärung von Cybercrime- und Industriespionagefällen hinzu.

Er ist Mitglied im Expertenrat Cybersicherheit des BSI, Buchautor (»Krisenfall Ransomware«) und Mitgründer der MCTTP, einer internationalen Cyber-Sicherheitskonferenz.

Copyright und Urheberrechte:

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Wolfgang Keller

IT-Unternehmensarchitektur

Von der Geschäftsstrategie zur optimalen IT-Unterstützung

4., überarbeitete und aktualisierte Auflage

Unter Mitarbeit von Florian Oelmaier

Wolfgang Keller

Website: www.objectarchitects.biz

E-Mail: [email protected]

Unter Mitarbeit von:

Florian Oelmaier

Website: https://x.com/h0tz3npl0tz

E-Mail: [email protected]

Lektorat: Christa Preisendanz

Lektoratsassistenz: Julia Griebel

Copy-Editing: Ursula Zimpfer, Herrenberg

Layout & Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner, Frank Heidt

Umschlaggestaltung: Eva Hepper, Silke Braun

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-86490-992-4

PDF

978-3-98890-173-6

ePub

978-3-98890-174-3

4., überarbeitete und aktualisierte Auflage

Copyright © 2024 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

Für Ilka und Arved

Vorwort zur 4. Auflage

Zum vierten Mal knappe 500 Seiten durchzuarbeiten, die man selbst über drei Auflagen und 18 Jahre geschrieben hatte, erfordert ein wenig Überwindung. Sieben Jahre nach der letzten Überarbeitung im Jahr 2016 hatte ich allerdings genug Abstand, um es wieder anzugehen. Motivation waren dabei nicht zuletzt auch die Menschen, denen ich begegnet bin und die mir (hoffentlich nicht nur aus Höflichkeit) gesagt haben, dass das Buch ihnen bei ihrer Arbeit geholfen hat.

Die Frage, ob das Buch grundsätzlich noch »funktioniert«, war spannend. Lassen Sie uns das anhand der Themen beantworten:

Der musterbasierte Ansatz für das Management von IT-Unternehmensarchitekturen funktioniert nach wie vor. Man kann aus den Unternehmenszielen abgeleitete Zielmuster für die IT identifizieren (Kap. 3) und basierend darauf bedarfsgerecht Managementmuster anwenden (Kap. 4) und dann dazu eine passende Informationsbasis ableiten (Kap. 5).

Fragt sich: Warum nur IT-Unternehmensarchitektur (IT-EAM)? Auf dem Gebiet der businessorientierten Unternehmensarchitektur (EA, EAM) hat sich eine Menge bewegt. TOGAF 10th Edition hat wieder in diese Richtung expandiert und es sind auch neue Global Player auf dem Markt aufgetaucht, wie die Intersection Group (https://www.intersection.group) mit ihrer Sprache EDGY (https://enterprise.design) zur Gestaltung von Unternehmensarchitektur, -erfahrung und -identität. Ich habe mich trotzdem entschieden, mich weiterhin auf die IT-Seite zu konzentrieren. Die Übergänge sind fließend und Sie werden hier genug Bezüge zu Methoden finden, die dafür sorgen, dass die Unternehmensstrategie sich in der IT-Strategie manifestiert.

Das gilt auch für die Digitalisierung. Für digitale Strategien gibt es Muster [Woerner+22]. Wenn man diese umsetzen möchte, kann man das wieder mit den Zielmustern und Managementstrategien unterfüttern, die in diesem Buch vorgestellt werden. Es war also nicht das Ziel, ein Buch über alles im Unternehmen zu schreiben, sondern sich nach wie vor auf den Anteil des IT-Managements zu konzentrieren.

Den größten Aktualisierungsbedarf hatten die Themen, die sich darauf beziehen, was man als IT-Unternehmensarchitekt neben dem Architekturkern dringend »auch noch« beherrschen muss:

Compliance

ist ein so umfassendes Gebiet, dass dort sowieso nur Grundlagen vermittelt werden und wenig Spezialwissen, das veraltet. Von daher war hier mäßig viel zu tun.

IT-Sicherheit

ist hingegen ein Gebiet, das sich sehr schnell weiterentwickelt. Hier hat Florian Oelmaier sein Kapitel gründlich überarbeitet, sodass es inzwischen ca. 20 Prozent des kompletten Buches einnimmt. Wenn man sich allerdings CIO-Prioritäten ansieht, dann ist das absolut gerechtfertigt und nötig.

Für das

IT-Risikomanagement

gibt es sehr viele Änderungen in den Frameworks, die allesamt nach der letzten Überarbeitung des Buches vorgenommen wurden. Sei es COSO 2017 oder COBIT 2019. Beide Frameworks wurden überarbeitet und teilweise wurden Themen fusioniert.

Die

Makro-Architekturmuster

müssen für den Zweck dieses Buches nicht die »neuesten« sein. Hier geht es vor allem darum, das Prinzip zu zeigen. Von daher war es nicht notwendig, die neueste PaaS-Plattform von Google, Amazon oder Azure hier im Detail zu beschreiben. Dafür gibt es andere Werke.

TOGAF 10

th

Edition (neu in 2022), COBIT 2019 (Ende 2018) und auch ITIL 4 (2019) wurden alle nach dem Erscheinen der 3. Auflage dieses Buches gründlich überarbeitet. Daher waren starke Überarbeitungen der entsprechenden Kapitel in diesem Buch notwendig.

Trendthemen wie Lean, Agile und Cloud waren grundsätzlich schon durch die 3. Auflage abgedeckt.

Interessant werden wird der Einfluss durch »generative KI«: Noch sind die Modelle zu schwach, um Inhalte z. B. aus der Kombination von Repositories, Wikis, EAM-Tools und Freitext-Bibliotheken simultan zu bearbeiten, die aus strukturierten Daten, Text und Bildern bestehen oder es erfordern, dass »schöne« Bilder erzeugt werden. Nachdem wir hier erst am Anfang einer rasanten Entwicklung stehen, würde eine nächste Auflage sicher »voll mit KI-Themen« sein – wenn sie nicht sogar von einer generativen KI geschrieben würde. Das war hier leider noch nicht möglich. Der Ausblick (Kap. 16) gibt u.a. einen kurzen Überblick über die Herausforderungen, die zu lösen sind, bis KI einen IT-Unternehmensarchitekten wirklich bei seiner Arbeit unterstützen kann.

München – im April 2024

Wolfgang Keller

Vorwort zur 3. Auflage

Nach fast fünf Jahren war wieder eine Überarbeitung des Buches notwendig. Wenn man eine solche Überarbeitung angeht, stellt man sich die Frage, ob grundsätzlich neue Dinge passiert sind oder der Status von IT-Unternehmensarchitektur eher stabil geblieben ist.

Die Antwort ist etwas gespalten: IT-Unternehmensarchitektur, soweit sie sich auf den IT-Anteil bezieht, war schon 2012 relativ stabil und es hat dort auch keine revolutionär neuen Entwicklungen gegeben. Nachfolgend erhalten Sie einen Überblick, wo es Ergänzungen gab. Parallel dazu hat sich »Business Architecture« oder aber auch Enterprise Business Architecture weiterentwickelt und auch verbreitet.

Doch zunächst zu Unternehmensarchitektur:

Von dem am häufigsten verwendeten Framework, das immer wieder als EAM-Framework bezeichnet wird, TOGAF 9.0, hat es 2012 mit TOGAF 9.1 ein Wartungsrelease gegeben. Seitdem hält die »Gemeinde« der Unternehmensarchitekten Ausschau nach TOGAF 10.0, das wahrscheinlich 2017 erscheinen wird und von dem man sich weitere Komplettierungen in Richtung vollständigere Abdeckung von IT-Unternehmensarchitektur wird erwarten können.

Das zweite wichtige Framework – COBIT 5 – war zum Erscheinen der 2. Auflage dieses Buches als Preview verfügbar. Der Herausgeber ISACA hat das Framework in der Zwischenzeit weiter ergänzt, sodass Risikomanagement und Management des Wertbeitrags der IT aus den bisher gesonderten Frameworks Risk IT und Val IT integriert wurden.

Was die Methodik von IT-Unternehmensarchitektur (bzw. EAM) generell angeht, gab es in den letzten zehn Jahren keine revolutionären Neuerungen. Typisch für »reife Märkte« gab es aber Produktvariationen: Lean EAM und Agile EAM. Wenn man beide betrachtet (Kap. 13), kann man feststellen, dass sie gut verträglich mit dem grundsätzlich musterbasierten Ansatz dieses Buches sind. In einen ähnlichen Kontext fallen Fragen nach »EAM für den Mittelstand«. Das Thema wurde bisher nicht explizit in diesem Buch behandelt, wird aber jetzt aus Gründen, die in Kapitel 15 erklärt werden, zumindest kurz angerissen. Weiter kann man fragen, wie es mit EAM bei sogenannten »exponentiellen Unternehmen« (ExOs) [Ismail+14] bestellt ist. Solche Unternehmen gibt es in ihren ersten Formen seit ca. 2006. Ihre Anfänge gab es also bereits, als die erste Auflage dieses Buches erschien – sie werden allerdings erst heute breiter diskutiert. Bezüglich EAM sind sie zum großen Teil einfach abzuhandeln. Warum das so ist, wird ebenfalls in Kapitel 15 diskutiert werden.

Technologische Trends wirken sich auf die IT-Unternehmensarchitektur zwar aus – aber nicht dramatisch. Sofern es Bezüge zu Cloud Computing gibt, werden sie eingewoben. Neue Architekturmuster, wie z. B. »Microservice-Architektur«, werden die bisherigen Architekturmuster ergänzen (siehe Abschnitt 9.3.3).

Eine weitere Frage betrifft die Weiterentwicklung von EAM-Tools. Die Strategie, das Thema abzuhandeln, bestand in den bisherigen Auflagen darin, sich anzusehen, welche neuen Trends beim Marktführer implementiert sind. Dies wurde auch hier wieder getan. Den aktualisierten Stand zu EAM-Tools finden Sie in Kapitel 12.

Aktualisierungen waren bei fast allen Kapiteln nötig. Speziell zu erwähnen sind noch die Kapitel zu Compliance (Kap. 6) und IT-Sicherheit (Kap. 7): Im Kapitel zu Compliance wurden die Beispiele auf einen aktuellen Stand gebracht. Dies war nicht zwingend erforderlich. Man lässt sich als Autor aber ungerne vorwerfen, etwas zu Basel II zu schreiben, wenn es schon Basel III gibt. Auch wenn es für den Zweck des Buches unerheblich ist und es eigentlich nur darum geht, zu zeigen, wie sich Regulierungen ganz allgemein auf IT-Unternehmensarchitektur auswirken. Bei IT-Sicherheit hat sich schlicht die Bedrohungslage weiter verschärft. Entsprechend musste das Kapitel überarbeitet und in »Cybersicherheitsarchitektur« umbenannt werden.

Das Thema Enterprise Business Architecture und Business Architecture generell ist auf dem Vormarsch. Es gibt hier inzwischen eine wachsende Menge an Publikationen [Reynolds10], [Sensler+15], [Simon+15], [Ulrich+13], an denen auch der Autor dieses Buches teilweise beteiligt war [Simon+15]. Dieses Buch soll jedoch vorerst auf die IT-Seite der Unternehmensarchitektur fokussiert bleiben. Über Business-IT-Alignment, Capabilities (Geschäftsfähigkeiten) und IT-Strategien gibt es mehr als genug Anknüpfungspunkte und Schnittstellen.

München – im Dezember 2016

Wolfgang Keller

Vorwort zur 2. Auflage

Vom ersten Auftauchen eines Themas in der Informatik bis zu dem Zeitpunkt, an dem eine Technik allgemein beherrscht und gelehrt wird, vergehen üblicherweise 10–15 Jahre. Das bezieht sich auf das in diesem Buch behandelte Thema IT-Unternehmensarchitektur ebenso wie auf den Begriff Softwarearchitektur, der zu Beginn der 1990er-Jahre auftauchte. Anfang der 2000er-Jahre war das Thema Softwarearchitektur allgemein akzeptiert und reif. Als die erste Auflage dieses Buches geschrieben wurde, also 2005 bis 2006, gab es bereits ein brauchbares Softwarearchitektur-Curriculum und ausreichend Literatur dazu, sodass Softwarearchitektur sich zu einer Disziplin entwickelte, die in Praxis und Wissenschaft heute von großer Bedeutung ist.

Die erste Auflage dieses Buches gab den Wissensstand der »IT-Unternehmensarchitektur«, die sich etwa seit dem Jahr 2000 zu einer eigenständigen Disziplin entwickelt hatte, wieder. Es gab erste Ansätze wie das Zachman-Framework oder frühere Versionen von TOGAF (The OpenGroup Architecture Framework), die sich jedoch meistens auf die Entwicklung großer Einzellösungen bezogen. Später tauchten dann Begriffe wie »Planung der Anwendungslandschaft« oder der Vergleich von IT-Unternehmensarchitektur mit Stadtplanung auf, gefolgt von Begrifflichkeiten rund um das Management kompletter Anwendungsportfolios. Heute, im Jahr 2011, hat das Thema Unternehmensarchitektur also einen zur Softwarearchitektur Anfang der 2000er-Jahre vergleichbaren Stand. Die Methoden und Definitionen haben sich angeglichen, und ein gemeinsames Curriculum entwickelte sich. Von daher war es notwendig und sinnvoll, dieses Buch in Form einer zweiten Auflage gründlich zu überarbeiten. Ein neuer Ordnungsrahmen und der Aufbau des Buches spiegeln den Stand der IT-Unternehmensarchitektur heute wider. Viele Textpassagen und Abschnitte sind neu geschrieben oder erweitert worden.

IT-Unternehmensarchitektur ist im Gegensatz zur Softwarearchitektur noch kein großes Thema an Hochschulen. Dies mag damit zusammenhängen, dass in der Industrie deutlich weniger Unternehmensarchitekten benötigt werden als Softwarearchitekten. Während in einem Entwicklungsteam von ca. 10 Personen üblicherweise ein Softwarearchitekt zu finden ist, bezeichnen sich nur ca. 1 Prozent der Softwareexperten als Unternehmensarchitekten. Es ist also davon auszugehen, dass es derzeit mindestens zehnmal mehr Softwarearchitekten gibt als Unternehmensarchitekten.

Eine Neuauflage dieses Buches war auch aus anderen Gründen sinnvoll: In den letzten 5–6 Jahren haben sich in der IT großer Unternehmen einige Schwerpunkte verschoben. Reines Kostendenken, zumindest bezogen auf die IT, tritt immer mehr in den Hintergrund. Es wird davon ausgegangen, dass dieses Thema von IT-Managern bereits ausreichend ausgelotet und ausgereizt wurde. Insofern wird es in dieser Auflage auch nicht mehr dieselbe Breite einnehmen wie noch vor 5 Jahren. Stattdessen tritt die Notwendigkeit in den Vordergrund, als IT zusammen mit den Geschäftsbereichen Felder aufzuzeigen, in denen das Unternehmen seine Ertragsposition massiv verbessern kann. Angesichts der Tatsache, dass mehr als 90 Prozent aller Kosten den Geschäftsbereichen zuzuordnen sind – und eben nicht der IT –, liegt hier für das Unternehmen auch der wesentlich attraktivere Hebel.

Heute ist es für einen Projektleiter in einem großen Unternehmen deutlich mühsamer geworden, ein Projekt überhaupt bis zur Auslieferungsreife zu bringen. Ursachen dafür sind vor allem deutlich gestiegene Anforderungen aus den Querschnittsgebieten Compliance, Sicherheit und Risikomanagement. Die spektakulären Ereignisse rund um die letzten Finanzkrisen haben das akzeptierte Niveau an Risiko, das große Unternehmen eingehen dürfen, deutlich abgesenkt. Als Konsequenz wurden zusätzliche Stabsstellen installiert, die sich in allen Projekten um die Einhaltung der »IT-Governance« kümmern. Der Nachweisaufwand, den Projekte heute dafür führen müssen, ist erheblich gestiegen. Davon bleibt auch die IT-Unternehmensarchitektur nicht unberührt. Wenn Unternehmensarchitekten Projekte starten, geht ein guter Teil des Planungsaufwands in diese Themen. Außerdem müssen Aspekte der Compliance, der Sicherheit und des Risikomanagements auch in den zukünftigen Architekturen berücksichtigt werden. Auch dies ist mit aufwendigen Nachweispflichten verbunden.

Gleichzeitig wollen Unternehmen Produkte schneller entwickeln, um sich Vorteile in einem Zeitwettbewerb zu verschaffen. Hier beißt sich, vor allem in internationalen Großunternehmen, die Katze quasi in den Schwanz. Einerseits bedeuten Anforderungen an Compliance und Sicherheit einen erhöhten Aufwand für die Projekte. Andererseits sollen diese schneller abgewickelt werden als früher. Agile Methoden wie Scrum versprechen hier Lösungen. Wie agile Methoden zusammen mit großen Architekturen und Compliance- und Sicherheitsanforderungen skalieren, ist ein Thema, von dem Sie als Unternehmensarchitekt zumindest am Rande auch mit betroffen sind.

Des Weiteren breiten sich neben den agilen Methoden auch Konzepte der Lean Production in der Softwareentwicklung aus. Exemplarisch sei hier Kanban genannt. Beim Einsatz dieser Methoden darf jedoch das Thema Architektur nicht vergessen oder vernachlässigt werden, auch wenn sie keinen großen Einfluss darauf haben. Da sich die Themen IT-Unternehmensarchitektur und Agilität orthogonal verhalten, finden Sie in diesem Buch kein eigenes Kapitel zu »agiler Unternehmensarchitektur«. Oder anders ausgedrückt: Für das Portfolio von Anwendungen und Services ist es wenig relevant, ob diese agil oder nach der Wasserfallmethode erstellt wurden, solange dabei die Architekturrichtlinien eingehalten wurden.

Für Unternehmensarchitektur wird häufig eine Stabsstelle eingerichtet, wie auch für die Einheiten, die für Compliance, Sicherheit und Risikomanagement zuständig sind. In der Form einer solchen Stabsstelle ist Architekturmanagement heute in der Praxis weit verbreitet und hat zumindest bei sehr großen Unternehmen auch schon eine erhebliche Normung erfahren. Wenn man beispielsweise die Architektureinheiten mehrerer global agierender Finanzkonzerne vergleicht, wird man große Ähnlichkeiten feststellen. Die zu lösenden Probleme und die Methoden, damit umzugehen, konvergieren inzwischen stark.

In der Summe gab es also genügend Gründe, um die erste Auflage dieses Buches deutlich zu überarbeiten und eine zweite Auflage herauszubringen.

München – im Dezember 2011

Wolfgang Keller

Vorwort zur 1. Auflage

Unternehmensarchitekten leben gefährlich.

Chefarchitekt eines großen IT-Anwenderunternehmens zu sein, kann ein »gefährlicher Job« werden. Viele mittelgroße Anwenderunternehmen haben derzeit nicht einmal eine Gruppe für IT-Unternehmensarchitektur oder eine Unterstützungsgruppe für den IT-Vorstand1, die sich u.a. mit IT-Governance beschäftigt. Es gibt heute noch eine Mehrheit von Unternehmen mit deutlich mehr als 3 Mrd. Euro Umsatz, die das Portfolio ihrer IT-Anwendungen nicht »auf Knopfdruck« kennen und die ihre Anwendungsportfolios nicht systematisch managen.

Budgets für Infrastruktur sind knapp.

In Zeiten knapper Budgets und kurzfristigen Erfolgsdrucks ist die Investitionsbereitschaft für »Housekeeping« naturgemäß schwach ausgeprägt – auch wenn man dezidiert nachweisen kann, dass Firmen durch die Totalverweigerung jeglicher Budgets für Infrastruktur und Aufräumarbeiten schon mittelfristig in erheblichem Umfang Mehrkosten produzieren. Mit der Krise ab 2002 haben viele IT-Anwenderunternehmen auch ihre Funktionen für »Methoden, Verfahren und Werkzeuge« auf nahe an der Nulllinie reduziert, um kurzfristig Kosten zu sparen. Oft haben solche Teams auch Aufgaben im Bereich der IT-Unternehmensarchitektur wahrgenommen, deren Fehlen sich mittelfristig ebenfalls teuer bemerkbar machen wird.

Nutzen muss nachgewiesen werden.

Das zu beklagen hilft aber wenig. Man muss es vielmehr schaffen, den Nutzen über andere Argumentationsketten nachzuweisen.

Das gelingt Ihnen vor allem dann, wenn Sie Ihrem IT-Vorstand zeigen, dass Sie ihm dabei helfen können, seine Aufgabe erfolgreich anzugehen und auch durch Ihre Arbeit ein anerkanntes Mitglied des Topmanagement-Teams zu werden und zu bleiben.

Regulierungsdruck fördert solide Arbeit.

Wenn Ihnen das nicht spontan gelingt, arbeitet langfristig auch der wachsende Regulierungsdruck für Sie. Als Beispiele seien hier Entwicklungen genannt wie Solvency II, Basel II oder SOX (Sarbanes-Oxley Act), die auch eine Privathaftungskomponente für Vorstände enthalten können. An den Bereichen IT-Security oder Kartellrechts-Compliance kann man beobachten, wie blitzartig aufgeräumt werden kann, wenn der Vorstandsvorsitzende für Verstöße gegen allgemein als sicher akzeptierte Praktiken persönlich haftbar gemacht werden kann.

Bei den Unternehmen, die Funktionen wie beispielsweise IT-Unternehmensarchitektur haben, leben Chefarchitekten oft ähnlich gefährlich wie der IT-Vorstand selbst. Der Autor kennt fast so viele Architekten, die in der Hierarchie degradiert wurden oder denen das Budget so lange reduziert wurde, bis sie nur noch eine Alibifunktion hatten, wie solche, bei denen es »im Job einigermaßen« klappt. Der Autor kennt ferner viele Architekten, die zwar den Titel IT-Unternehmensarchitekt tragen – die aber zusammen mit ihren Mitarbeitern komplett in tagesaktuellen Projekten verbraucht werden.

IT-Unternehmensarchitektur ist bezahlbar.

Die gute Botschaft ist aber, dass es sehr wohl Ansätze gibt, wie man mit moderaten Budgets eine funktionierende IT-Unternehmensarchitektur aufbauen kann, die der IT-Vorstand und damit das komplette Topmanagement als nützlich empfindet.

Da Architekturfunktionen auf Unternehmensebene derzeit erst im Entstehen sind, werden Sie noch relativ wenige Job-Handbücher für solche Funktionen finden. Unter diesen sind nur wenige, die auf praktischer Erfahrung – positiver wie negativer Art – im Job als Chefarchitekt beruhen. Damit war die Idee geboren, diese Lücke zu schließen und dieses Buch zu schreiben. Es wird Ihnen Ansätze zeigen, mit denen Sie den Job als IT-Unternehmensarchitekt erfolgreich angehen können. Das Buch wird demonstrieren, wann der Job gefährlich ist und wie man die Gefahren nicht nur begrenzen kann, sondern auch als akzeptierter Helfer des IT-Vorstands erfolgreich agiert.

München – im Juli 2006

Wolfgang Keller

Danksagung

IT-Unternehmensarchitektur ist ein spannendes Thema. An die Architektur wirklich großer Softwaresysteme wird man durch die Praxis herangeführt und am besten durch ein professionelles Umfeld, das sich u.a. dieses Thema zum Anliegen gemacht hat. Ich bin durch die Firma sd&m (heute Capgemini) an dieses Umfeld herangeführt worden und möchte dafür Herrn Prof. Dr. Ernst Denert danken, der in dieser Firma eine Atmosphäre geschaffen hatte, in der nicht nur Termine und kurzfristige Gewinne eine Rolle gespielt haben, sondern aus der auch wirklich solide Arbeit auf dem Gebiet Softwarearchitektur für große Systeme hervorgegangen ist, wie auch zahlreiche andere Veröffentlichungen aus diesem Umfeld zeigen. Auch in 2023 arbeitet Herr Prof. Dr. Denert zusammen mit diversen gemeinsamen Bekannten aus sd&m-Zeiten immer noch an Themen rund um Softwarearchitektur und ich möchte mich bei Kollegen aus diesem Umfeld erneut für Impulse und angeregte Gespräche bedanken, die mich seit nunmehr etwas mehr als 30 Jahren begleiten.

Durch die Arbeit bei sd&m ergab sich für mich die Chance, die Architekturthemen auch an verantwortlicher Stelle in der Praxis anzugehen. Mein Dank gilt hier denen, die mir die Chance dafür gegeben haben: Herrn Walter Steidl, von dem ich gelernt habe, was es heißt, über lange Zeit und gegen Widerstände an Ideen festzuhalten, von denen man überzeugt ist, und auch Herrn Norbert Barth, von dem ich in Bezug auf langfristiges strategisches Denken sehr viel lernen konnte, vor allem wie man durch konsequent verfolgte Vereinfachungen viel Geld sparen kann.

In den mittlerweile fast 20 Jahren seit der Veröffentlichung der ersten Auflage dieses Buches habe ich zu meiner eigenen Verblüffung weniger als Unternehmensarchitekt, sondern meist als Interims- und Projektmanager in großen, teils global agierenden Unternehmen gearbeitet. In diesen Positionen konnte ich gut beobachten, wie sich die Unternehmensarchitektur weiterentwickelt hat. Meine Kontakte zur Community der Unternehmensarchitekten habe ich weiter gepflegt und auch kleinere Beratungsaufträge im Kontext von Coaching für Architekturgruppen übernommen.

Wesentliche Impulse konnte ich immer wieder durch die Zusammenarbeit mit dem Lehrstuhl Informatik 19 (sebis) der Technischen Universität München gewinnen. Hier möchte ich mich besonders bedanken bei Florian Matthes, André Wittenburg, Sabine Buckl, Alexander Ernst, Christian Schweda und Gloria Bondel, deren Arbeiten hier häufig zitiert und verwendet werden. Sie haben auch immer wieder Beiträge für eine teils gemeinsame Vorlesung zur IT-Unternehmensarchitektur an der Universität Potsdam geliefert. Ein weiterer Kollege, dem ich für seinen Input danken möchte und mit dem ich 2007 und 2008 Seminare zu EAM-Themen durchgeführt habe, ist Dieter Masak. Das, was ich über eine präzisere Definition von Business-IT-Alignment weiß, und viele Dinge mehr habe ich von ihm gelernt.

Mein Dank für das Beisteuern kompletter Abschnitte geht an:

Frau Gloria Bondel und Herrn Prof. Dr. Florian Matthes für den Abschnitt über hybride Wikis (

Abschnitt 5.4.2

).

Herrn Florian Oelmaier für das komplette

Kapitel 7

über Cybersicherheitsarchitektur. Ein solches Kapitel erfordert Spezialwissen, über das ich nicht in dem Maße verfüge wie Herr Oelmaier, der spezialisierter Berater für IT-Sicherheit und Cybersicherheitsarchitektur ist. Herr Oelmaier war so nett, dieses Kapitel auch für die 4. Auflage dieses Buches wieder zu überarbeiten. Sicherheit ist einer der Bereiche, der sich rasant weiterentwickelt.

Die Herren Dirk Slama und Ralph Nelius für die Erlaubnis zur Verwendung der

Abschnitte 3.2

bis

3.5

ihres Buches über Enterprise BPM

[Slama+11]

als Begriffssystem für SOA (

Abschnitt 9.3.1

).

Für angeregte Diskussionen und Iterationen zum Thema Service Portfolio Management (Abschnitt 4.8) möchte ich mich bei Herrn Michael Kunz bedanken.

Speziell für die 4. Auflage möchte ich mich bei Herrn Rolf Knoll bedanken, der mir geholfen hat, beim Thema TOGAF 10 schnell auf einen aktuellen Stand zu kommen.

Zum vierten Mal gilt mein Dank auch dem Verlagsteam vom dpunkt.verlag, speziell Frau Christa Preisendanz und Herrn René Schönfeldt, mit denen ich wiederholt zusammenarbeiten durfte. Und es hat wieder Spaß gemacht. Dafür danke!

Inhaltsübersicht

1Einleitung und Überblick

2Was ist IT-Unternehmensarchitektur?

3Zielmuster

4Managementprozessmuster

5Sichten und Informationsmodelle

6Compliance

7Cybersicherheitsarchitektur

8IT-Risikomanagement

9Makro-Architekturmuster

10Frameworks für IT-Unternehmensarchitektur

11IT-Management-Frameworks

12Werkzeuge für Enterprise Architecture Management

13Lean und Agile EAM

14Pragmatische Vorgehensweisen

15Einführungspfade für IT-Unternehmensarchitektur

16Ausblick

Anhang

ACheckliste für Richtlinien, Vorstudien und Architekturdokumente

BTextauszüge

CAbkürzungsverzeichnis

DGlossar

ELiteratur

Stichwortverzeichnis

Inhaltsverzeichnis

1Einleitung und Überblick

1.1Motivation des Buches

1.2Struktur des Buches

1.3Wer sollte dieses Buch lesen und warum?

1.3.1Eine Frage der Unternehmensgröße?

1.3.2IT-Unternehmensarchitekten

1.3.3Verantwortliche für Business Development

1.3.4IT-Vorstände, CIOs und CDOs

1.3.5Softwarearchitekten

1.3.6Alle anderen IT-Mitarbeiter

1.3.7Studierende

1.4Wie können Sie dieses Buch lesen?

1.5Einige Besonderheiten

1.5.1Sprache: Deutsch

1.5.2Verwendung von Wikipedia-Definitionen

1.6Was sich seit der ersten Auflage geändert hat

2Was ist IT-Unternehmensarchitektur?

2.1Das Substantiv: Unternehmensarchitektur als Struktur

2.1.1Geschäftsarchitektur

2.1.1.1Geschäftsarchitektur in TOGAF 10th Edition

2.1.1.2Geschäftsarchitektur nach Reynolds

2.1.1.3Geschäftsmodelle (Business Models)

2.1.1.4Digitale Geschäftsmodelle

2.1.1.5Enterprise Architecture nach Intersection Group

2.1.2IT-Unternehmensarchitektur

2.2Die Tätigkeit: Unternehmensarchitektur als Management

2.3Musterbasierter Ansatz für IT-Unternehmensarchitektur

3Zielmuster

3.1Business-IT-Alignment

3.1.1Bedeutung

3.1.2Dimensionen

3.1.3Zwischenbilanz

3.2Verbesserung der Ertragskraft und Kostenmanagement

3.2.1Verbesserung der Ertragskraft des Business

3.2.2Reduktion von IT-Kosten

3.3Optimierung mit Sourcing-Strategien

3.4Verbesserung Time-to-Market

3.5Verbesserung Kundenzufriedenheit

3.6Reduktion von Heterogenität

3.7Bewältigung von Fusionen

3.8Compliance, Sicherheit und Risikomanagement

4Managementprozessmuster

4.1IT-Strategieentwicklung

4.1.1Was ist eine Strategie?

4.1.2Ein kurzer Blick auf den Strategieprozess

4.1.3Wozu sollte eine IT-Strategie Aussagen machen?

4.1.4Wo bleibt hier bitte die Digitalisierung?

4.1.5Herausforderungen bei der Umsetzung in der Praxis

4.1.6Der Maxime-Prozess

4.2Business-IT-Alignment herstellen mit Capabilities

4.2.1Was sind Capabilities?

4.2.2Investitionssteuerung mit Capabilities

4.2.3Wie kommt man zu einem sinnvollen Katalog von Capabilities?

4.2.4Wie kommt man zu den Bewertungen der Capabilities?

4.2.5Zwischenbilanz: Warum helfen Capabilities bei der strategischen Ausrichtung einer Anwendungslandschaft?

4.2.6Optimierung des Sourcings einer Anwendungslandschaft mit Capabilities

4.2.7Vergleich von Anwendungen mit Footprints

4.3Management des Anwendungsportfolios

4.3.1Grundlegende Begriffe zum Management des Anwendungsportfolios

4.3.2Management des Anwendungsportfolios als zyklischer Prozess

4.4Erfassung der Ist-Anwendungslandschaft

4.4.1Umfang

4.4.2Typische Attribute für eine minimale Befüllung

4.4.3Erfassung von Schnittstellen: Ja oder Nein?

4.4.4Keyvisual für die Anwendungslandschaft

4.4.5Tipps und Tricks

4.5Auswertungen des Anwendungsportfolios

4.6Anwendungslandschaft, Metriken und Dashboards

4.7Strategische Bebauungsplanung

4.7.1Grundsätzliches Vorgehen

4.7.2Erfassen der Anforderungen (Scoping)

4.7.3Analyse und Bewertung (Analysis)

4.7.4Erarbeiten der Zielbebauung (Design)

4.7.5Abstimmung (Design)

4.7.6Maßnahmenplanung (Plan Implementation)

4.7.7Zusammenfassung der strategischen Bebauungsplanung

4.8Management eines Serviceportfolios

4.9Managed Evolution

4.10Etablieren eines IT-Governance-Systems

4.10.1Was ist IT-Governance?

4.10.2Hierarchie von Governance-Systemen

4.10.3Stile von IT-Governance

4.10.4Hinzunahme des Unternehmenstyps

4.11Architektur-Governance

4.11.1Aufbauorganisation der IT-Governance und Architektur-Governance

4.11.2Entwicklung und Durchsetzung von Richtlinien

4.11.3Monitoring des Projektportfolios

4.11.4Projektbegleitung

4.11.5Über Reviews im Rahmen der Projektbegleitung

4.12SOA-Governance

4.12.1Schichten

4.12.2Operationale und technische SOA-Governance

4.12.3Business-Motivation für SOA

4.13Management von Fusionen

4.13.1Die Leiter der Integration

4.13.2Grundmuster von Anwendungskonsolidierungen

4.14Reduktion von Heterogenität

5Sichten und Informationsmodelle

5.1Softwarekartografie als Grundlage der Systematisierung

5.2Typen von Softwarekarten

5.2.1Clusterkarten

5.2.2Prozessunterstützungskarten

5.2.3Intervallkarten

5.2.4Karten ohne Kartengrund

5.3Viewpoints und Viewpoint-Patterns

5.3.1Viewpoints in ISO/IEC/IEEE 42010 und TOGAF

5.3.2Viewpoint-Patterns

5.3.3Diskussion der Pattern-Qualität

5.4Informationsmodelle

5.4.1Das TOGAF Content Metamodel

5.4.2Hybride Wikis als Repository für IT-Unternehmensarchitektur

6Compliance

6.1Was ist »Compliance«?

6.2IT-Compliance im Kontext von Enterprise Compliance

6.3Exemplarische Compliance-Themen für die IT

6.3.1Basel II, III und IV

6.3.2Solvency II

6.3.3Der Sarbanes-Oxley Act (SOX)

6.4KonTraG

6.5Aufbewahrungsfristen

6.5.1E-Mails sind archivierungspflichtig

6.5.2Stilllegung von DV-Systemen

6.6COBIT und Compliance

6.6.1Beispiel aus APO02 – Managen der Strategie

6.6.2Beispiel aus APO03 – Managen der Unternehmensarchitektur

6.7Der Clinger-Cohen Act

7Cybersicherheitsarchitektur

7.1Zielmuster

7.1.1Zielmuster: Bedrohungen abwehren

7.1.1.1Schutzbedarfsanalyse

7.1.1.2Bedrohungsanalyse

7.1.1.3Umfassender Schutz

7.1.2Zielmuster: Compliance herstellen

7.1.2.1Identifikation der Anforderungen

7.1.3Zielmuster in Einklang bringen

7.1.4Zusammenhang mit dem Risikomanagement

7.2Managementprozessmuster

7.2.1Sicherheitsstrategie

7.2.2Cybersicherheitsparadigmen

7.2.2.1Defend the Perimeter

7.2.2.2Assume Breach

7.2.2.3Defense in Depth

7.2.2.4Jeder schützt sich selbst

7.2.2.5Betreibbarkeit geht vor Sicherheit

7.2.2.6Security/Privacy by Design

7.2.3Organisation der Cybersicherheit

7.2.3.1Modell: Zentrale IT

7.2.3.2Modell: Dezentrale IT

7.2.3.3Modell: One IT-Team

7.2.3.4Mischformen

7.2.3.5Sicherheit auf Projektebene

7.2.4Umsetzung des ISO-2700x-Standards

7.2.4.1Überblick

7.2.4.2Einführung ISMS

7.2.5Prüfung der Sicherheit

7.2.5.1Audits

7.2.5.2Penetrationstests/Redteaming

7.2.5.3Outside-In Checks

7.2.5.4Schwachstellenscans

7.2.5.5Awareness-Trainings

7.2.5.6Phishing-Tests

7.2.6Umgang mit Notfällen und Krisen

7.2.6.1Reaktive Sicherheit als Aufgabe der CISO-Organisation

7.2.6.2Vorbereitungen für das Alarmstufenmanagement

7.2.6.3Tatorthygiene für Administratoren

7.2.6.4Alarmstufe Gelb: 100% Wachsamkeit

7.2.6.5Alarmstufe Orange: Schilde hoch, Waffen bereit machen

7.2.6.6Alarmstufe Rot: Krise

7.3Lösungsmuster auf Infrastrukturebene

7.3.1Unternehmensweite Sicherheitssegmente

7.3.2Aufbau unternehmensweiter Sicherheitsinfrastrukturen

7.3.2.1Phishing-Schutz

7.3.2.2Client Hardening

7.3.2.3Zugänge von außen kontrollieren

7.3.2.4Offline-Backup

7.3.2.5Domäne schützen

7.3.2.6Erkennung von Angriffen im internen Netz

7.3.2.7Patchmanagement

7.3.2.8Virtualisierungsinfrastruktur

7.3.2.9Cloud-Umgebungen

7.3.2.10Zentrales Logging und Protokollierung

7.3.3Sicherheit betreiben

7.4Lösungsmuster auf Applikationsebene

7.4.1Konzeptionelle Architekturmuster

7.4.1.1Klare Sicherheitsverantwortung

7.4.1.2Sicherheitsorientierte Segmentierung

7.4.1.3Sichere Modellierung der fachlichen Schnittstellen

7.4.1.4Zentrale Infrastrukturen

7.4.1.5Applikationsinternes Software Lifecycle Management

7.4.1.6Defense in Depth

7.4.1.7Sicherheitsmanagement über den Lifecycle hinweg

7.4.1.8Compliance

7.4.2Funktionale Architekturmuster

7.4.2.1Rollen und Rechte

7.4.2.2Logging

7.4.2.3Privacy by Design, Privacy by Default

7.4.2.4Updates, Apps, Sandboxing

7.4.3Nicht funktionale Architekturmuster

7.4.3.1Modellierung von Schutzzonen

7.4.3.2Risikobewusste Einbindung von Anwendungen in die Netzwerkinfrastruktur

7.4.3.3Verschlüsselung auf Applikationsebene

7.4.3.4Verschlüsselung auf Netzwerkebene

7.4.3.5Einbindung in Infrastruktur- und Betriebssicherheit

7.4.3.6Sicherheitsbewusstes Codedesign

7.4.3.7Sicherheitstechnisch korrekte Konfiguration

7.4.4Testen

7.4.5Dokumentation & Vollständigkeitscheck

7.5Zusammenfassung

8IT-Risikomanagement

8.1Was ist Risikomanagement?

8.2Management von Risiken mit Total Risk Profiling

8.3Risikoregister für Anwendungen

9Makro-Architekturmuster

9.1Blueprints und Architekturrichtlinien

9.1.1Abstützen auf Standards

9.1.2Beschreibungsmittel

9.1.3Marchitecture: der Marketingaspekt

9.2Beispiel: Facharchitektur für Versicherungen

9.2.1Beispiel zur Beschreibungstiefe einer Facharchitektur

9.2.2Einsatz und Nutzen einer Facharchitektur

9.2.3Abgrenzung zu Informationsarchitekturen

9.2.4Verwendung der Facharchitektur für die Bebauungsplanung

9.3Beispiele für technische Architekturmuster

9.3.1Beispiel: SOA

9.3.2Beispiel: Blueprint für Internetanwendungen

9.3.3Beispiel: Microservices und REST

10Frameworks für IT-Unternehmensarchitektur

10.1Ordnungsrahmen für EAM- und IT-Management-Frameworks

10.2TOGAF 10th Edition

10.2.1Die Sicht von TOGAF 10th Edition auf IT-Unternehmensarchitektur

10.2.2Der Kern von TOGAF: die »Architecture Development Method« (ADM)

10.2.3Abgleich von TOGAF mit Prozessclustern der IT-Unternehmensarchitektur

10.2.4Abdeckung weiterer Aufgabenbereiche durch TOGAF

10.2.5Sonstige nützliche Aspekte von TOGAF

10.2.6Künftige Versionen von TOGAF

10.3Zachman-Framework

11IT-Management-Frameworks

11.1COBIT

11.1.1Grobstruktur des COBIT-Prozessmodells

11.1.2Nutzen von COBIT für IT-Unternehmensarchitekten

11.2ITIL

11.2.1ITIL 3

11.2.2ITIL 4

12Werkzeuge für Enterprise Architecture Management

12.1Abwägungen beim Werkzeugeinsatz

12.2Umfang eines integrierten IT-Planungswerkzeugs

12.2.1Zu unterstützende Prozesse der IT-Unternehmensarchitektur

12.2.2Sonstige Prozesse des IT-Managements

12.2.3Schnittstellen eines IPIT zu anderen Arten von Werkzeugen

12.2.4Weitere funktionale Anforderungen an IPITs

12.2.5Nicht funktionale Anforderungen an IPITs

12.3Möglicher Umfang von Planungswerkzeugen

12.3.1Werkzeuge mit maximalem Umfang: das umfassende Informationssystem für die IT-Funktion?

12.3.2Werkzeuge mit realistischem Funktionsumfang: IPIT

12.3.3Werkzeuge mit mittlerem Funktionsumfang: Aufsätze auf bestehenden Lösungen

12.3.4Werkzeuge mit geringem Funktionsumfang: Ad-hoc-Werkzeuge nur für Bebauungsplanung

12.4Herkunft der Werkzeuge

12.5Marktsituation

13Lean und Agile EAM

13.1Lean und IT-Unternehmensarchitektur

13.1.1Lean-Prinzipien

13.1.2Lean auf Prozesse der IT-Unternehmensarchitektur anwenden

13.2Die Tätigkeit: agile Praktiken auf EAM-Prozesse anwenden

13.2.1Agiles Manifest und agile Prinzipien

13.2.2Abgleich Lean und Agile

13.3Das Substantiv: agile Softwarearchitektur

14Pragmatische Vorgehensweisen

14.1Angemessenes Budget für IT-Unternehmensarchitektur

14.1.1Zahlt sich IT-Unternehmensarchitektur aus?

14.1.2Wie groß sollte eine Architekturgruppe sein?

14.2Wie viel Ordnung muss sein?

14.2.1Wie sorgt man für die Reduktion von Komplexität?

14.2.2Wie viel Ordnung ist gut? Gibt es zu viel Ordnung?

14.3Gefahren für Unternehmensarchitekten

14.3.1Exkurs: Organisationsmuster für die IT-Funktion

14.3.2Auf die Beschaffungsseite fixierter IT-Vorstand

14.3.3Organigramm alten Stils

14.3.4Hierarchiedenken

14.3.5Chicken Race

14.3.6Mangelnde Offenheit

14.3.7Verzetteln: keine klare Strategie

14.3.8Inkonsequenz

14.4Zusammenarbeit mit Lösungsarchitekten

14.4.1Warum macht der IT-Unternehmensarchitekt nicht meine Projektarchitektur?

14.4.2Das Kostendilemma der Wiederverwendung

14.5Tipps und Tricks

14.5.1Architekturtickets

14.5.2Radar-Chart-Methode

14.5.3Chefmanagement

15Einführungspfade für IT-Unternehmensarchitektur

15.1IT-Unternehmensarchitektur für Großunternehmen

15.2Einführungspfade für IT-Unternehmensarchitektur mit und ohne Topmanagement-Unterstützung

15.3Wege in Konzernen mit dezentralen IT-Einheiten

16Ausblick

Anhang

ACheckliste für Richtlinien, Vorstudien und Architekturdokumente

A.1Wer kann diese Checkliste verwenden und warum?

A.2Zu Beginn

A.2.1Reviewen ist eine Dienstleistung für den Autor

A.2.2Schreiben ist eine Dienstleistung für den Leser

A.3Kontrollfragen

A.3.1Kontrollfragen zur Geschichte, die das Dokument wiedergibt

A.3.2Formalia

BTextauszüge

B.1Auszug SOX Sections 302 und 404

B.2Auszug AO (Abgabenordnung)

CAbkürzungsverzeichnis

DGlossar

ELiteratur

Stichwortverzeichnis

1Einleitung und Überblick

Anforderungen an das IT-Management steigen.

Die Anforderungen an das IT-Management sind über die Jahre, in denen sich die Informationstechnologie weiterentwickelt hat, kontinuierlich gestiegen. Während es in den 1980er-Jahren ausgereicht hat, die sogenannte Beschaffungsseite der IT (siehe Abb. 1–1) im Griff zu haben – also überhaupt eine einigermaßen lauffähige IT betreiben zu können –, hatte sich die Situation bis ca. 2005 dahingehend weiterentwickelt, dass es nun wichtig war, die IT als sogenannten Enabler zu führen. Dafür war es wichtig, als IT-Verantwortlicher primär das Geschäft zu verstehen und es optimal mit den Mitteln der Informationstechnologie zu unterstützen. Noch besser war und ist es, wenn der IT-Verantwortliche in der Lage ist, dem Topmanagement echte Innovation mit IT-Hilfe anzubieten. Nicht jedes Geschäft setzt hier auf den Einsatz von Informationstechnologien. Nachdem heute aber sehr viele Geschäftsprozesse automatisiert und in IT-Systemen abgebildet sind, kann IT oft einen wichtigen Hebel für die Innovation darstellen und ist häufig eine wesentliche Komponente neuer Geschäftsmodelle. Der Trend, dass IT immer mehr zum Bestandteil neuer Geschäftsmodelle wird, spiegelt sich inzwischen auch im Thema »Digitalisierung« wider. IT ist nicht mehr eine Unterstützungsfunktion für Geschäftsmodelle, sondern wird selbst zum Teil des Geschäftsmodells. Häufig werden durch Digitalisierung sehr große Veränderungsprogramme in einer Unternehmens-IT verursacht. Solche großen Programme müssen gesteuert werden, und zwar sowohl, was das Projektmanagement anbelangt, als auch, was die Planung der IT-Unternehmensarchitektur betrifft.

Abb. 1–1Agenda eines IT-Vorstands nach [Broadbent+05]

Time-to-Market

Darüber hinaus haben sich Produktzyklen weiter verkürzt. Dies hat zur Folge, dass sich die IT-Landschaften schneller entwickeln müssen, als dies noch vor fünf oder zehn Jahren der Fall war. Apps für mobile Geräte sind heute bei Updatezyklen von durchschnittlich 30 Tagen angelangt [Kelly16]. Applikationen im Bereich mobiler Geräte und von Webfrontends sind teilweise »permanente Betaversionen«. Sogenannte Kernsysteme oder Bestandssysteme sollten ein solches Tempo eher nicht mitgehen – deshalb wird auch die sogenannte Two-Speed-IT heute kontrovers diskutiert.

Compliance und Sicherheit

Auf der Gegenseite der Beschleunigung finden sich verschärfte Anforderungen an die Compliance (das Einhalten von Gesetzen), eine wesentlich gesteigerte Sensibilität für IT-Sicherheit und Cybersicherheitsarchitektur sowie ein deutlich niedrigeres Risikoniveau, das die Öffentlichkeit, die Kunden, die Aktionäre oder der Gesetzgeber bereit sind zu akzeptieren. Das heißt, Risikomanagement – auch und gerade für die IT – spielt ebenfalls eine wichtige Rolle. Diese drei zuletzt genannten Entwicklungen machen Projekte eher langsamer als schneller.

Aus der Softwarearchitektur, die Einzelsysteme gestaltet, ist bekannt, dass mit Architekturmitteln sich einzelne Anwendungen schneller, sicherer und effizienter ändern lassen. Analog kann man auch ein komplettes Portfolio von Anwendungen so gestalten, dass sich Änderungen möglichst zügig, sicher und effizient durchführen lassen.

IT-Alignment

Die IT-Funktion eines großen Unternehmens muss im Regelfall heute also mindestens zwei Themengebiete beherrschen:

Einerseits muss sie Enabler für ein Geschäft sein, das sich schnell ändern kann und in vielen Fällen von aggressiven Start-ups angegriffen werden wird,

andererseits soll sie gesetzliche Auflagen erfüllen und verhindern, dass ein Unternehmen durch Sicherheitsprobleme in negative Schlagzeilen gerät, die schnell existenzbedrohende Ausmaße annehmen können.

Große Unternehmen müssen dabei viele Arten von Wettbewerbern abwehren. Kleine aggressive Start-ups können sich auf kleine lukrative Teile des Geschäftsportfolios des großen Unternehmens konzentrieren und dadurch Teile des Gewinns angreifen. Große Internetunternehmen können sich zwischen ein Unternehmen und seine Kunden schieben und dadurch die Kundenbeziehung gefährden oder Gewinn daraus abschöpfen. KI-Assistenten werden diesen Trend noch gefährlicher für die Unternehmen machen, wenn die Kunden aus Bequemlichkeit einen »künstlich intelligenten« digitalen Assistenten von Google oder Amazon fragen, der dann im Hintergrund die Anfrage des Kunden versteigert und auf den Kanal leitet, der dem Internet-Giganten am meisten für den Kontakt bietet. Bei Onlinewerbung sind solche Versteigerungen bereits üblich. Durch den Einsatz von Assistenzsystemen werden sie sich weiter verbreiten.

Man erkennt leicht, dass sich solche Anforderungen, nämlich die Abwehr schneller oder extrem mächtiger Wettbewerber aus dem Internet, von der Commodity-IT, wie sie noch vor 20–25 Jahren weit verbreitet war, deutlich unterscheiden. IT-Management benötigt heute auch fortgeschrittenere Methoden als beim Erscheinen der ersten Auflage dieses Buches vor fast 20 Jahren. Zum Glück haben sich die Methoden kontinuierlich weiterentwickelt und verbessert.

1.1Motivation des Buches

Rolle IT-Unternehmensarchitektur

Wenn IT-Management heute für viele Unternehmen wichtiger ist als jemals zuvor, kann man sich die Frage stellen, welche Rolle denn dann IT-Unternehmensarchitektur spielt. So viel sei vorweg gesagt: IT-Unternehmensarchitektur deckt zentrale Gebiete eines fortschrittlichen IT-Managements ab. Abbildung 1–2 zeigt im Vergleich zwei Modelle für IT-Governance. In beiden Modellen sind jeweils die wichtigsten Aufgabenblöcke genannt, die ein IT-Gesamtverantwortlicher organisieren muss, um erfolgreich zu sein. Wenn man die Blöcke kurz durchgeht, ist leicht zu sehen, dass IT-Unternehmensarchitektur eine breite Rolle im IT-Management einnimmt.

Gebräuchliche IT-Governance-Modelle z.B. ITGI

IT-Governance-Modell nach Weill

IT-Strategie

IT Principles

IT-Betrieb

IT Infrastructure Strategies

IT Architecture

IT-Architektur

Business Application Needs

IT-Programmmanagement

IT Investment and Prioritization

IT-Controlling

IT-Human-Resource-Management

IT-Risikomanagement

Abb. 1–2Aufgabengebiete des IT-Managements – dargestellt anhand der Gliederungen des IT Governance Institute® (ITGI®, links) [ITGI11] und nach Weill (rechts) [Weill+04]

IT-Strategie

IT-Strategie: Der IT-Unternehmensarchitekt ist meist der maßgebliche Helfer des CIO, wenn es darum geht, eine IT-Strategie zu definieren. Dieses Thema wird sowohl in den Kapiteln über Zielmuster (Kap. 3) als auch über Prozessmuster (Kap. 4) ausführlich erläutert.

IT-Betrieb

IT-Betrieb: Unternehmensarchitekten, die meist ihren Berufsweg in der Softwareproduktion (Programmierung, Softwaredesign, Softwarearchitektur) zurückgelegt haben, vergessen zu oft, dass es wesentlich lohnender sein kann, Infrastruktur statt Software kostenmäßig zu optimieren. Bei vielen Unternehmen macht der Anteil der reinen Betriebskosten bis zu 70 Prozent der gesamten IT-Kosten aus. Es ist relativ klar, dass hier ein deutlich größerer Hebel liegen kann als in der Optimierung von Softwareprojekten. Durch Cloud Computing sind die Möglichkeiten, Betriebskosten zu senken, in den letzten fünf Jahren eher noch umfangreicher geworden. Man muss heute keine eigenen Rechenzentren mehr konsolidieren. Man kann sie in vielen Fällen vollständig in die Cloud auslagern und eigene Rechenzentren damit komplett abschaffen. Entsprechend ist es für einen IT-Verantwortlichen wichtig, über eine Technologiestrategie zu verfügen. Auch eine Sourcing-Strategie ist wichtig, da nicht jedes Unternehmen die komplette Infrastruktur, die es benötigt, selbst betreiben möchte. Dieses Thema erhält weiteren Schub durch Themen wie Cloud und »Software as a Service« (SaaS) und wird in diesem Buch sowohl bei den Zielmustern als auch bei den Prozessmustern behandelt.

IT-Architektur

IT-Architektur: Dass sich IT-Unternehmensarchitektur auch mit IT-Architektur (Lösungsarchitektur) beschäftigen muss, liegt nahe. Die Unternehmensarchitektur erarbeitet u.a. auch die Vorgaben für Zielarchitekturen und Blueprints als Muster für eine Menge von Einzelsystemen. Oft muss man hier allerdings nicht mehr viel selbst erarbeiten. Die meisten Cloud-Provider bieten Open-Source-Software-Stacks an, die schon einmal eine gute Grundlage für eine Lösungsarchitektur bilden. Gewisse Dinge, wie die Oberflächenarchitektur, sind allerdings nach wie vor selbst zu komplettieren, auch wenn es hier ebenfalls wieder sehr gute Vorarbeiten in Form von großteils Open-Source-Umgebungen gibt.

IT-Programmmanagement

IT-Programmmanagement: Dies ist der wesentliche Bereich des IT-Managements, der üblicherweise nicht von den IT-Unternehmensarchitekten selbst betreut wird. Hierfür gibt es in den meisten Unternehmen heute Project Management Offices, die ein unternehmensweites Programmmanagement für alle Vorhaben eines großen Unternehmens betreiben. Dementsprechend wird auch das Thema Multiprojektmanagement (siehe z. B. [Hirzel+19]) in diesem Buch nicht zentral behandelt.

IT-Controlling

IT-Controlling und IT-Human-Resource-Management fallen üblicherweise ebenfalls nicht in das Aufgabengebiet eines IT-Unternehmensarchitekten. Ebenso wird es meistens einen separaten IT-Risikomanager geben. Dieser arbeitet häufig eng mit den IT-Unternehmensarchitekten zusammen, da das Risikoregister normalerweise zusammen mit der Informationsbasis der IT-Unternehmensarchitekten gepflegt und visualisiert wird.

Zusammenfassend kann man also sagen, dass ein CIO (Chief Information Officer), der über eine gute Stabsstelle für IT-Unternehmensarchitektur verfügt, wesentliche Teile seines Aufgabenportfolios damit abdecken kann. Oder anders formuliert: IT-Unternehmensarchitektur deckt einen sehr großen Teil der wesentlichen IT-Managementaufgaben ab, die zentral im Umfeld eines CIO anfallen.

1.2Struktur des Buches

Überblick über das Buch

Nach Einführung und Überblick und einigen grundlegenden Begriffsdefinitionen (Kap. 2) gliedert sich das Buch in drei große Teile (siehe auch Abb. 1–3).

Einleitung, Überblick, BegriffeKapitel 1 und 2

EAM-Kern

ZielmusterKapitel 3

ManagementprozessmusterKapitel 4

Sichten und InformationsmodelleKapitel 5

Ergänzende Wissensgebiete

ComplianceKapitel 6

CybersicherheitsarchitekturKapitel 7

IT-RisikomanagementKapitel 8

Makro-ArchitekturmusterKapitel 9

Prozesse

Lean und Agile EAMKapitel 13

Frameworks▪Kapitel 10 und 11▪ TOGAF (Kapitel 10)▪ Zachman (Kapitel 10)▪ COBIT (Kapitel 11)▪ ITIL (Kapitel 11)

Pragmatische VorgehensweisenKapitel 14

EinführungspfadeKapitel 15

Werkzeuge für Enterprise Architecture ManagementKapitel 12

AusblickKapitel 16

Abb. 1–3Kapitelstruktur des Buches

EAM-Kern

EAM-Kern: Der Teil über den Kern von Enterprise Architecture Management (EAM) beschreibt vor allem den Umgang mit den funktionalen (geschäftsorientierten) Anforderungen an die IT-Funktionen eines Unternehmens. Hier erfahren Sie, wie Sie Ihre Funktionen für die IT-Unternehmensarchitektur so aufbauen bzw. anpassen können, dass sie den Anforderungen des Geschäfts genügen.

ZielmusterManagementprozessmusterInformationsmodelle

In der Praxis kann man dabei immer wieder bestimmte Muster entdecken. Solche Muster lassen sich sowohl für Ziele von Unternehmen erkennen als auch für die Art und Weise, wie Unternehmen versuchen, ihre Ziele zu erreichen. In Kapitel 3 finden Sie gebräuchliche Zielmuster. Solche Zielmuster beschreiben typische Anforderungen an die IT-Funktionen eines Unternehmens Es ist charakteristisch, dass Sie als Unternehmensarchitekt deutlich mehr als ein einziges Ziel verfolgen müssen. Die Zielmuster sind auch nicht immer trennscharf voneinander abgegrenzt. Mithilfe solcher Muster ist es erheblich einfacher und schneller möglich, sinnvolle Ziele für das IT-Management und damit auch die IT-Unternehmensarchitektur zu beschreiben. Zielmuster werden üblicherweise dadurch erfüllt, dass man Managementprozessmuster anwendet. Diese finden Sie in Kapitel 4. Für bestimmte Arten von Zielen haben sich heute Prozesse etabliert, die das Erreichen dieser Ziele unterstützen. Eine weitere interessante Frage ist dann, welche Sichten und Informationsmodelle benötigt werden, um die Managementprozesse zu unterstützen. Deren wesentliche Formen werden in Kapitel 5 diskutiert. Es gibt jedoch Hunderte von möglichen Diagrammformen und Metamodellvarianten, die eine hohe dreistellige bis zu einer kleinen vierstelligen Anzahl von Metaentitäten enthalten. Hier wird das Buch also vor allem auf weiterführende Quellen hinweisen, die umfangreiche Kataloge von Sichten und Informationsmodellen und deren mögliche Metaentitäten enthalten.

Musterbasierter Ansatz

Der musterbasierte Ansatz, der im Buch verwendet wird, unterstellt, dass es kein »one version fits everybody«-EAM gibt, sondern dass Ziele in Unternehmen verschieden sind. Wenn Sie alle möglichen Metaentitäten füllen und alle denkbaren Auswertungen durchführen würden, würden Sie einen viel zu hohen Aufwand für EAM treiben. Es ist preiswerter, genau die Dinge zu tun, die für die Erreichung einer bestimmten Menge von Zielmustern erforderlich sind. Auf diese Weise kann und sollte man sich sein EAM selbst konfigurieren. Dabei helfen nicht nur Zielmuster, sondern auch die dazugehörigen Managementprozessmuster sowie die dazu passenden Sichten und Informationsmodellmuster. Dieses Buch ist damit seit der zweiten Auflage feinteiliger aufgebaut als die erste Auflage, die als Leitlinie für die Gliederung lediglich eine EAM-Prozesslandkarte verwendet hat, wobei diese nach wie vor enthalten ist. Für die vorliegende vierte Auflage wurde der Musteransatz beibehalten. Einzelne Prozesse finden sich nach wie vor auch in den Managementprozessmustern wieder, die seit der ersten Auflage beschrieben wurden.

Weitere Wissensgebiete

Ergänzende Wissensgebiete: In einem anspruchsvollen, modernen Unternehmensumfeld reicht es heute für einen Unternehmensarchitekten bei Weitem nicht mehr aus, nur technisch und funktional »ordentliche Lösungen« bauen zu können. Gesetzgeber, Öffentlichkeit und weitere Stakeholder haben eine Vielzahl von Ansprüchen an die Systemlandschaften von Unternehmen, die weit über die reine betriebswirtschaftliche Funktion und den technischen Aufbau hinausgehen. Solche weiter gehenden Querschnittsanforderungen kann man mit nicht funktionalen Anforderungen in der inzwischen klassischen Disziplin Softwarearchitektur vergleichen. Sie tragen zum Geschäftszweck unmittelbar nichts bei – wenn man sich allerdings nicht ausreichend um sie kümmert, haben sie das Potenzial, das Unternehmen ernsthaft zu gefährden oder sogar zu vernichten. Dies gilt sowohl für Compliance (Kap. 6) als auch für die Themen IT-Sicherheit und Cybersicherheitsarchitektur (Kap. 7) sowie IT-Risikomanagement (Kap. 8). Zum schnellen Finden sinnvoller Lösungen bedienen sich Unternehmensarchitekten darüber hinaus sogenannter Makro-Architekturmuster. Dies sind Architekturmuster im großen Maßstab, z. B. Blaupausen für den fachlichen Aufbau einer kompletten Anwendungslandschaft einer Versicherung oder eines Telekommunikationsunternehmens. Makro-Architekturmuster werden in Kapitel 9 beschrieben.

Prozesse der IT-Unternehmensarchitektur

Prozesse: Abgesehen von den Managementprozessmustern in Kapitel 4, die jeweils zu einer Menge von Zielmustern (Kap. 3) passen, gibt es auch Prozessbausteine, die für das Management von IT-Unternehmensarchitekturen unabhängig von den Zielmustern eingesetzt werden.

EAM-Frameworks

Beim Design Ihrer speziellen Prozesse für das Management der IT-Unternehmensarchitektur in Ihrem Unternehmen werden Sie mit großer Wahrscheinlichkeit sogenannte EAM-Frameworks sowie weitere Frameworks für das IT-Management benutzen. Eine Auswahl der gebräuchlichsten Frameworks finden Sie in den Kapiteln 10 und 11. In einem ausführlichen Abschnitt über TOGAF (Abschnitt 10.2) erhalten Sie einen Überblick über das derzeit wichtigste EAM-Framework.

EAM-Tools

Werkzeuge für Enterprise Architecture Management: Früher oder später werden Sie ein EAM-Werkzeug einsetzen. In Kapitel 12 erfahren Sie, wo diese Werkzeuge herkommen, und erhalten Hinweise darauf, wie Sie das passende Werkzeug finden.

Pragmatik

Pragmatisches Vorgehen: Das Buch ist so geschrieben, dass Sie zunächst den kompletten erforderlichen »Lernstoff« vermittelt bekommen, auf dessen Grundlage dann Dinge, wie Lean EAM (Kap. 13), pragmatische Vorgehensweisen (Kap. 14) und Einführungspfade (Kap. 15), diskutiert werden können.

Lean und Agile EAM

In den ca. 10 Jahren seit der zweiten Auflage dieses Buches haben sich als Varianten Lean EAM und Agile EAM herausgebildet. Ziel der Anwendung von Lean-Prinzipien und agilen Prinzipien auf EAM ist es, ein überbürokratisches EAM im Elfenbeinturm zu vermeiden und stattdessen die Aktivitäten konsequent an der Wertschöpfung für das Unternehmen und an den Bedürfnissen der Betroffenen auszurichten. In Kapitel 13 wird gezeigt, dass der musterbasierte Ansatz mit solchen Überlegungen sehr gut verträglich ist. In dem musterbasierten Ansatz finden sich sowohl die Muster, die man benötigt, um ein EAM »lean« auszugestalten, als auch solche, um es »agil« zu machen. Im Wesentlichen heißt das in beiden Fällen, Dinge wegzulassen, die nicht von den Stakeholdern benötigt werden.

Wenn Sie sich an einige pragmatische Vorgehensweisen halten, erleichtern Sie sich die Arbeit. Eine Auswahl finden Sie in Kapitel 14. Hier wird z. B. die Frage diskutiert, ob perfekte Ordnung (also null Heterogenität) wirklich sinnvoll ist oder wo pragmatische Grenzen liegen.

Einführungspfade

Wenn Ihre Stabsfunktion IT-Unternehmensarchitektur noch nicht etabliert ist, werden Sie sich fragen, wie Sie eine solche Funktion am sinnvollsten einführen. Hierzu finden Sie Informationen in Kapitel 15, Einführungspfade für IT-Unternehmensarchitektur.

Trends

Ausblick: In Kapitel 16 finden Sie zum Abschluss des Buches Aussagen zu Trends beim Management der IT-Unternehmensarchitektur.

Wie alles zusammenpasst:Abbildung 1–4 vermittelt Ihnen einen alternativen Überblick über die wesentlichen Zusammenhänge des Buches.

Abb. 1–4Zusammenhang der Teile des Buches

Vom Istzustand …

Wenn Sie Verantwortung als IT-Unternehmensarchitekt übernehmen, werden Sie immer einen Ausgangszustand Ihrer IT-Landschaft vorfinden. In Kapitel 4 zu Prozessmustern finden Sie u.a. Hinweise dazu, wie man diesen Ausgangszustand beschreiben kann. Sehr häufig wird dazu ein EAM-Werkzeug (Kap. 12) eingesetzt, um die Daten über die existierende IT-Landschaft zu erfassen. In welcher Intensität dies geschieht, hängt allerdings von den Zielen ab (Zielmuster, siehe Kap. 3), die Sie mit Ihrer Initiative zur IT-Unternehmensarchitektur verfolgen.

… zum Zielzustand

Der Zielzustand, den Sie für jede Periode strategischer Planung herbeiführen wollen, ist davon abhängig, welche Ziele Sie und Ihre Unternehmensleitung mithilfe von IT-Unternehmensarchitektur erreichen wollen. Auch für Ziele gibt es Muster, die man in vielen Unternehmen finden kann. Solche Zielmuster, die in vielen Unternehmen in ähnlicher Form angestrebt werden, finden Sie in Kapitel 3.

Managementprozessmuster

Sie werden sich dann für einen Weg entscheiden, wie Sie vom Ausgangszustand in den Zielzustand gelangen können. Dazu haben sich Managementprozessmuster bewährt (siehe Kap. 4).

Informationsbasis

Für die Umsetzung dieser Managementprozesse benötigen Sie Informationen über den Zustand Ihrer IT-Landschaft. Diese werden normalerweise in Sichten aggregiert. Beispiele für solche Sichten sind z. B. sogenannte Softwarekarten, auf denen der Zustand einer IT-Landschaft schnell erfasst und dokumentiert werden kann. Für die Erstellung solcher Karten benötigt man eine Informationsbasis, bestehend aus Sichten und Informationsmodellen. Eine solche Informationsbasis beinhaltet normalerweise ein Metamodell. In Kapitel 5 finden Sie u.a. Hinweise auf Musterkataloge für Sichten und wie Sie sich anhand von Mustern ein Metamodell für eine passende Informationsbasis zusammenstellen können. So viel sei hier schon vorweg gesagt: Nicht jedes Unternehmen wird dasselbe Metamodell einsetzen. Die Menge an Informationen ist abhängig von den Zielen, die Sie mit Ihrer IT-Unternehmensarchitektur erreichen wollen. Es ist nicht immer sinnvoll, das größtmögliche Metamodell einzuführen, und es ist überhaupt nicht sinnvoll, das größtmögliche Metamodell vollständig mit Informationen zu füllen.

LeitplankenCompliance IT-Sicherheit/Cybersicherheitsarchitektur Risikomanagement

Auf dem Weg vom Ausgangszustand zum Ziel finden Sie zwei Sätze von Leitplanken: Dies sind zum einen die geschäftlichen Anforderungen des Unternehmens, zum anderen die Querschnittsanforderungen, die im Teil über ergänzende Wissensgebiete beschrieben sind. Dabei handelt es sich quasi um nicht funktionale Anforderungen wie Compliance, IT-Sicherheit und Cybersicherheitsarchitektur sowie die Ergebnisse des IT-Risikomanagements (Kap. 6 bis 8). Sowohl die funktionalen als auch die nicht funktionalen Anforderungen müssen in Ihre Lösungen einfließen.

EAM-FrameworksEAM-Tools

Weitere Hilfsmittel unterstützen Sie dabei, Ihren Weg von der Ausgangssituation zum Ziel erfolgreich zu gehen. Makro-Architekturmuster (Kap. 9) können Sie verwenden, um den Zielzustand detailliert zu beschreiben, sofern es sich um Architekturen handelt und nicht um die Veränderung von Kennzahlen (wie z. B. IT-Kosten pro Umsatz). Allgemeine Prozessmuster, wie z. B. pragmatische Vorgehensweisen (Kap. 14), helfen Ihnen, den Weg schneller zu gehen. Auch aus EAM-Frameworks (Kap. 10 und 11) und sonstigen IT-Management-Frameworks können Sie viele nützliche Anregungen ziehen, um schnell ans Ziel zu gelangen, indem Sie Dinge wiederverwenden und nicht neu erfinden müssen. Und EAM-Werkzeuge (Kap. 12) helfen Ihnen dabei, Ihre Informationsbasis zu verwalten. Wenn Sie es nur mit einer zweistelligen Anzahl von Anwendungen zu tun haben sollten, kann die Werkzeugunterstützung geringer ausfallen. Wenn Sie allerdings für ein internationales Großunternehmen tätig sind, werden Sie mit einer vierstelligen Anzahl von Applikationen rund um den Erdball zu tun haben und nicht darum herumkommen, ein umfangreicheres Werkzeug einzusetzen.

Einführungspfade

Je nachdem, welche Ziele Sie verfolgen (also mit welchen Zielmustern Sie es zu tun haben), werden Sie an unterschiedlichen Enden des Unternehmens anfangen, IT-Unternehmensarchitektur einzuführen. Kapitel 15 zu Einführungspfaden wird Ihnen Hinweise dazu geben, welche Wege zu welchen Zielkombinationen passen.

1.3Wer sollte dieses Buch lesen und warum?

Zielgruppen

Dieses Buch wendet sich primär an IT-Unternehmensarchitekten, ihre Vorgesetzten (IT-Gesamtverantwortliche, CIOs) sowie an IT-Mitarbeiter, die eine Karriere als IT-Unternehmensarchitekt ins Auge gefasst haben. Nachdem IT-Unternehmensarchitektur in Projektmodellen heute allerdings immer breiter verankert wird (die meisten Vorgehensmodelle großer Konzerne verweisen auf Checkpoints zur IT-Unternehmensarchitektur), sollten auch Projektleiter in Großunternehmen zumindest über Grundwissen zu Methoden und Vorgehensweisen der IT-Unternehmensarchitektur verfügen. Jeder, für den IT-Management einen Schwerpunkt seiner Aufgaben darstellt, sollte wenigstens in groben Umrissen wissen, wie die Kollegen »Unternehmensarchitekten« arbeiten, so wie jeder Entwickler über Grundlagenwissen zur Softwarearchitektur verfügen sollte.

Im Folgenden wird beschrieben, für welche Unternehmenstypen und für welche Leserkreise welche Kapitel besonders interessant sein können und warum.

1.3.1Eine Frage der Unternehmensgröße?

Großunternehmen

Die Methoden und Verfahren für IT-Unternehmensarchitektur haben sich Ende der 1990er- und Anfang der 2000er-Jahre in Großunternehmen für Großunternehmen entwickelt. Damals gab es zwar schon die DotCom-Blase. Erfolgreiche sogenannte »exponentielle Unternehmen«, so wie wir sie heute beispielsweise in Form von UBER oder Airbnb beobachten können, gab es damals noch nicht. Als IT-Anwenderunternehmen gab es damals neben den Großunternehmen vor allem Mittelständler. Mittelständische Unternehmen können die in diesem Buch geschilderten Methoden ebenfalls einsetzen. Viele Rollen werden dort allerdings in Personalunion ausgefüllt.

Öffentliche Verwaltung

Zunehmend werden die hier vorgestellten Vorgehensweisen auch in der öffentlichen Verwaltung verwendet – in den USA sind sie für weite Teile der öffentlichen Verwaltung sogar gesetzlich vorgeschrieben. Solche Unternehmen oder Institutionen sind gekennzeichnet durch Milliardenumsätze und/oder IT-Budgets ab einem hohen zweistelligen Millionen-Euro-Bereich. Der größte Auftraggeber für Software weltweit ist das Department of Defense mit einem dreistelligen Milliarden-US-Dollar-Volumen, das jährlich für Software ausgegeben wird. Das Department of Defense hat daher mit DoDAF (Department of Defense Architecture Framework) sogar ein eigenes sehr umfangreiches Architekturframework entwickelt. In großen Behörden sind Methoden der IT-Unternehmensarchitektur mittlerweile in unterschiedlichen Ausprägungen und flächendeckend anzutreffen. Kritisch ist jedoch gerade in der Verwaltung, dass EAM nicht zu einer formalen Übung ausarten darf. Vor allem hier kann es also sinnvoll sein, die geübte Praxis gegen die Ansätze von Lean EAM und agilem EAM zu reflektieren, die in Kapitel 13 beschrieben werden.

Mittelstand

Der Einsatz im Mittelstand unterscheidet sich vor allem durch die Personalausstattung und die Größe und Komplexität der Anwendungsportfolios. Ein CIO eines größeren mittelständischen Unternehmens ist z. B. für ein Gesamt-IT-Budget von 30 Mio. Euro oder US-Dollar verantwortlich – bei beispielsweise 2 Mrd. Euro Umsatz des von ihm mit IT betreuten Unternehmens. Davon entfällt dann ca. 1/3, also 10 Mio. Euro, auf Beschaffung und Wartung der 20 Applikationspakete, oft Standardprodukte und zunehmend auch SaaS (Software as a Service). Ein solcher CIO wird zwar »im Kopf« Methoden der IT-Unternehmensarchitektur verwenden. Er wird in der Regel aber keinen »IT-Unternehmensarchitekten« einstellen, sondern die Aufgaben entweder selbst quasi im Kopf miterledigen – oder aber er wird einen erfahrenen Lösungsarchitekten beschäftigen, der die Aufgaben der IT-Unternehmensarchitektur mit erledigt.

Start-ups

Heute gibt es auch noch die sogenannten exponentiellen Unternehmen, die dadurch charakterisiert sind, dass sie exponentiell wachsen. Unter ihnen finden sich zahlreiche »Einhörner«. Das sind Start-ups, die mit mehr als einer Milliarde Euro oder US-Dollar Unternehmenswert eingeschätzt werden. Oft betreiben solche Unternehmen zwar IT für sehr viele Benutzer – allerdings im Wesentlichen in Form einer sogenannten »One Page Application« für viele Plattformen (diverse Browser, iOS, Android). Aufgrund der hohen Benutzerzahlen benötigen solche Unternehmen zwar eine wirklich gute Lösungsarchitektur für ihre eine oder ganz wenigen Anwendungen. Sie benötigen aber in vielen Fällen keine Unternehmensarchitektur.

Zusammenfassend kann man Folgendes festhalten: In Großunternehmen wird IT-Unternehmensarchitektur nach wie vor angewendet und hat dort auch eine ähnliche Bedeutung wie vor 10–15 Jahren. Viele Mittelständler können die Methoden verwenden. Start-ups mit hohen Benutzerzahlen und wenigen IT-Anwendungen benötigen vor allem eine sehr ausgefeilte Lösungsarchitektur.

1.3.2IT-Unternehmensarchitekten

IT-Unternehmensarchitekten

Das Buch ist primär für IT-Unternehmensarchitekten geschrieben. Wenn Sie in diesem Buch direkt angesprochen werden, dann versetzen Sie sich bitte in die Rolle eines IT-Unternehmensarchitekten. Als solcher erhalten Sie Hinweise, wie Sie Ihren Job so gestalten können, dass er nicht »gefährlich« wird, sondern dass Sie darin erfolgreich werden. Sehr erfahrene IT-Unternehmensarchitekten, die den Job gut beherrschen, werden in diesem Buch lediglich die Bestätigung finden, dass sie sich im Rahmen von »Good Practices« bewegen. Dramatisch Neues werden Sie nicht lernen – eben, weil sich das Feld auch konsolidiert. Wenn Sie auf Dinge treffen, die Sie schon kennen, können Sie diese Themen ja schnell diagonal überfliegen. Unternehmensarchitekten »in Ausbildung« werden von dem Buch deutlich mehr profitieren. Als IT-Unternehmensarchitekt sollte man tendenziell den kompletten Inhalt des Buches kennen – und noch eine Menge weiterer Wissensgebiete, die meist im Buch auch referenziert werden.

Schwerpunkt IT-Management

Das Buch legt einen Schwerpunkt auf die IT-Management-Perspektive und nicht oder nur am Rande auf technische Architekturen und Lösungsarchitekturen. In den Kapiteln zu Zielmustern (Kap. 3) und Managementprozessmustern (Kap. 4) finden Sie wesentliches Managementwissen, das Sie benötigen, um die IT-Funktionen eines großen Unternehmens an den Geschäftszielen auszurichten.

Compliance IT-Sicherheit/Cybersicherheitsarchitektur Risikomanagement

Die Bereiche Compliance (Kap. 6), IT-Sicherheit und Cybersicherheitsarchitektur (Kap. 7) sowie IT-Risikomanagement (Kap. 8) sind für Sie insofern wichtig, als sie deutlich machen, dass es neben den eher funktionalen Anforderungen der Ausrichtung Ihrer IT auf den Geschäftszweck Ihres Unternehmens eine immer wichtiger werdende Menge nicht funktionaler Anforderungen gibt, die Sie nicht aus den Augen verlieren dürfen. Eine Nichtbeachtung kann schlicht dazu führen, dass Ihr Unternehmen in seiner Existenz gefährdet wird. Auch wenn Sie als IT-Unternehmensarchitekt nicht der primäre Verantwortliche z. B. für Sicherheitsfragen im Unternehmen sind, dürfen Sie trotzdem keine Architektur genehmigen, die nicht allen Sicherheitsanforderungen Ihres Unternehmens genügt. Sie benötigen daher ein ähnlich tiefes Wissen über Sicherheitsfragen wie z. B. der IT-Sicherheitsbeauftragte Ihres Unternehmens. Ähnliches gilt auch für die Themen Compliance und IT-Risikomanagement. Sie müssen in der Lage sein, in Reviews frühzeitig Verstöße gegen Gesetze zu erkennen sowie auch bei der Beurteilung Ihres bestehenden Anwendungsportfolios IT-Risiken zu sehen und sinnvoll zu erfassen.

Prozesse Frameworks Werkzeuge

Der Rest des Buches, die Blöcke über Prozesse, Frameworks und Werkzeuge, wird Ihnen viele nützliche Hinweise für Ihre Tagesarbeit geben. Makro-Architekturmuster (Kap. 9) dürften den meisten IT-Architekten schon vertraut sein. Sie werden hier trotzdem erläutert, um ihren Nutzen zu demonstrieren. In einem Kapitel über pragmatische Vorgehensweisen (Kap. 14) finden Sie nützliche Hinweise, die Ihnen die tägliche Arbeit als IT-Unternehmensarchitekt erleichtern. Zum Beispiel wird dort die Frage diskutiert, wie viel Ordnung (Homogenität) ein Unternehmen überhaupt benötigt. Es wird weiter erläutert, welche Budgetausstattung eine Stabsstelle für IT-Unternehmensarchitektur üblicherweise zur Verfügung haben sollte. Auch finden Sie in diesen Kapiteln eine Diskussion über verbreitete Architekturframeworks wie auch sonstige Frameworks, die im Kontext des IT-Managements heute verbreitet sind und die ein Unternehmensarchitekt folglich in Grundzügen kennen sollte. Früher oder später werden Sie als IT-Unternehmensarchitekt damit konfrontiert werden, ein EAM-Werkzeug aussuchen und einführen zu müssen. Hinweise hierzu enthält das Kapitel 12.

Einführungspfade

Ebenfalls häufig werden Sie mit der Frage befasst sein, wie man eine Funktion für IT-Unternehmensarchitektur im Unternehmen einführen und verankern kann. Standardpfade hierzu beschreibt Kapitel 15.

1.3.3Verantwortliche für Business Development

IT-Alignment

Auf der Geschäftsseite gibt es häufig Einheiten, die sich mit dem Finden und Umsetzen neuer Geschäftsmodelle befassen. In diesem Buch wird an mehreren Stellen deutlich, dass man massive Zeitvorteile erreichen kann, wenn man Geschäfts- und IT-Seite neuer Produkte und Services simultan plant und entwickelt. Dafür ist es sinnvoll, dass IT-Unternehmensarchitekten die Methoden und Vorgehensweisen der Kollegen kennen, die für Business Development verantwortlich sind. Umgekehrt ist es aber auch sinnvoll, wenn diese Kollegen ein Grundwissen in IT-Planung und speziell IT-Unternehmensarchitektur haben. Langfristig werden beide Kompetenzbereiche tendenziell zusammenwachsen. In fortschrittlichen Unternehmen ist dies bereits geschehen. Geschäftsarchitekten sollten daher heute schon mindestens über ein Grundwissen in IT-Unternehmensarchitektur verfügen.

1.3.4IT-Vorstände, CIOs und CDOs

IT-Verantwortliche

Als IT-Vorstand bzw. IT-Gesamtverantwortlicher gibt Ihnen dieses Buch Hinweise dazu, wie Sie IT-Unternehmensarchitektur für den eigenen Erfolg einsetzen können. Dies gilt auch für die modernere Form des sogenannten CDO (Chief Digital Officers), der digitale Geschäftsmodelle vorantreiben soll. Ein IT-Unternehmensarchitekt kann eine wesentliche Stütze für Sie sein. Um ihn auszuwählen und gut zu führen, hilft es, die Methoden und Standardaufgaben zu kennen, die er beherrschen sollte. Daher ist dieses Buch auch für IT-Vorstände nützlich.

Zielmuster Managementprozessmuster

Als IT-Gesamtverantwortlicher sind für Sie vor allem die Kapitel über Zielmuster (Kap. 3) und Managementprozessmuster (Kap. 4) von Interesse. Sie können hier zusammen mit Ihrem IT-Unternehmensarchitekten festlegen, welche Prioritäten er für seine Arbeit setzen soll. Themen wie Sichten und Informationsmodelle (Kap. 5) sind für Sie als Topmanager weniger von Interesse, weil sie das Handwerk Ihres Mitarbeiters betreffen.

Ebenso werden Sie mit Querschnittsanforderungen (Compliance, IT-Sicherheit/Cybersicherheitsarchitektur und IT-Risikomanagement) im Regelfall operativ nichts zu tun haben wollen. Sie werden diese Themen sauber delegieren und lediglich periodisch sicherstellen, dass sie ordnungsgemäß abgehandelt werden, sodass Sie im Problemfall nachweisen können, dass Sie sich mit der notwendigen Sorgfalt darum gekümmert haben. Kapitel 6 bis 8 dieses Buches bieten einen schnellen Überblick und sind als Zusammenfassungen für das Management geeignet.

Auch die Kapitel über Hilfsmittel (Kap. 9 bis 14) gehören nicht notwendigerweise zu Ihrem Aufgabengebiet als IT-Verantwortlicher. Sie werden höchstwahrscheinlich auch diese Aufgaben delegieren.

Einführungspfade

Interessant für Sie sind Überlegungen zu Einführungspfaden in Ihre IT-Unternehmensarchitektur (Kap. 15), wenn eine solche Funktion in Ihrem Unternehmen noch nicht oder noch nicht in vollem Umfang existiert und Sie eine entsprechende Stelle erst schaffen oder massiv ausbauen wollen.

1.3.5Softwarearchitekten

Softwarearchitekten

Das Erste, was Sie als Softwarearchitekt bei der Lektüre dieses Buches bemerken werden, ist, dass die Methoden, mit denen IT-Unternehmensarchitekten arbeiten, komplett andere sind als diejenigen, mit denen Sie als Lösungsarchitekt arbeiten, wenn Sie sich mit der Softwarearchitektur für ein größeres System befassen – aber eben nicht mit der Planung für 200, 1000 oder noch mehr Systeme.

Compliance

Ein von mir sehr geschätzter Kollege und erfahrener Softwarearchitekt äußerte sich mir gegenüber einmal so, dass ihn dieses »ganze BWL-Konzeptzeugs« nicht interessiere und er speziell das Kapitel 6 über Compliance extrem langweilig finde. Dazu muss man leider sagen, dass mit diesem »BWL-Konzeptzeugs« über die Zukunft ganzer Systemcluster entschieden wird, an denen jeweils auch Arbeitsplätze hängen. Wenn man also nicht eines Morgens unvorbereitet vor der Situation stehen möchte, dass das eigene System »wegrationalisiert« oder »wegkonsolidiert« wurde, ist es sinnvoll, die Methoden der Leute zu kennen, die solche Entscheidungen mit vorbereiten – also die Methoden von IT-Unternehmensarchitekten oder Unternehmensberatern. Und auch Compliance ist kein so langweiliges Thema: Wer einmal die Freude hatte, als Architekt negativ in einem Revisionsbericht erwähnt worden zu sein, der für den Vorstandsvorsitzenden des Zentralvorstands eines globalen Konzerns bestimmt war, wird das Thema nicht mehr so langweilig finden. Speziell dann, wenn der Vorstand aus dem Bericht erfahren hatte, dass er für die dort aufgelisteten Mängel persönlich haftbar gemacht werden könnte. Der entsprechende Vorstand wird Ihnen glaubhaft vermitteln können, dass Sie sich für Revisionsberichte besser interessieren sollten, wenn Sie in der Firma bleiben möchten.

IT-StrategieKollegen verstehen

Softwarearchitekten sollten ebenso wie auch IT-Unternehmensarchitekten tendenziell das ganze Buch lesen. Wissen über strategische Prozesse schadet nicht, auch wenn es nicht zu Ihrem Tagesgeschäft gehört. Es kann Ihnen auch als Softwarearchitekt, der nur für ein System eines kompletten Anwendungsportfolios verantwortlich ist, helfen, die