IT-Unternehmensarchitektur

Von der Geschäftsstrategie zur optimalen IT-Unterstützung
 
 
dpunkt (Verlag)
  • 3. Auflage
  • |
  • erschienen am 24. Mai 2017
  • |
  • 506 Seiten
 
E-Book | PDF mit Wasserzeichen-DRM | Systemvoraussetzungen
978-3-96088-133-9 (ISBN)
 
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.
überarbeitete und erweiterte Auflage
  • Deutsch
  • Heidelberg
  • |
  • Deutschland
  • 16,55 MB
978-3-96088-133-9 (9783960881339)
3960881339 (3960881339)
weitere Ausgaben werden ermittelt
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.
  • Intro
  • Vorwort zur 3. Auflage
  • Vorwort zur 2. Auflage
  • Vorwort zur 1. Auflage
  • Danksagung
  • Anhang 429
  • Inhaltsübersicht
  • Inhaltsverzeichnis
  • 1 Einleitung und Überblick
  • Abb. 1-1 Agenda eines IT-Vorstands nach [Broadbent+05]
  • 1.1 Motivation des Buches
  • Abb. 1-2 Aufgabengebiete des IT-Managements - dargestellt anhand der Gliederungen des IT Governance Institute (ITGI, links) [ITGI11] und nach Weill (rechts) [Weill+04]
  • 1.2 Struktur des Buches
  • Abb. 1-3 Kapitelstruktur des Buches
  • Abb. 1-4 Zusammenhang der Teile des Buches
  • 1.3 Wer sollte dieses Buch lesen und warum?
  • 1.3.1 Eine Frage der Unternehmensgröße?
  • 1.3.2 IT-Unternehmensarchitekten
  • 1.3.3 Verantwortliche für Business Development
  • 1.3.4 IT-Vorstände
  • 1.3.5 Softwarearchitekten
  • 1.3.6 Alle anderen IT-Mitarbeiter
  • 1.3.7 Studierende
  • 1.4 Wie können Sie dieses Buch lesen?
  • 1.5 Einige Besonderheiten
  • 1.5.1 Sprache: Deutsch
  • 1.5.2 Verwendung von Wikipedia-Definitionen
  • 1.6 Was sich seit der ersten Auflage geändert hat
  • 2 Was ist IT-Unternehmensarchitektur?
  • 2.1 Das Substantiv: Unternehmensarchitektur als Struktur
  • Definition: Enterprise Architecture
  • Abb. 2-1 Unternehmensarchitektur - Sicht aus [Engels+08] und [Kappes+09] - leicht angepasst
  • 2.1.1 Geschäftsarchitektur
  • Abb. 2-2 Bestandteile einer Geschäftsarchitektur nach [Reynolds10]
  • Abb. 2-3 Beispiel für die Kategorien eines Geschäftsmodells (aus dem Englischen übersetzt auf Basis von [Doblaski03])
  • 2.1.2 IT-Unternehmensarchitektur
  • Abb. 2-4 Beziehung von Unternehmensarchitektur und IT-Unternehmensarchitektur (analog zu [Engels+08] - leicht angepasst)
  • Abb. 2-5 Architektur-Modellpyramide nach Dern [Dern03]
  • Abb. 2-6 TOGAF Content Metamodel Overview [TOGAF9.1]
  • 2.2 Die Tätigkeit: Unternehmensarchitektur als Management
  • Abb. 2-7 Prozesslandkarte IT-Unternehmensarchitektur
  • Trennung Business/IT ist auf Dauer wenig sinnvoll
  • 2.3 Musterbasierter Ansatz für IT-Unternehmensarchitektur
  • EAM-Patternkatalog der Technischen Universität München
  • Abb. 2-8 Viewpoint-Pattern »V-6 Architectural Standard Clustering«2
  • Abb. 2-9 Information-Model- Pattern »I-6 Usage of Architectural Solutions«4
  • Konfiguration mit den Patterns des TUM-EAM-Patternkataloges
  • Anwendung der Pattern-Idee in diesem Buch
  • 3 Zielmuster
  • Abb. 3-1 Beziehungen gebräuchlicher Zielmuster in IT-Unternehmensarchitektur (IT-Management)
  • Tab. 3-1 Prioritätenliste von CIOs (Quelle: Jährliche Umfrage der Society for Information Management, 2015 wiedergegeben im Forbes Magazin1)
  • 3.1 Business-IT-Alignment
  • 3.1.1 Bedeutung
  • Tab. 3-2 Prioritäten von CIOs über mehrere Jahre (Quelle: CIO Panels der Society for Information Management 2011 - 2013)
  • 3.1.2 Dimensionen
  • 3.1.3 Zwischenbilanz
  • 3.2 Verbesserung der Ertragskraft und Kostenmanagement
  • 3.2.1 Verbesserung der Ertragskraft des Business
  • 3.2.2 Reduktion von IT-Kosten
  • Abb. 3-2 IT-Fitnessprogramm. Bei allen dunkelgrau hinterlegten Feldern spielt IT-Unternehmensarchitektur eine wesentliche Rolle.
  • 3.3 Optimierung mit Sourcing-Strategien
  • 3.4 Verbesserung Time-to-Market
  • 3.5 Verbesserung Kundenzufriedenheit
  • 3.6 Reduktion von Heterogenität
  • 3.7 Bewältigung von Fusionen
  • 3.8 Compliance, Sicherheit und Risikomanagement
  • 4 Managementprozessmuster
  • Abb. 4-1 Prozesslandkarte IT-Unternehmensarchitektur nach [Dern+08] (redundant zu Abb. 2-7 - um Ihnen als Leser mühsames Blättern zu ersparen)
  • Tab. 4-1 Zusammenhang zwischen Zielmustern und unterstützenden Managementprozessmustern
  • 4.1 IT-Strategieentwicklung
  • 4.1.1 Was ist eine Strategie?
  • Definition: Strategie
  • Definition: Strategie (Clausewitz)
  • 4.1.2 Ein kurzer Blick auf den Strategieprozess
  • Abb. 4-2 Einordnung des Maxime-Prozesses in den IT-Strategieprozess. Die Erarbeitung von Business- und IT-Maximen ermöglicht die sinnvolle Definition der IT-Governance- Strukturen und die Erarbeitung und Ausformulierung einer IT-Strategie.
  • 4.1.3 Wozu sollte eine IT-Strategie Aussagen machen?
  • Tab. 4-2 Strategieraster der Gartner Group (aus [Gartner03b] und [Gartner03c] ins Deutsche übersetzt). Die Matrix zeigt exemplarische Fragen, die man sich stellen kann, um zu einer Strategie zu kommen. In den Zeilen sind typische Dimensionen einer...
  • Abb. 4-3 Bausteine für IT-Strategie [Gartner03b]
  • 4.1.4 Herausforderungen bei der Umsetzung in der Praxis
  • Geschäftsstrategie ist nicht dokumentiert
  • Geschäftsstrategie ist nicht fokussiert
  • Geschäftsstrategie ist in sich widersprüchlich
  • Das Management kümmert sich nicht ausreichend um das Thema
  • Infrastruktur-Betriebsstrategie spielt eine Nebenrolle
  • 4.1.5 Der Maxime-Prozess
  • Beispiel für eine Geschäftsmaxime und die daraus abgeleitete IT-Maxime
  • 4.2 Business-IT-Alignment herstellen mit Capabilities
  • 4.2.1 Was sind Capabilities?
  • Definition: Capabilities
  • Definition: Capability
  • Microsoft 2006
  • Definition: Capability
  • Forrester 2009
  • Abb. 4-4 Capabilities können mit IT implementiert werden, sie lassen sich aber auch rein manuell implementieren.
  • 4.2.2 Investitionssteuerung mit Capabilities
  • Abb. 4-5 Thermografie als Beispiel für Heat Maps3
  • Abb. 4-6 Beispiel für eine Heat Map in einem Unternehmen [HeatMap06]: Hier interessiert zunächst nur der »oberflächliche optische Eindruck« - die Farbcodierung kann beliebig gewählt werden, je nachdem welche Aspekte der Geschäftsfähigkeit...
  • 4.2.3 Wie kommt man zu einem sinnvollen Katalog von Capabilities?
  • Abb. 4-7 Capability-Landkarte (oberste Ebene) [Merrifield+06]
  • Abb. 4-8 Oberste Ebene des Capability-Modells eines stark vertriebsorientierten Finanzdienstleisters4
  • Abb. 4-9 Beispiel für elementare Geschäftsfähigkeiten in Ausschnitten aus zwei verschiedenen Modellen (links bzw. rechts)
  • 4.2.4 Wie kommt man zu den Bewertungen der Capabilities?
  • Abb. 4-10 Festlegen der Bewertungsfunktionen für Heat Maps
  • 4.2.5 Zwischenbilanz: Warum helfen Capabilities bei der strategischen Ausrichtung einer Anwendungslandschaft?
  • 4.2.6 Optimierung des Sourcings einer Anwendungslandschaft mit Capabilities
  • Abb. 4-11 Zerlegen einer Anwendung in strategische und nicht strategische Teile mithilfe einer Analyse von Capabilities
  • 4.2.7 Vergleich von Anwendungen mit Footprints
  • Abb. 4-12 Bewertungen von Anwendungen mithilfe von Capabilities
  • 4.3 Management des Anwendungsportfolios
  • 4.3.1 Grundlegende Begriffe zum Management des Anwendungsportfolios
  • Definition: Portfolio
  • Definition: Anwendung (Application)
  • Unterschiede zu Finanzanlagen
  • 4.3.2 Management des Anwendungsportfolios als zyklischer Prozess
  • Abb. 4-13 Management des Anwendungsportfolios als zyklischer Prozess
  • 4.4 Erfassung der Ist-Anwendungslandschaft
  • 4.4.1 Umfang
  • 4.4.2 Typische Attribute für eine minimale Befüllung
  • 4.4.3 Erfassung von Schnittstellen: Ja oder Nein?
  • Abb. 4-14 Architekturmodelle in der IT-Unternehmensarchitektur werden meist breit (Mile Wide), aber flach (Inch Deep) angelegt. Für viele Zwecke reicht eine flache Modellierung aus. Bei konkretem Bedarf kann man die Modellierung verfeinern, wenn m...
  • 4.4.4 Key Visual für die Anwendungslandschaft
  • Abb. 4-15 Beispiel für eine komplette Bank-Anwendungslandschaft. Sie werden dieses Bild in vielen Vorträgen der Credit Suisse immer wieder in fast identischer Form vorfinden.
  • 4.4.5 Tipps und Tricks
  • 4.5 Auswertungen des Anwendungsportfolios
  • Grundmodell Marktwachstum-Marktanteil-Portfolio der BCG
  • Abb. 4-16 Beispiel für eine Marktwachstum-Marktanteil-Matrix. Die Fläche der Kreise symbolisiert den Umsatz eines Geschäftsfelds. In einer solchen Matrix kann das komplette Produktportfolio einer Firma eingetragen werden.
  • Anwendungsportfoliomanagement nach Ward/Griffiths/Peppard
  • Abb. 4-17 Boston-Square- Produktportfoliomatrix übertragen auf ein Anwendungsportfolio ([Ward+02], S. 299 ff.)
  • Bezug zum Management des Softwareentwicklungsprozesses
  • 4.6 Anwendungslandschaft, Metriken und Dashboards
  • Abb. 4-18 Beispiel für ein einfaches Dashboard7
  • 4.7 Strategische Bebauungsplanung
  • Definition: Strategische IT-Planung
  • 4.7.1 Grundsätzliches Vorgehen
  • Abb. 4-19 Workflow für die Erstellung einer strategischen Anwendungsplanung
  • 4.7.2 Erfassen der Anforderungen (Scoping)
  • 4.7.3 Analyse und Bewertung (Analysis)
  • 4.7.4 Erarbeiten der Zielbebauung
  • 4.7.5 Abstimmung (Design)
  • 4.7.6 Maßnahmenplanung (Plan Implementation)
  • 4.7.7 Zusammenfassung der strategischen Bebauungsplanung
  • 4.8 Management eines Serviceportfolios
  • Abb. 4-20 Anwendungssicht mutiert zu SOA-Sicht [Slama+11].
  • Definition: Service Portfolio Management
  • Abb. 4-21 Capabilities benötigen Prozesse. Die IT-unterstützten Prozesse benötigen IT-Support in Form von Services.
  • Abb. 4-22 SOA bildet u. a. Geschäftsprozesse auf Services ab, es besteht eine Beziehung zu Capabilities.
  • Abb. 4-23 Von der Capability über Geschäftsprozesse zum Service
  • Abb. 4-24 Service Portfolio Management benötigt u. a. auch Capability- basierte Planung, Business Process Management und SOA-Governance für ein sinnvolles Funktionieren.
  • 4.9 Managed Evolution
  • Abb. 4-25 Schrittweise Verschlechterung eines »sehr großen Softwaresystems« durch opportunistische Projekte ([Murer+11], S. 16)
  • Abb. 4-26 Vorgehen bei Managed Evolution. Projekte werden so gesteuert, dass das Gesamtsystem in einem festgelegten Zielkorridor aus Agilität und Geschäftswert bleibt. Verschlechterung wird verhindert ([Murer+11], S. 24).
  • 4.10 Etablieren eines IT-Governance-Systems
  • Definition: Governance
  • 4.10.1 Was ist IT-Governance?
  • Definition: IT-Governance (ITGI)
  • Abb. 4-27 IT-Regelkreise der Meta Group [Meta02]
  • 4.10.2 Hierarchie von Governance-Systemen
  • Abb. 4-28 Hierarchie von Governance-Systemen
  • 4.10.3 Stile von IT-Governance
  • Typen von IT-Governance
  • Tab. 4-3 Governance-Archetypen nach Weill [Weill+04]
  • Tab. 4-4 Häufigste Verteilungen der Entscheidungs- und Mitwirkungsrechte je Entscheidungsfeld eines IT-Governance-Systems [Weill+04]. Stark umrandete graue Felder sind die am häufigsten genannten Verteilungen der Entscheidungsrechte je Entscheidu...
  • 4.10.4 Hinzunahme des Unternehmenstyps
  • Reife von Industrien, Grad an Föderalismus
  • Werttreiber
  • Generische Wettbewerbsstrategien nach Porter
  • Abb. 4-29 Generische Wettbewerbsstrategien nach Porter [Porter89]
  • Einfluss der Situation Ihres Unternehmens auf die Strategie
  • Typisiert und dann? Anwendung der Merkmalsraster
  • 4.11 Architektur-Governance
  • Definition: Architektur-Governance (Architecture Governance)
  • 4.11.1 Aufbauorganisation der IT-Governance und Architektur-Governance
  • Einbettung in die Organisation des Gesamtunternehmens
  • Abb. 4-30 Exemplarische Darstellung - Einbettung einer zentralen IT in ein Unternehmen mit mehreren Geschäftseinheiten
  • Gremien
  • Abb. 4-31 Typische Berichtswege für IT-Komitee und IT-Architekturboard
  • Typische Entscheidungs- und Vorschlagsrechte
  • Tab. 4-5 Typische Verteilung von Vorschlags- und Entscheidungsrechten in einem großen IT-Anwenderunternehmen
  • Mehr zu Architekturboard und IT-Unternehmensarchitekturgruppe
  • Tab. 4-6 Typische Aufgabenverteilung für die Prozesse der IT-Unternehmensarchitektur
  • Beispielhafte Aufgaben eines Architekturboards
  • 4.11.2 Entwicklung und Durchsetzung von Richtlinien
  • Abb. 4-32 Schritte bei der Entwicklung und Durchsetzung von Richtlinien
  • Regelungsbedarf erkennen
  • Richtlinien entwerfen
  • Richtlinien abstimmen
  • Richtlinien kommunizieren und durchsetzen
  • Richtlinien aktualisieren
  • 4.11.3 Monitoring des Projektportfolios
  • Ziel des Monitorings
  • Durchführung des Monitorings
  • 4.11.4 Projektbegleitung
  • Kontinuierliche Begleitung
  • Abb. 4-33 Phasen der Projektbegleitung
  • Initiales Gespräch
  • Als Beispiel dafür, wie man Vertrauen nicht aufbauen kann, möge folgende Geschichte dienen:
  • Periodische Gespräche
  • Retrospektive
  • 4.11.5 Über Reviews im Rahmen der Projektbegleitung
  • Wie man in den Wald hineinruft, so schallt es hinaus.
  • Ziel von Reviews, Vorgehen bei Reviews
  • Der Fall des vorgeblichen »Vollidioten«:
  • Der Fall des vorgeblichen »Vollidioten« (Fortsetzung):
  • Noch zwei Tricks
  • Für Fortgeschrittene: Fly on the Wall und Writers' Workshops
  • Keine Rückdelegation zulassen
  • 4.12 SOA-Governance
  • 4.12.1 Schichten
  • Tab. 4-7 Klassifikation von SOA-Initiativen
  • Definition: SOA-Governance
  • Definition: SOA-Governance
  • 4.12.2 Operationale und technische SOA-Governance
  • 4.12.3 Business-Motivation für SOA
  • 4.13 Management von Fusionen
  • Fangen Sie überhaupt an, die Situation zu bereinigen?
  • 4.13.1 Die Leiter der Integration
  • Abb. 4-34 Die Leiter der Integration: Je weiter Sie auf dem Weg der Integration fortschreiten, desto höher werden die Stufen und desto geringer wird der relative Ertrag. Gleichzeitig steigen auch die Projektrisiken an.
  • 4.13.2 Grundmuster von Anwendungskonsolidierungen
  • Kompletter Neubau
  • Cherry Picking
  • Dampfwalze
  • Auch Zukauf kann Dampfwalze sein
  • 4.14 Reduktion von Heterogenität
  • 5 Sichten und Informationsmodelle
  • Abb. 5-1 Auf den ersten Blick erscheint die Menge verschiedener Diagramme zur Beschreibung von Anwendungslandschaften [Wittenburg07] schier unüberschaubar.
  • 5.1 Softwarekartografie als Grundlage der Systematisierung
  • Abb. 5-2 Ebenen von Karten und Softwarekarten
  • 5.2 Typen von Softwarekarten
  • 5.2.1 Clusterkarten
  • Abb. 5-3 Beispiel für eine Softwarekarte vom Typ Clusterkarte
  • 5.2.2 Prozessunterstützungskarten
  • Abb. 5-4 Beispiel für eine Softwarekarte vom Typ Prozessunterstützungskarte
  • 5.2.3 Intervallkarten
  • Abb. 5-5 Beispiel für eine Softwarekarte vom Typ Intervallkarte
  • 5.2.4 Karten ohne Kartengrund
  • Abb. 5-6 Beispiel für eine Softwarekarte ohne Kartengrund zur Verortung
  • 5.3 Viewpoints und Viewpoint-Patterns
  • 5.3.1 Viewpoints in IEEE 1471 und TOGAF
  • Abb. 5-7 Konzeptuelles Modell des IEEE 1471 [IEEE00]
  • 5.3.2 Viewpoint-Patterns
  • Abb. 5-8 Beispiel für die Anwendung des Viewpoint-Patterns V-76, Technology Usage Viewpoint.
  • Abb. 5-9 Information-Pattern I-76 »Infrastructure Usage«4
  • 5.3.3 Diskussion der Pattern-Qualität
  • 5.4 Informationsmodelle
  • 5.4.1 Das TOGAF Content Metamodel
  • Abb. 5-10 Überblick über das TOGAF Content Metamodel (Informationsmodell): vereinfachte Form von Abbildung 2-6
  • Abb. 5-11 Ausschnitt aus dem TOGAF Content Metamodel - Teil: Core Content Metamodel [TOGAF9.1]
  • 5.4.2 Hybride Wikis als Repository für IT-Unternehmensarchitektur
  • Die Grundidee der Wikis
  • Funktionsweise traditioneller Wikis
  • Abb. 5-12 Ansätze zur Generierung eines Informationsmodells
  • Abb. 5-13 Beispielhafte Struktur eines Wikis
  • Die Weiterentwicklung der traditionellen Wikis: semantische Wikis
  • Hybride Wikis vereinen die Vorteile traditioneller und semantischer Wikis
  • Abb. 5-14 User Interface des hybriden Wikis
  • Weitere Funktionalitäten hybrider Wikis
  • Abb. 5-15 Beispiel für ein Dashboard, das mit dem SocioCortex Visualizer erstellt wurde
  • Abb. 5-16 Anzeige von Typ-Inkonsistenzen in einem Wiki
  • Einsatzpotenziale für hybride Wikis im EAM
  • 6 Compliance
  • Haftungsausschluss
  • 6.1 Was ist »Compliance«?
  • Definition: Compliance
  • 6.2 IT-Compliance im Kontext von Enterprise Compliance
  • Abb. 6-1 Aufteilung von Corporate Compliance in einzelne Arbeitsgebiete [Behringer13]
  • Abb. 6-2 Compliance-Würfel für IT-Compliance ([Behringer13], S. 293)
  • 6.3 Exemplarische Compliance-Themen für die IT
  • 6.3.1 Basel II und III
  • Wo und wann gelten Basel II und III?
  • Was heißt das für IT-Unternehmensarchitekten von Banken?
  • Was bedeuten Basel II und III für IT-Manager von Kundenunternehmen?
  • 6.3.2 Solvency II
  • Wo und wann gilt Solvency II?
  • Was bedeutet Solvency II für IT-Unternehmensarchitekten von Versicherungen?
  • 6.3.3 Der Sarbanes-Oxley Act (SOX)
  • Gültigkeitsbereich
  • Wesentliche Stellen für den IT-Verantwortlichen
  • Aus Section 302
  • Aus Section 404
  • Konsequenzen der Nichtbefolgung von SOX
  • Konsequenzen für den IT-Bereich
  • SOX kann man also nicht nur als Last empfinden, sondern auch als Chance, vom Management Unterstützung dafür zu bekommen, ordentliche Arbeit machen zu dürfen.
  • Was tun kleine Firmen?
  • 6.4 KonTraG
  • 6.5 Aufbewahrungsfristen
  • 6.5.1 E-Mails sind archivierungspflichtig
  • 6.5.2 Stilllegung von DV-Systemen
  • 6.6 COBIT und Compliance
  • 6.6.1 Beispiel aus APO02 - Managen der Strategie
  • Tab. 6-1 Prozessziele des COBIT-5-Prozesses APO02 - Managen der Strategie [COBIT12b]
  • 6.6.2 Beispiel aus APO03 - Managen der Unternehmensarchitektur
  • Tab. 6-2 Prozessziele des COBIT-5-Prozesses APO03 - Managen der Unternehmensarchitektur [COBIT12b]
  • 6.7 Der Clinger-Cohen Act
  • 7 IT-Sicherheit
  • Abb. 7-1 Entwicklung von Sicherheitsrisiken (Quelle: Umfrage Corporate Trust 2014)
  • 7.1 Bedarfsgerechte Sicherheit
  • 7.2 Dimensionen von IT-Sicherheit
  • 7.2.1 Sicherheit: Security & Safety
  • 7.2.2 Grundwerte der Sicherheit
  • 7.2.3 Daten versus System/Verarbeitungslogik/Code
  • 7.2.4 Kategorien von Sicherheitsanforderungen
  • 7.2.5 Anforderungsquellen
  • 7.2.6 Technologie - Organisation - Prozesse
  • 7.2.7 Gesamtes Netzwerk
  • 7.2.8 Gehäuse, Hardware und Software
  • 7.2.9 Lebenszyklen einzelner Komponenten
  • 7.2.10 Wiederverwendung & Konfigurierbarkeit
  • 7.2.11 Betrachtung der Wertschöpfungskette
  • 7.2.12 Dienstleisterketten und Geschäftspartner, Berater
  • 7.2.13 End-to-End-Kommunikationswege
  • 7.2.14 Multinationaler Einsatz
  • 7.2.15 End-to-End in der Softwareentwicklung
  • 7.2.16 End-to-End im Betrieb
  • 7.2.17 Zwischenfazit
  • 7.3 Organisation zur IT-Sicherheit
  • 7.3.1 Sicherheit als Prozess
  • 7.3.2 Ebenen der IT-Sicherheit
  • 7.3.3 Andere Akteure der IT-Sicherheit
  • Abb. 7-2 Bedrohungen in der IT-Sicherheit (Quelle: Umfrage Corporate Trust 2014)
  • 7.3.4 Aufgaben der Unternehmensarchitektur
  • 7.4 Management der Informationssicherheit
  • Tab. 7-1 Normenserie ISO 2700x und ihre Inhalte
  • Abb. 7-3 Einordnung von Arbeitsfeldern zur Informationssicherheit [BITKOM14]
  • Vorgehen bei der Einführung eines ISMS
  • Abb. 7-4 Prozessschritte bei der Einführung eines ISMS
  • Abb. 7-5 Schematisches Beispiel für eine Risikomatrix
  • 7.5 Sicherheitsstrategie
  • 7.6 Schutzbedarfs- oder Bedrohungsanalyse
  • 7.6.1 Schutzbedarfsanalyse
  • 7.6.2 Bedrohungsanalyse
  • Tab. 7-2 Bedrohungsanalyse am Beispiel einer Bank
  • 7.7 Prävention für Forensik & Notfallprozesse
  • 7.7.1 Entdeckung von Sicherheitsvorfällen
  • Entdeckung
  • Meldung
  • Behandlung
  • 7.7.2 Technische Vorbereitungen
  • 7.7.3 Rechtliche Vorbereitungen
  • 7.7.4 Vorgehensweise bei einem IT-Sicherheitsvorfall
  • 7.7.5 Prozedur für Ersthelfer
  • 7.8 Dokumentation, Test und Verifikation
  • Abb. 7-6 Klassifizierung von Penetrationstests nach BSI
  • 7.9 Aufgaben für IT-Unternehmensarchitekten
  • Tab. 7-3 Security-Patterns
  • 7.10 Sicherheitsbebauung
  • 7.11 Typische funktionale Sicherheitsmaßnahmen
  • 7.11.1 Rollen und Rechte
  • Single Sign-on (SSO)
  • Rollenbasierter Zugriffsschutz
  • 7.11.2 Logging
  • 7.11.3 Privacy by Design, Privacy by Default
  • 7.11.4 Updates, Apps, Sandboxing
  • 7.12 Typische nicht funktionale Sicherheitsmaßnahmen
  • 7.12.1 Modellierung von Schutzzonen
  • 7.12.2 Risikobewusste Einbindung von Anwendungen in die Netzwerkinfrastruktur
  • 7.12.3 Verschlüsselung auf Applikationsebene
  • 7.12.4 Verschlüsselung auf Netzwerkebene
  • 7.12.5 Einbindung in Infrastruktur- und Betriebssicherheit
  • 7.12.6 Sicherheitsbewusstes Codedesign
  • 8 IT-Risikomanagement
  • Abb. 8-1 IT-Governance, IT-Risikomanagement, Compliance und IT-Sicherheit greifen eng ineinander.
  • Abb. 8-2 IT-Risiko tritt heute querschnittsmäßig in allen Disziplinen des Risikomanagements auf (nach [RiskIT09]).
  • 8.1 Was ist Risikomanagement?
  • Definition: Risiko
  • Abb. 8-3 Risikowürfel [COSO04]
  • 8.2 Management von Risiken mit Total Risk Profiling
  • Abb. 8-4 Vorgehen TRP-Methode [TRP10]
  • Abb. 8-5 TRP-Matrix zum Management einer Menge von Risiken (nach [TRP10])
  • 8.3 Risikoregister für Anwendungen
  • 8.4 IT-Risikomanagement-Framework Risk IT
  • Abb. 8-6 Überblick Risk IT [RiskIT09]
  • 9 Makro-Architekturmuster
  • 9.1 Blueprints und Architekturrichtlinien
  • Abb. 9-1 Blueprint aus dem 19. Jahrhundert - technischer Plan aus dem Schiffbau1
  • Definition: Blueprint
  • 9.1.1 Abstützen auf Standards
  • 9.1.2 Beschreibungsmittel
  • 9.1.3 Marchitecture: der Marketingaspekt
  • Abb. 9-2 SAP NetWeaver: Darstellung der obersten Ebene als Beispiel für eine gut eingeführte »Marchitecture«
  • 9.2 Beispiel: Facharchitektur für Versicherungen
  • 9.2.1 Beispiel zur Beschreibungstiefe einer Facharchitektur
  • Abb. 9-3 Beispiel für die Darstellung der obersten Ebene der Facharchitektur einer Versicherung. Das Bild wurde anonymisiert. Ähnliche Abbildungen in verschiedenen Versicherungen unterscheiden sich nur marginal.
  • 9.2.2 Einsatz und Nutzen einer Facharchitektur
  • 9.2.3 Abgrenzung zu Informationsarchitekturen
  • 9.2.4 Verwendung der Facharchitektur für die Bebauungsplanung
  • Abb. 9-4 Intervallkarte zu den Mandanten des Obstia- Versicherungskonzerns mit der Abdeckung des Geschäftsobjekts (Geschäftssystems) Partner durch verschiedene Standardprodukte und deren Versionen
  • 9.3 Beispiele für technische Architekturmuster
  • 9.3.1 Beispiel: SOA
  • Abb. 9-5 Vier Schichten von SOA [Slama+11]
  • SOA-Schichten
  • SOA-Komponenten
  • Abb. 9-6 Aufbau einer SOA-Service- Komponente [Slama+11]
  • Abb. 9-7 Elemente einer SOA [Slama+11]
  • 9.3.2 Beispiel: Blueprint für Internetanwendungen
  • Abb. 9-8 Blueprint für Internetanwendungen [Generali02] (Abkürzungen siehe Fußnote)4
  • 9.3.3 Beispiel: Microservices und REST
  • Abb. 9-9 Aufbrechen von Monolithen in Microservices - Abbildung angelehnt an [Fowler+14]
  • Tab. 9-1 REST-Protokoll - Tabelle angelehnt an [Pautasso09]
  • Abb. 9-10 REST-Operationen und Ressourcenprotokoll - Abbildung angelehnt an [Pautasso09]
  • 10 Frameworks für IT-Unternehmensarchitektur
  • Definition: Framework
  • Definition: Architecture Framework
  • 10.1 Ordnungsrahmen für EAM- und IT-Management-Frameworks
  • Abb. 10-1 Genealogie von EAM-Frameworks [Buckl10]
  • Abb. 10-2 Klassifizierungsraster für EAM-Frameworks nach [Rozemeijer07]
  • Abb. 10-3 Alternatives Klassifikationsschema für IT-Management- Frameworks [Schönherr04]
  • Marktanteile von EAM-Frameworks
  • Abb. 10-4 Marktanteile von EA-Frameworks - Stand 2003 [Schekkerman03]
  • 10.2 TOGAF 9.x
  • 10.2.1 Die Sicht von TOGAF 9.x auf IT-Unternehmensarchitektur
  • TOGAF as an EAM Framework (TOGAF 8.1 - Enterprise Edition)
  • Abb. 10-5 Entwicklung von TOGAF von Version 7 bis Version 9
  • 10.2.2 Der Kern von TOGAF: die »Architecture Development Method« (ADM)
  • TOGAF Teil II - Überblick über die ADM
  • Abb. 10-6 Der zyklische ADM-Prozess1
  • TOGAF Teil III - ADM Guidelines und Techniques
  • Weiteres Material, das Sie neben TOGAF lesen sollten
  • 10.2.3 Abgleich von TOGAF mit Prozessclustern der IT-Unternehmensarchitektur
  • TOGAF und IT-Strategie
  • TOGAF und Anwendungsportfoliomanagement
  • TOGAF und Management des Infrastrukturportfolios
  • Abb. 10-7 Oberste Ebene des technischen TOGAF- Referenzmodells. Dazu sind tiefere Ebenen und Taxonomien abgebildet.2
  • TOGAF und Architektur-Governance
  • Abb. 10-8 Überblick über Architektur-Governance- Anteile der Prozesslandkarte für IT-Unternehmensarchitektur
  • 10.2.4 Abdeckung weiterer Aufgabenbereiche durch TOGAF
  • TOGAF und Informationsmodelle für die IT-Unternehmensarchitektur
  • Abb. 10-9 Oberste Ebene des TOGAF Content Metamodel3
  • TOGAF und Toolunterstützung für IT-Unternehmensarchitektur
  • TOGAF und Einführungspfade für IT-Unternehmensarchitektur
  • 10.2.5 Sonstige nützliche Aspekte von TOGAF
  • Foundation Architecture/Technical Reference Model (TRM)
  • Abb. 10-10 Vereinfachte Sicht auf TOGAF TRM4
  • Das Integrated Information Infrastructure Reference Model (III-RM)
  • 10.2.6 Künftige Versionen von TOGAF
  • 10.3 Zachman-Framework
  • Tab. 10-1 Zachman-Framework6
  • Tab. 10-2 Abgleich Zachman- Framework mit Architektur-Modellpyramide (Abb. 2-5)
  • 11 IT-Management-Frameworks
  • 11.1 COBIT
  • Definition: COBIT
  • 11.1.1 Grobstruktur des COBIT-Prozessmodells
  • Tab. 11-1 Abgleich COBIT mit dem IT-Referenzorganisationsmodell (siehe Abb. 14-8)
  • Abb. 11-1 COBIT-Prozesslandkarte [COBIT12b]
  • Tab. 11-2 Prozesscluster von COBIT 5
  • 11.1.2 Nutzen von COBIT für IT-Unternehmensarchitekten
  • 11.2 ITIL
  • Was ist ITIL?
  • Abb. 11-2 Aufbau der ITIL-Dokumentation. Dieses Bild der obersten Ebene von ITIL ist in fast jeder Publikation der ITIL-Version 3 enthalten, z. B. in [ITIL11].
  • 12 Werkzeuge für Enterprise Architecture Management
  • A fool with a tool is still a fool.
  • Die Kinder des Schusters haben die zerrissensten Schuhe.
  • Weiterführendes Material
  • 12.1 Abwägungen beim Werkzeugeinsatz
  • Abb. 12-1 Typische Schnittstellen eines IPIT
  • Systeme, die zentrale Stellen zum Funktionieren erfordern, skalieren nicht.
  • Abb. 12-2 Eine Auswahl notwendiger Schnittstellen für ein IPIT, das einen weniger integrierten Funktionsumfang hat als dasjenige, das der Darstellung in Abbildung 12-1 zugrunde lag (nach [Reese10]).
  • Das Wunschbild und die derzeitige Realität
  • 12.2 Umfang eines integrierten IT-Planungswerkzeugs
  • Abb. 12-3 Funktionsblöcke der aktuellen Version (2016) des IPIT alfabet der Software AG
  • 12.2.1 Zu unterstützende Prozesse der IT-Unternehmensarchitektur
  • Abb. 12-4 Prozessmodell
  • Unterstützung: Strategie ableiten und verfolgen
  • Unterstützung: IT-Anwendungsportfoliomanagement
  • Wo werden technologische Blueprints abgelegt?
  • Unterstützung: Modellierung
  • Unterstützung: Entwicklung und Durchsetzung von Richtlinien
  • Unterstützung: Monitoring des Projektportfolios
  • Unterstützung: Projektbegleitung
  • 12.2.2 Sonstige Prozesse des IT-Managements
  • Unterstützung: Anforderungsmanagement
  • Unterstützung: Projektportfoliomanagement
  • Unterstützung: IT-Asset-Management (CMDB)
  • 12.2.3 Schnittstellen eines IPIT zu anderen Arten von Werkzeugen
  • Schnittstelle zum ERP-System des Gesamtunternehmens
  • Schnittstellen zum IT-Asset-Management und zur Configuration Management Database
  • Schnittstelle ITIL-Unterstützungssysteme (Incident, Problem)
  • 12.2.4 Weitere funktionale Anforderungen an IPITs
  • Unterstützung: Synchronisationsmanagement
  • Unterstützung: Management von Softwareservices (SOA)
  • 12.2.5 Nicht funktionale Anforderungen an IPITs
  • Anforderung: Prozessunterstützung
  • Anforderung: Konfigurierbarkeit des Metamodells
  • Anforderung: Abdeckung bekannter Frameworks durch das ausgelieferte Metamodell
  • Anforderung: Reichhaltigkeit unterstützter Visualisierungsarten, Flexibilität der Visualisierung
  • Anforderung: Flexibilität der Reporting-Funktionen
  • Anforderung: Unterstützung für die Zusammenarbeit mehrerer Benutzer (Usability)
  • Anforderung: Unterstützung für Import und Export von Daten
  • 12.3 Möglicher Umfang von Planungswerkzeugen
  • 12.3.1 Werkzeuge mit maximalem Umfang: das umfassende Informationssystem für die IT-Funktion?
  • 12.3.2 Werkzeuge mit realistischem Funktionsumfang: IPIT
  • 12.3.3 Werkzeuge mit mittlerem Funktionsumfang: Aufsätze auf bestehenden Lösungen
  • Ergänzungen zu BPM-Werkzeugen
  • Ergänzungen zu UML-Werkzeugen
  • 12.3.4 Werkzeuge mit geringem Funktionsumfang: Ad-hoc-Werkzeuge nur für Bebauungsplanung
  • 12.4 Herkunft der Werkzeuge
  • Werkzeuge für Balanced Scorecards
  • Metaeditor-Werkzeuge
  • BPM-Werkzeuge
  • Hersteller von Systemverwaltungssoftware
  • Hybride Wikis
  • 12.5 Marktsituation
  • 13 Lean und Agile EAM
  • Agile Architektur ist diejenige Software- und IT-Unternehmensarchitektur, die es einem Unternehmen ermöglicht, sich schnell und flexibel - also agil - an sich ändernde Marktbedingungen anzupassen [Bloomberg13].
  • 13.1 Lean und IT-Unternehmensarchitektur
  • 13.1.1 Lean-Prinzipien
  • Tab. 13-1 Abgleich der Lean-Begriffe verschiedener Autoren
  • 13.1.2 Lean auf Prozesse der IT-Unternehmensarchitektur anwenden
  • 13.2 Die Tätigkeit: agile Praktiken auf EAM-Prozesse anwenden
  • 13.2.1 Agiles Manifest und agile Prinzipien
  • Abb. 13-1 Das Agile Manifest1
  • Abb. 13-2 Die Prinzipien der agilen Softwareentwicklung2
  • 13.2.2 Abgleich Lean und Agile
  • Abb. 13-3 Abgleich Lean versus Agile auf hoher Ebene (Quelle: [Komus+14])
  • Tab. 13-2 Abgleich Lean und Agile - Idee aus [Komus+14]
  • 13.3 Das Substantiv: agile Softwarearchitektur
  • Abb. 13-4 Vertikale Services liefern fachliche Bausteine an eine Oberfläche.
  • 14 Pragmatische Vorgehensweisen
  • 14.1 Angemessenes Budget für IT-Unternehmensarchitektur
  • 14.1.1 Zahlt sich IT-Unternehmensarchitektur aus?
  • Architecture is free!
  • Architecture is free
  • Architecture is free
  • Die Kinder des Schusters haben die schlechtesten Schuhe
  • Leerkapazitäten
  • Business Continuity Management
  • Langfristige Einsparungen durch Portfoliomanagement
  • Geht es nicht schneller?
  • Professionalisierung ist zu erwarten
  • 14.1.2 Wie groß sollte eine Architekturgruppe sein?
  • Einfluss der Fertigungstiefe
  • Anzahl der Projektarchitekten
  • 14.2 Wie viel Ordnung muss sein?
  • 14.2.1 Wie sorgt man für die Reduktion von Komplexität?
  • 14.2.2 Wie viel Ordnung ist gut? Gibt es zu viel Ordnung?
  • Städte, die leblos wirken
  • Abb. 14-1 Modell von Germania, der geplanten Hauptstadt des Dritten Reiches, die zum Glück nie gebaut wurde, als Beispiel für eine »von oben nach unten« geplante Architektur mit dem klar formulierten Ziel, Macht auszudrücken.
  • Abb. 14-2 München-Westkreuz als Beispiel für ein totes Stadtviertel, das am Reißbrett geplant wurde. Trotz Modernität und besserer Infrastruktur als in manchem gewachsenen Kiez wirkt das Viertel tot.
  • Abb. 14-3 Ein »lebendiges« Stadtviertel - Berlin-Charlottenburg, Dankelmannstraße. Ein gewachsenes Stadtviertel, das nicht am Reißbrett geplant wurde, sondern über mehrere Jahrzehnte entstanden ist.
  • Christopher Alexander und die rekursive Nutzung von Mustern
  • Abb. 14-4 Kaukasischer Teppich (Quelle: wikimedia - public domain). Der Raum wird durch Zentren in Unterräume geteilt.
  • Abb. 14-5 Muster dafür, wie Alexander Stadtarchitektur beschreibt. Hier wird z. B. das Konzept einer von Fußgängern zu benutzenden Straße beschrieben. Man beachte, dass die anderen Entwurfsmuster rekursiv verwendet werden, um das hier vorgestel...
  • Entwicklungsplanung
  • Abb. 14-6 Beispiel für einen Bauleitplan der Stadt Wien3
  • 14.3 Gefahren für Unternehmensarchitekten
  • 14.3.1 Exkurs: Organisationsmuster für die IT-Funktion
  • Klassische Organisation (Typ A)
  • Abb. 14-7 Klassische Organisation großer IT-Abteilungen, wie man sie heute noch finden kann. Dieses Muster für Organisationscharts befindet sich allerdings auf dem Rückzug.
  • Modernere Organisationsform (M/C/R) (Typ B)
  • Abb. 14-8 Aufteilung der IT-Funktion in Manage/Change/Run
  • DevOps (Typ C)
  • Abgleich Typ A versus Typ B aus Sicht von Unternehmensarchitektur
  • 14.3.2 Auf die Beschaffungsseite fixierter IT-Vorstand
  • 14.3.3 Organigramm alten Stils
  • 14.3.4 Hierarchiedenken
  • 14.3.5 Chicken Race
  • 14.3.6 Mangelnde Offenheit
  • 14.3.7 Verzetteln: keine klare Strategie
  • 14.3.8 Inkonsequenz
  • 14.4 Zusammenarbeit mit Lösungsarchitekten
  • 14.4.1 Warum macht der IT-Unternehmensarchitekt nicht meine Projektarchitektur?
  • Ihre eigentlichen Aufgaben bleiben liegen
  • Sie fördern Rückdelegation von Verantwortung
  • Nicht abheben
  • Abgrenzungsregeln, die sich bewährt haben
  • 14.4.2 Das Kostendilemma der Wiederverwendung
  • 14.5 Tipps und Tricks
  • 14.5.1 Architekturtickets
  • 14.5.2 Radar-Chart-Methode
  • Abb. 14-9 Beispiel für eine qualitative Skala
  • Abb. 14-10 Beispiel für ein Radar-Chart für die Größen, die in einem Architekturmanagement als diejenigen erkannt werden, die gesteuert werden müssen. An den Ringen kann man recht schnell die geplanten Fortschritte erkennen. Dazu muss es logis...
  • 14.5.3 Chefmanagement
  • Abb. 14-11 Matrix zur Klassifikation unangenehmer Situationen im Chefmanagement (adaptiert nach [Welch+05], S. 329)
  • 15 Einführungspfade für IT-Unternehmensarchitektur
  • 15.1 IT-Unternehmensarchitektur für Großunternehmen
  • 15.2 Einführungspfade für IT-Unternehmensarchitektur mit und ohne Topmanagement-Unterstützung
  • Abb. 15-1 In Anlehnung an bekannte und eher leicht witzig gemeinte »Problem-Charts« zeigt diese Abbildung, worauf es bei der Maßnahmenplanung für IT-Unternehmensarchitektur ankommt.
  • Weg 1: Von oben nach unten
  • Abb. 15-2 Einführungsstrategie »von oben nach unten«
  • Weg 2: Von unten nach oben
  • Abb. 15-3 Einführungsstrategie »von unten nach oben«
  • 15.3 Wege in Konzernen mit dezentralen IT-Einheiten
  • Abb. 15-4 Unternehmensgruppe mit mehreren Geschäftseinheiten und jeweils dezentralen IT-Funktionen. Über die Stärke der Zentralfunktionen ist hier noch keine Aussage getroffen.
  • Weg 1: Von oben nach unten
  • Abb. 15-5 Einführung von oben nach unten über die Zentrale
  • Weg 2: Pilotanwendungen
  • Abb. 15-6 Einführung über ein Pilotprojekt
  • Abb. 15-7 Erfolgsaussichten verschiedener Einführungswege von IT-Unternehmensarchitektur - gilt auch für unterstützende Werkzeuge.
  • 16 Ausblick
  • IT-Unternehmensarchitektur hat sich ausgebreitet und wird zur reifen Disziplin
  • Bezüglich Business-IT-Alignment gibt es nach wie vor Verbesserungspotenzial
  • Abb. 16-1 Steigender Nutzen verschiedener Herangehensweisen an das Thema IT-Unternehmensarchitektur
  • IT-Unternehmensarchitektur und Business-Architektur werden weiter zusammenwachsen
  • IT-Unternehmensarchitektur rechnet sich schon bei geringerem Anspruch
  • Modellierung ist nicht die Hauptsache
  • Compliance, IT-Sicherheit, IT-Risikomanagement und IT-Governance werden weiter als Themen »wachsen«
  • Ausreichendes Rüstzeug ist vorhanden
  • Zu »Architektur« gibt es keine wirklichen Alternativen mehr
  • Architecture is free!
  • Für sehr große Systeme ist architekturgetriebene, kontrollierte Weiterentwicklung (Managed Evolution) der einzig sinnvolle Weg, um die Kontrolle über die IT zu behalten und als Unternehmen handlungsfähig zu bleiben.
  • Anhang
  • A Checkliste für Richtlinien, Vorstudien und Architekturdokumente
  • A.1 Wer kann diese Checkliste verwenden und warum?
  • A.2 Zu Beginn
  • A.2.1 Reviewen ist eine Dienstleistung für den Autor
  • A.2.2 Schreiben ist eine Dienstleistung für den Leser
  • A.3 Kontrollfragen
  • A.3.1 Kontrollfragen zur Geschichte, die das Dokument wiedergibt
  • A.3.2 Formalia
  • B Textauszüge
  • B.1 Auszug SOX Sections 302 und 404
  • SEC. 302. CORPORATE RESPONSIBILITY FOR FINANCIAL REPORTS.
  • SEC. 404. MANAGEMENT ASSESSMENT OF INTERNAL CONTROLS.
  • B.2 Auszug AO (Abgabenordnung)
  • AO 1977 § 147 Ordnungsvorschriften für die Aufbewahrung von Unterlagen
  • C Abkürzungsverzeichnis
  • Abkürzung
  • Bedeutung
  • D Glossar
  • Begriff
  • Bedeutung
  • E Literatur
  • Unbenannt

Dateiformat: PDF
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie zum Lesen die kostenlose Software Adobe Reader, Adobe Digital Editions oder einen anderen PDF-Viewer Ihrer Wahl (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie die kostenlose App Adobe Digital Editions oder eine andere Lese-App für E-Books (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nur bedingt: Kindle)

Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Download (sofort verfügbar)

39,99 €
inkl. 19% MwSt.
Download / Einzel-Lizenz
PDF mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
E-Book bestellen

Unsere Web-Seiten verwenden Cookies. Mit der Nutzung dieser Web-Seiten erklären Sie sich damit einverstanden. Mehr Informationen finden Sie in unserem Datenschutzhinweis. Ok