IT-Unternehmensarchitektur E-Book

Wolfgang Keller

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

Seitenzahl: 641

Beschreibung

Gegenstand von IT-Unternehmensarchitektur ist es, ein Portfolio an Software und IT-Infrastruktur so auszurichten, dass daraus ein optimaler Nutzen für das anwendende Unternehmen entsteht. Durch den musterbasierten Ansatz, den dieses Buch verfolgt, ist es möglich, die IT-Unternehmensarchitektur für die Einsatzziele des Unternehmens zielgenau zu konfigurieren. Der Leser erfährt, welche Zielmuster durch welche Managementprozessmuster unterstützt werden und wie er daraus die erforderliche Datenbasis ableiten kann, um Architekturaktivitäten zu nterstützen. Die Kernprozesse der IT-Unternehmensarchitektur – wie das Erarbeiten der IT-Strategie, das IT-Portfoliomanagement, die strategische IT-Planung, das Monitoring des Projektportfolios sowie die Projektbegleitung – können so an den Bedarf des Unternehmens angepasst werden. Darüber hinaus vermittelt das Buch notwendige Grundlagen zu den im Unternehmensumfeld wichtigen Themen Compliance, IT-Sicherheit und IT-Risikomanagement. Dabei werden Frameworks für das IT-Management wie TOGAF oder COBIT vorgestellt. Im Anhang finden sich u.a. Checklisten für Richtlinien und Architekturdokumente sowie ein Glossar. Das Buch bietet somit viele in der Praxis anwendbare Hinweise und zeigt IT-Verantwortlichen, wie sie IT-Unternehmensarchitektur für die Erreichung ihrer Ziele einsetzen können. Die 3. Auflage wurde komplett überarbeitet und um Themen wie Lean EAM und Agile EAM sowie EAM für den Mittelstand erweitert. Auch neue technologische Trends wie Cloud Computing und Microservice-Architektur wurden aufgenommen.

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 mehr als 20 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«, ebenfalls erschienen im dpunkt.verlag.

Website:www.objectarchitects.bizE-Mail:[email protected]

1. VAA steht für Versicherungs-Anwendungs-Architektur, eine Initiative des Gesamtverbandes der Deutschen Versicherungswirtschaft (GDV), siehe http://www.gdv-online.de/vaa.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.de/plus

Wolfgang Keller

IT-Unternehmensarchitektur

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

3., überarbeitete und erweiterte Auflage

Wolfgang Keller

[email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenberg

Herstellung: Birgit Bäuerlein

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Fachliche Beratung und Herausgabe von dpunkt.büchern im Bereich Wirtschaftsinformatik: Prof. Dr. Heidi Heilmann · [email protected]

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:

Print978-3-86490-406-6

PDF978-3-96088-133-9

ePub978-3-96088-134-6

mobi978-3-96088-135-3

3., überarbeitete und erweiterte Auflage

Copyright © 2017 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

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.

5 4 3 2 1 0

Für meine Familie: Gabriele, Ilka und Arved

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 Wertbeitrages 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 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 2016Wolfgang 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 Open Group 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 2011Wolfgang 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 unter anderem mit IT-Governance beschäftigt. Es gibt heute noch eine Mehrheit von Unternehmen mit deutlich mehr als drei 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 2006Wolfgang Keller

1. Der Begriff IT-Vorstand wird in diesem Buch durchgehend für den IT-Verantwortlichen eines Unternehmens oder einer Unternehmensgruppe verwendet. Der Begriff steht hier für den engl. Begriff CIO (Chief Information Officer). Auch der Geschäftsführer eines ausgegründeten IT-Dienstleisters, der nicht den Titel Vorstand trägt, wird hier in diesem Buch unter dem Begriff »IT-Vorstand« subsumiert.

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 unter anderem 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.

Dadurch ergab sich für mich die Chance, die Themen 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 10 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, 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 IT-Sicherheit. 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 ist.

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 dritte Auflage haben mir einige Kollegen besonders geholfen, schnell wieder auf den neuesten Stand zu kommen. Zu erwähnen sind hier vor allem Herr Dr. Ulrich Kalex von alfabet/Software AG und Herr Rolf Knoll von der NovaTec Consulting GmbH, der mir noch in seiner alten Funktion bei der Firma Syracom Zugang zu einer aktuellen EAM-Tools-Vergleichsstudie gewährt hat. Diese Studie wird in Zukunft von NovaTec und Syracom gemeinsam weitergeführt werden.

Zum dritten 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!

Weiter gilt mein Dank allen Kolleginnen und Kollegen, die die 3. Auflage dieses Buches oder einzelne Kapitel als Reviewer durchgesehen haben und denen ich viele wertvolle Hinweise verdanke. In alphabetischer Reihenfolge waren dies: Prof. Dr. Stefan Bente, Olaf Boczan, Dr. Peter Brössler, Nadin Ebel, Markus Gaulke und Mahbouba Gharbi. Vielen Dank!

Inhaltsübersicht

1Einleitung und Überblick

2Was ist IT-Unternehmensarchitektur?

3Zielmuster

4Managementprozessmuster

5Sichten und Informationsmodelle

6Compliance

7IT-Sicherheit

Von Florian Oelmaier

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

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.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.4Herausforderungen bei der Umsetzung in der Praxis

4.1.5Der 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.4Key Visual 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

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 IEEE 1471 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

Von Gloria Bondel und Prof. Dr. Florian Matthes

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 und III

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

7IT-Sicherheit

Von Florian Oelmaier

7.1Bedarfsgerechte Sicherheit

7.2Dimensionen von IT-Sicherheit

7.2.1Sicherheit: Security & Safety

7.2.2Grundwerte der Sicherheit

7.2.3Daten versus System/Verarbeitungslogik/Code

7.2.4Kategorien von Sicherheitsanforderungen

7.2.5Anforderungsquellen

7.2.6Technologie – Organisation – Prozesse

7.2.7Gesamtes Netzwerk

7.2.8Gehäuse, Hardware und Software

7.2.9Lebenszyklen einzelner Komponenten

7.2.10Wiederverwendung & Konfigurierbarkeit

7.2.11Betrachtung der Wertschöpfungskette

7.2.12Dienstleisterketten und Geschäftspartner, Berater

7.2.13End-to-End-Kommunikationswege

7.2.14Multinationaler Einsatz

7.2.15End-to-End in der Softwareentwicklung

7.2.16End-to-End im Betrieb

7.2.17Zwischenfazit

7.3Organisation zur IT-Sicherheit

7.3.1Sicherheit als Prozess

7.3.2Ebenen der IT-Sicherheit

7.3.3Andere Akteure der IT-Sicherheit

7.3.4Aufgaben der Unternehmensarchitektur

7.4Management der Informationssicherheit

7.5Sicherheitsstrategie

7.6Schutzbedarfs- oder Bedrohungsanalyse

7.6.1Schutzbedarfsanalyse

7.6.2Bedrohungsanalyse

7.7Prävention für Forensik & Notfallprozesse

7.7.1Entdeckung von Sicherheitsvorfällen

7.7.2Technische Vorbereitungen

7.7.3Rechtliche Vorbereitungen

7.7.4Vorgehensweise bei einem IT-Sicherheitsvorfall

7.7.5Prozedur für Ersthelfer

7.8Dokumentation, Test und Verifikation

7.9Aufgaben für IT-Unternehmensarchitekten

7.10Sicherheitsbebauung

7.11Typische funktionale Sicherheitsmaßnahmen

7.11.1Rollen und Rechte

7.11.2Logging

7.11.3Privacy by Design, Privacy by Default

7.11.4Updates, Apps, Sandboxing

7.12Typische nicht funktionale Sicherheitsmaßnahmen

7.12.1Modellierung von Schutzzonen

7.12.2Risikobewusste Einbindung von Anwendungen in die Netzwerkinfrastruktur

7.12.3Verschlüsselung auf Applikationsebene

7.12.4Verschlüsselung auf Netzwerkebene

7.12.5Einbindung in Infrastruktur- und Betriebssicherheit

7.12.6Sicherheitsbewusstes Codedesign

8IT-Risikomanagement

8.1Was ist Risikomanagement?

8.2Management von Risiken mit Total Risk Profiling

8.3Risikoregister für Anwendungen

8.4IT-Risikomanagement-Framework Risk IT

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

Von Dirk Slama und Ralph Nelius

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 9.x

10.2.1Die Sicht von TOGAF 9.x 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

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. 2006 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 Compliance (das Einhalten von Gesetzen), eine wesentlich gesteigerte Sensibilität für IT-Sicherheit und 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 das meiste 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 15–20 Jahren weit verbreitet war, deutlich unterscheiden. IT-Management benötigt heute auch fortgeschrittenere Methoden als beim Erscheinen der ersten Auflage dieses Buches vor zehn 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.

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 komplett 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 das Thema »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-Programm-management

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+12]) 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).

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.

Zielmuster

Managementprozessmuster

Informationsmodelle

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 2. 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 3. 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 stellen 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 (Kap. 7) und 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 fünf Jahren seit der letzten 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 Information zu füllen.

Leitplanken

Compliance IT-Sicherheit 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 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-Frameworks

EAM-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, der IT-Management als einen Schwerpunkt seiner Aufgaben hat, 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 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-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 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 5–10 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 Risikomanagement

Die Bereiche Compliance (Kap. 6), IT-Sicherheit (Kap. 7) und 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 konfrontiert 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

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. 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 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 im 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 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-Strategie

Kollegen 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 Methoden und Arbeitsweisen der Kollegen zu kennen, die Ihr Projekt auf Verträglichkeit mit den Unternehmensrichtlinien überprüfen. Ihnen ist dann die Motivation der Kollegen bekannt, Sie wissen, mit welchen Mitteln sie arbeiten, was sie im Sinne des Gesamtunternehmens akzeptieren dürfen und was nicht. Und Sie erkennen auch, warum diese Kollegen nicht dafür verantwortlich sind, sozusagen als »Überarchitekten« Ihren Job zu machen. Mancher Softwarearchitekt wird sich auch später in einer IT-Unternehmensarchitekturfunktion wiederfinden. Es ist dann gut, vorher zu wissen, dass die Aufgaben und Erfolgsfaktoren komplett verschieden sind, auch wenn es reichlich Schnittstellen und Berührungspunkte zwischen IT-Unternehmensarchitektur und Projektarchitektur gibt.

1.3.6Alle anderen IT-Mitarbeiter

IT-Mitarbeiter

Alle anderen Mitarbeiter der IT-Funktionen von Anwenderunternehmen können von diesem Buch profitieren, weil es hilfreich ist, zu erfahren, wie eine IT-Funktion langfristig von der Geschäftsseite gesehen wird. Man lernt dann zu verstehen, warum über Outsourcing nachgedacht wird, welche Antriebskräfte einen IT-Vorstand zu gewissen Handlungen veranlassen und in welcher Art Unternehmen oder Unternehmenskultur man sich befindet.

Wenn man die vierte Gruppe »alle anderen IT-Mitarbeiter« außen vor lässt, dann können ca. 10–15 Prozent des IT-Personals von diesem Buch unmittelbar profitieren. In etwa so hoch ist der Anteil von Unternehmens- und Projektarchitekturfunktionen am gesamten IT-Personal. Die Tendenz ist steigend, weil mit wachsendem Anteil an Outsourcing und Standardsoftware (abnehmender Wertschöpfungstiefe) der Anteil der Planungsaufgaben gegenüber reinen Implementierungstätigkeiten zunimmt.

1.3.7Studierende

Einsatz an Hochschulen

Die erste und zweite Auflage des Buches wurden bereits erfolgreich als Grundlage für Lehrveranstaltungen zu EAM oder IT-Management an verschiedenen Hochschulen eingesetzt. Auch der Autor hat basierend auf seinem Buch insgesamt vier Lehrveranstaltungen im Masterstudium des Hasso-Plattner-Instituts der Universität Potsdam durchgeführt.

1.4Wie können Sie dieses Buch lesen?

IT-Profis

Dieses Buch ist primär für berufserfahrene IT-Profis geschrieben. Es kann jedoch auch von Berufsanfängern gelesen werden. Auf diese wird allerdings bei der Didaktik nicht immer die maximale Rücksicht genommen, da im Sinne des guten Leseflusses die für Profis in der IT allgemein bekannten Basisbegriffe nicht ausführlich definiert werden. Dies geschieht eher kurz in Form von Fußnoten mit weiterführenden Literaturhinweisen. Dieses Buch hat den Anspruch, dass jedes Kapitel sinnvoll für sich allein gelesen werden kann, damit Sie als Leser die Aspekte herausgreifen können, die für Sie neu und interessant sind. Es ist also so geschrieben, dass man einzelne Kapitel detailliert, andere nur diagonal liest und das Buch dann später zum Nachschlagen wieder »herausziehen« kann.

1.5Einige Besonderheiten

Sprache

Wenn man ein Buch wie dieses schreibt, denkt man länger darüber nach, ob man es in Deutsch oder »gleich« in Englisch schreiben soll. Englisch hat den Vorteil, dass viele bekannte Begriffe nicht übersetzt werden müssen, dass »denglische« Texte vermieden und potenziell ein größerer Leserkreis erreicht werden kann.

1.5.1Sprache: Deutsch

Deutsch hat den Vorteil, dass Leser, die mit der englischen Fachsprache nicht so vertraut sind, das Buch schneller durchlesen können. Ich habe mich also im Sinne der Leser für Deutsch entschieden. Das hat allerdings auch Nachteile, z. B. dass man dabei mit Wortmonstern hantieren muss, die man eigentlich im Sinne eines flüssigen Schreibstils gerne vermeiden würde. Es reicht in diesem Buch beispielsweise nicht aus, einfach »Architektur« zu schreiben, weil in der deutschen Fachsprache im Gegensatz zur englischen zwischen Begriffen wie IT-Architektur, IT-Unternehmensarchitektur oder Geschäftsarchitektur zu unterscheiden ist.

Wenn Sie aus der Beraterwelt vertraute Begriffe wie CIO, CFO, CxO, C-Level-Officer, Challenge, Cost Cutting und ähnliche manchmal etwas sparsam eingesetzt sehen, hat das nichts damit zu tun, dass der Autor sie nicht auch beherrscht – sie wurden nur bewusst reduziert verwendet, um das Buch nicht mit englischen Akronymen zu überladen.

1.5.2Verwendung von Wikipedia-Definitionen

Definitionen

Ein weiteres Thema ist der Umgang mit Definitionen. Das Buch enthält mehrere Definitionen aus Wikipedia. Über den Ruf von Wikipedia kann man sicher diskutieren, im Falle der Auswahl der Begriffe in diesem Buch waren diese Definitionen jedoch oftmals die instruktivsten. So erschien es sinnvoller, sie zu verwenden, als sie mit Gewalt durch andere, unverständlichere zu ersetzen. Die Wikipedia-Definitionen wurden gründlich plausibilisiert und auch nur dann verwendet, wenn keine andere gut erreichbare Quelle zur Verfügung stand.

1.6Was sich seit der ersten Auflage geändert hat

Die erste Auflage dieses Buches repräsentierte den Kenntnisstand der IT-Unternehmensarchitektur von 2006.

Musterbasierter Ansatz

Seit damals hat nicht nur die Bedeutung und Verbreitung des Themas IT-Unternehmensarchitektur stark zugenommen. Durch Forschungsarbeiten hat sich auch der Blick auf die Systematik und das Raster geändert, mit dem das Gebiet heute (2016) dargestellt werden kann. Dies hatte starke Auswirkungen auf die Struktur und den Umfang der zweiten Auflage, die 2011 entstand. Zwischen 2011 und 2016 hat sich im Kernfeld der IT-Unternehmensarchitektur nicht dramatisch viel verändert. Verändert hat sich vor allem, dass nun auch auf der Geschäftsseite etwas entsteht, was als »Enterprise Business Architecture« [Sensler+15] bezeichnet wird, und dass es mit exponentiellen Unternehmen einen neuen Typus sehr teurer Unternehmen mit sehr vielen Benutzern gibt, die interessant zu betrachten sind [Ismail+14].

Ordnungsprinzip Muster

Als grundlegendes Ordnungsprinzip wird seit der zweiten Auflage nicht mehr nur die Prozesslandkarte für Architekturmanagement verwendet, die in einer früheren Form der ersten Auflage zugrunde lag. Es wird stattdessen eine eher modulare und auf Mustern basierende Herangehensweise an das Thema gewählt (zur Erläuterung siehe Abschnitt 2.3). Sie beruht auf Forschungsarbeiten der Technischen Universität München zu EAM-Patterns. Dieser musterbasierte Ansatz ist zu der ursprünglichen Darstellung einer Prozesslandkarte hinzugekommen und erlaubt ein feineres Anpassen einer IT-Unternehmensarchitekturfunktion an die Ziele des jeweiligen Unternehmens. Die in den letzten fünf Jahren aufgetauchten Variationen Lean EAM und Agile EAM sind damit ebenfalls gut verträglich (siehe dazu Kap. 13).

Als IT-Unternehmensarchitekt haben Sie es somit einfacher, sich die Aspekte herauszusuchen, die Sie genau in Ihrem Unternehmen für die Ziele Ihrer IT-Funktion benötigen. Dieses Vorgehen spiegelt sich wider in den Kapiteln über Zielmuster (Kap. 3), Managementprozessmuster (Kap. 4) sowie Sichten und Informationsmodelle (Kap. 5). An Prozessmustern ist vor allem das Management von Business-IT-Alignment mit Capabilities (Abschnitt 4.2) vergleichsweise neueren Datums.

SOA

In den letzten Jahren ist ferner die SOA-Welle über die Unternehmen geschwappt: Manche mögen sagen, dass SOA tot sei. Tatsache ist jedoch, dass gerade große Unternehmen heute ein Service Portfolio Management (Abschnitt 4.8) betreiben und dies nicht im Sinne von ITIL, sondern in Form von SOA-Diensten, die analog zu Anwendungsportfolios gemanagt werden müssen. Hier gibt es auch Querbezüge zum Management von Geschäftsprozessen und auch zu den moderneren Ausprägungen von serviceorientierten Architekturen, die in Abschnitt 13.3 beschrieben sind.

Governance

Daraus entstehen Managementprozessmuster genauso wie SOA-Governance (Abschnitt 4.12), eine spezialisierte Form der Architektur-Governance.

Compliance

Der Compliance-Druck auf Unternehmen steigt immer weiter. Das Buch trägt dem dadurch Rechnung, dass dieser Aspekt immer wieder betont wird. In Kapitel 6