Fragen, die in diesem Kapitel beantwortet werden:
Wie kann ein Ordnungsrahmen für die Realisierung von Enterprise Architecture Management (kurz EAM) aussehen und welche Domänen sind dabei zu unterscheiden?
Was sind die wesentlichen Zielsetzungen für das Architekturmanagement und welche Architekturprinzipien können bei der Umsetzung eines Zielkatalogs zu berücksichtigen sein?
Wie lassen sich Enterprise-IT-Architekturen in den verschiedenen Domänen (Business, Applikationen, Data, Plattformen, Infrastrukturen) beschreiben/abbilden und auch in vernetzter bzw. integrierter Form dokumentieren?
Welche Regelungen gelten für den Aufbau eines EA-Metamodells und wie lassen sich daraufhin Managementsysteme für das Architekturmanagement konfigurieren?
Was sind typische Planungsaktivitäten zu den Enterprise- bzw. IT-Architekturen, die in der Unternehmenspraxis verbreitet sind und einen Beitrag zum Unternehmenserfolg leisten?
Welche EA-Projekte bzw. EA-Use-Cases versprechen einen hohen Mehrwert für den Business- und IT-Bereich eines Unternehmens?
Welche Instrumente zur Planung, Bewertung und Steuerung von Unternehmens-IT-Architekturen haben sich bewährt?
Welche Aufgaben der EA-Governance werden unterschieden und organisatorisch verankert?
Wie kann eine Einführung von EAM bzw. der Ausbau von vorhandenen EAM-Lösungen erfolgreich realisiert werden?
Welche Organisationsstrukturen und Prozesse sind für die Einführung von Architekturmanagement in der Unternehmenspraxis zu etablieren?
Welche Einsatzmöglichkeiten bietet das Framework TOGAF zur Unterstützung von Aufgaben im Unternehmens-IT-Architekturmanagement?
Welchen Nutzen und welche Anwendungsmöglichkeiten bietet ein professionelles Management der Unternehmens-IT-Architekturen?
Eine zentrale Herausforderung und Aufgabe im IT-Management wurde lange Zeit darin ge sehen, die aktuell installierten IT-Systeme zu gegebener Zeit zu modernisieren und (mit einem ausgewogenen Migrationskonzept) auf den neuesten Stand zu bringen. Eine weitere wichtige Aufgabe wurde in der Bereitstellung von geeigneten Applikationen und einer anpassungsfähigen IT-Infrastruktur gesehen. So sollten ein fortlaufender und zuverlässiger IT-Betrieb gewährleistet und gleichzeitig die Geschäftsprozesse des Unternehmens optimal unterstützt werden. Darüber hinaus kam es darauf an, die vorhandene IT-Infrastruktur und die IT-Applikationen mittels intelligenter und dynamischer Verwaltung optimal zu nutzen, um einerseits Kostenoptimierung und andererseits eine hohe Kundenzufriedenheit zu erreichen.
Mit dem Konzept der Enterprise Architecture (Unternehmensarchitektur) und der Verwendung des Kürzels EAM (für Enterprise Architecture Management) hat sich heute die zuvor skizzierte reine IT-Sicht um Geschäftskomponenten bzw. organisatorische Elemente (Strukturorganisation, Geschäftsfunktionen/Business Capabilities, Geschäftsprozesse, Geschäftsobjekte sowie die Unternehmensstrategie) erweitert, sodass mittels Enterprise Architecture Management eine neue Perspektive verbunden wurde, mit der auch das sogenannte Business-IT-Alignment auf eine nachhaltige Basis gestellt wird.
| 4.1 | Herausforderungen und Handlungsfelder von EAM |
Die Perspektive „Unternehmensarchitektur“ und ein darauf bezogenes Enterprise Architecture Management (kurz EAM) haben in den letzten Jahren in der Praxis des strategischen IT-Managements eine immer größere Bedeutung erlangt. Unter Anwendung eines Metamodells bzw. eines darauf basierenden EA-Tools ist heute die Möglichkeit gegeben, alle wesentlichen Elemente der Unternehmensarchitektur zu erfassen, integriert zu speichern und in unterschiedlichen Sichten anschaulich abzubilden. Dies sind – ausgehend von der vorliegenden Unternehmensorganisation – insbesondere
die Unternehmensfunktionen, Geschäftsservices, Geschäftsprozesse sowie Business-Capabilities (Geschäftsarchitektur oder fachliche Architektur),
die Applikationen und Applikationsservices (Anwendungs- oder Applikationsarchitektur),
die Daten- und Geschäftsobjekte (Daten- oder Informationsarchitektur) sowie
die zugrunde liegenden Plattformen und IT-Infrastrukturkomponenten sowie damit verbundene IT-Services (Technologiearchitektur).
Die genannten Bereiche der Enterprise-Architektur werden zur Unterstützung des Managements mit ihren wesentlichen Elementen erfasst und dokumentiert. Dabei werden die Be ziehungen der einzelnen Objekte und Komponenten untereinander (innerhalb der jeweiligen Architekturbereiche) sowie zu anderen Architekturbereichen festgehalten. Das Besondere: Im Unterschied zur IT-Architektur wird auch das Zusammenspiel von Elementen der Informationstechnologie (Applikationen, Daten, IT-Services, Infrastruktur) mit der geschäftlichen Tätigkeit des Unternehmens (Geschäftsfelder, Geschäftsprozesse, Organisationseinheiten, Rollen, Geschäftsobjekte) berücksichtigt.
Ziel des ganzheitlichen Architekturmanagements ist es, durch einen ganzheitlichen Blick die Unternehmensarchitektur in allen wesentlichen Teilbereichen (Domänen), die entsprechend miteinander vernetzt sind, transparenter zu machen. So können die Planbarkeit und Steuerbarkeit des Unternehmens sowie seiner Produkte und Services verbessert werden. Damit wird Unternehmen ein strategischer, konzeptioneller und organisatorischer Rahmen für die Ausgestaltung der IT-Landschaft zur Verfügung gestellt, der einen erheblichen Zusatznutzen sowohl für das Tagesgeschäft im Business-Bereich als auch für das Tages- und Projektgeschäft des IT-Bereichs darstellt.
Ausgehend von grundlegenden Herausforderungen, die ein Unternehmens-Architekturmanagement erforderlich machen, ist zunächst (in der Einführungsphase) ein Ordnungsrahmen zu spezifizieren, aus dem heraus sich die wesentlichen Handlungsfelder für das EAM (in Form von Use Cases oder Projekten) ableiten lassen. Dazu ist insbesondere eine Abgrenzung zwischen Geschäftsarchitektur und IT-Architekturen notwendig.
Eine Einordnung zum Begriff Unternehmensarchitektur (= Enterprise Architecture) gibt Bild 4.1.
Bild 4.1 Unternehmensarchitektur: Verbindung von Geschäftsarchitektur und IT-Architekturen
Herausforderungen und Probleme für das EAM
Eingesetzte IT-Infrastrukturen und IT-Applikationen sind insbesondere in mittleren und großen Unternehmen bzw. Verwaltungen oft organisch gewachsen. Über viele Jahre hinweg ist so eine umfangreiche, auf sehr unterschiedlichen Infrastrukturen (Technologien, Entwicklungsparadigmen, Komponenten) und Werkzeugen basierende IT-Anwendungslandschaft entstanden.
Hinzu kommt, dass in der Praxis oft Redundanzen auftreten: in der Funktionsabdeckung der Anwendungen, in der Datenarchitektur, bei den Schnittstellen und bei der Ausstattung mit Technologieplattformen. Zu viele Softwaretools decken identische Funktionen ab. Vielfach wird außerdem festgestellt, dass die Anzahl und die Komplexität von Schnittstellen zwischen den installierten Anwendungen außer Kontrolle geraten sind.
Folgende Herausforderungen sind für die IT-Verantwortlichen bzw. den EA-Leader zu beachten:
Es muss ein Ausgleich gefunden werden zwischen der nachhaltigen Unterstützung von Geschäftsprozessen und der nach wie vor dynamischen Entwicklung der Informationstechnologie. Wesentlich wird dabei ein Beherrschen der Schnittstellenkomplexität, um Integrationen zu ermöglichen bzw. zu fördern.
Die „Architekturkonformität“, bezogen auf die definierten Technologien und Migrationspläne, werden bei Architekturentwürfen und -entscheidungen sowie bei der Umsetzung von Roadmaps und der Durchführung von Business-IT-Projekten oft nicht bedacht. Deshalb sollten Enterprise-IT-Architekten bei IT-Projekten auch in die Konzeptions- und Auswahlphase einbezogen werden.
Ein zentraler Aspekt ist eine möglichst weitgehende Vereinfachung der integrierten Systemlandschaft, die auf prozess- und produktübergreifende Unternehmens-IT-Architekturen zielt (Stichwort „Komplexität der Bebauungslandschaft“ reduzieren).
Unternehmensleitung und auch IT-Verantwortliche stehen aufgrund der Differenziertheit der Anforderungen sowie der Fülle der Angebote und Lösungen für den IT-Bereich vor relativ schwierigen Situationen. Entscheidungen über IT-Architekturen zu treffen, ist deshalb nicht immer ganz einfach. So wurden in der Vergangenheit oft unkoordiniert IT-Systeme beschafft und Applikationen entwickelt, die anschließend im Betrieb und Support Unmengen von Geld und Ressourcen verschlangen oder schlicht nicht mehr wartbar waren.
Beachten Sie:
Angebotene und implementierte IT-Systeme weisen immer umfassendere Funktionalitäten auf und unterliegen raschen Entwicklungszyklen. Im Ergebnis ist bei Anwendern oft eine Vielzahl komplexer IT-Anwendungen auf unterschiedlichen Technologieplattformen vorhanden. Als Folge davon kann außerdem festgestellt werden, dass die heute existierende IT-Anwendungslandschaft äußerst komplex ist und häufig überdimensionierte Lösungen und überflüssige Funktionalitäten enthält.
Aufgrund der Ist-Situation in der IT-Praxis ergeben sich für die IT-Verantwortlichen zahlreiche Problemfelder:
Fehlender Überblick für Anwender und Entscheidungsträger durch die hohe Komplexität der IT-Landschaft: Aufgrund der über viele Jahre gewachsenen IT-Systeme ist vielfach nicht mehr nachvollziehbar, wie das Zusammenspiel zwischen den Geschäftsprozessen bzw. Arbeitsabläufen und der eingesetzten Soft- und Hardware im Detail erfolgt. Analysen der IT-Landschaft in Bezug auf Redundanzen, Strukturprobleme oder Optimierungsmöglichkeiten sind nur schwer möglich. Hilfreich wäre als Minimum zumindest eine grafische Darstellung der IT-Landschaft als Kommunikationsmittel in einem Unternehmen.
Erhöhte Risiken und fehlende Steuerbarkeit der IT: Softwareentwicklung und -beschaffung sind mangels eines umfassenden Überblicks über die Enterprise-Architektur (= IT-Bebauungslandschaft) ebenfalls nicht mehr gezielt steuerbar (schlechte, kostenintensive Wartbarkeit der IT-Systeme). Infolgedessen ergeben sich erhöhte Risiken für die Bereitstellung, Integration und den Betrieb leistungsfähiger IT-Systeme und IT-Anwendungen.
Fehlende Strategieorientierung bei Ad-hoc-Entscheidungen: Über fachliche Anforderungen werden aus dem Tagesgeschäft heraus Einzelfallentscheidungen getroffen – ohne übergreifende Gesamtsicht der IT. Entwicklungszusagen und vereinbarte Projektportfolios werden ständig geändert – mit einer Halbwertszeit von etwa acht bis zehn Wochen. Eine strategische Migration der existierenden Architekturen zu einer anderen Architektur wird vielfach erschwert oder ist oft kaum möglich. Unterschiedliche Entwicklungswege werden verfolgt – durch gegenläufige Technologie-Sets in der Infrastruktur entstehen eklatante Widersprüche.
Die Folgen liegen auf der Hand: Individualität und große Komplexität im IT-Bereich können Unternehmen und Verwaltungen teuer zu stehen kommen. Außerdem steigen durch die Standardisierung von Hard- und Software nicht nur die Administrationskosten, auch Änderungen in der IT-Infrastruktur lassen sich nicht so einfach und effizient durchführen. Letztlich führt dies zu einer erheblichen Verschlechterung der IT-Services und zu einer nachlassenden Kundenzufriedenheit bezüglich der IT-Organisation.
Eine Lösung der genannten Probleme sowie eine Nutzung weitergehender Potenziale könnte ein organisiertes und im strategischen IT-Management verankertes Enterprise-IT-Architekturmanagement eröffnen. Notwendig ist dafür eine integrierte Sicht auf alle relevanten Aspekte der IT-Anwendungs- und Systemlandschaft sowie der Technologielandschaft, die auch eine Verbindung zu den unterstützten Geschäftsprozessen bzw. Business Capabilities schafft.
Praxistipp
Eine wesentliche Aufgabe für das IT-Management besteht darin, ausgehend von strategischen Überlegungen und den vorliegenden Anforderungen die gewünschte IT-Entwicklung als Orientierungsrahmen vorzulegen: Dies ist im Kern die Zielarchitektur für die IT-Infrastruktur und die Applikationslandschaft. Dazu sind Gestaltungsprinzipien und Systementscheidungen zu formulieren, ebenso wie „strategische“ Technologien und Produkte (als Standards) definiert und in geeigneter Form im Unternehmen kommuniziert werden sollten. Im Sinne eines erfolgreichen Strategic Alignment müssen daraus auch verbindliche „Roadmaps“ zur weiteren IT-Entwicklung abgeleitet werden (etwa die Erarbeitung konkreter Architekturvorgaben und -standards).
Erst wenn mit EAM-Hilfe wesentliche Daten des Unternehmens strukturiert bereitgestellt und beherrscht werden, können durch die Analyse dieser Daten Stärken und Schwächen des Unternehmens in Hinblick auf zukünftige digitale Herausforderungen erkannt und in Zusammenarbeit mit dem Business die richtigen Innovationen angestoßen werden.
Handlungsfelder des EAM im Wandel
Die Handlungsfelder der Enterprise IT-Architekten befinden sich in einem dynamischen Wandel. Während Architekturmanagement traditionell eher auf eine Planung und Steuerung der unternehmensweiten IT-Architektur über Vorgaben ausgerichtet war, sind mittlerweile weitere Handlungsbereiche und neue Orientierungen verbreitet. Dabei wird ein besonderer Fokus auf Handlungsfelder und Use Cases gelegt, die den Unternehmen Mehrwert und umsetzbare Konzepte und Solutions zu liefern imstande sind.
Im Überblick können folgende Handlungsfelder und Aufträge für die EA-Verantwortliche und Architekturteams unterschieden werden (vgl. Bild 4.2):
Bild 4.2 Schwerpunkt-Handlungsfelder zur EA und für das EA-Management
Bei der Festlegung und Priorisierung der EA-Handlungsfelder gilt es einerseits, die Strategien im Unternehmenskontext (Unternehmens- und Digitalisierungsstrategie, IT-Strategie, Cloud-, Daten- und Servicestrategie etc.) in den Fokus zu nehmen, andererseits die Herausforderungen in Wirtschaft und Gesellschaft sowie die technologischen Veränderungen und ihre Potenziale zu beachten.
Als aktuelle Leitplanken für ein am Business Value ausgerichtetes EAM gelten primär folgende Orientierungen und Positionierungen:
EAM als Innovationsmotor im Unternehmen etablieren
EAM als Enabler datengesteuerter Organisationen und Produkte ausrichten
EAM als Treiber der Digitalisierung bzw. digitaler Transformationsvorhaben
EAM als Garant für das Erfüllen regulativer und resilienter Anforderungen verankern
EAM ist der entscheidende Innovationsmotor im Unternehmen: Enterprise IT-Architekten nehmen bereits heute wichtige Aufgaben bei Entscheidungen über Technologieinnovationen ein. Ergänzend bedarf es auch eines Involvierens der Enterprise-Architekten bei Innovationsinitiativen („die richtigen Innovationen und Investitionen machen“), indem die Einsatzpotenziale neuer Technologien und Verfahren rechtzeitig erkannt werden. Die damit verbundenen Migrations- und Umsetzungsmaßnahmen können unter Berücksichtigung von Einsatzszenarien und Impact-Analysen erfolgreich konzipiert und realisiert werden („Innovation ganzheitlich richtig implementieren“).
Praxistipp
Eine innovative Enterprise-Architecture-Organisation spielt eine Schlüsselrolle, um strategische Geschäfts- und IT-Ziele zu erreichen. Sie hilft der Organisation, effizient zu arbeiten, Silos zu durchbrechen, Optimierungspotenziale zu identifizieren sowie Risiken im Zusammenhang mit dem Einsatz intelligenter Technologien zu begrenzen.
Enterprise IT-Architekten sind die wesentlichen Enabler datengetriebener Organisationen: EAM spielt immer mehr eine Schlüsselrolle bei Aufbau und kontinuierlicher Weiterentwicklung einer datengesteuerten Organisation. Man spricht hier auch von einem Trend zum data centric EAM. Dabei ist für die Entwurfs- und Umsetzungsphase von Solutions in datengetriebenen Unternehmen ein Denken und Handeln nötig, das eine unternehmensweite Sicht der Datenanforderungen bereitstellt.
Dazu sind die strategischen Geschäftsprioritäten auf die technologischen und applikationsbezogenen Voraussetzungen abzustimmen. Da der organisatorische Bedarf an Daten und qualifizierten Datenanalysen und Datenprognosen wächst, werden Enterprise-Architekten benötigt, die ihre ganzheitliche Unternehmenssicht nutzen, um dabei die Geschäftsprioritäten mit der Datenarchitektur bzw. den Applikations- und Technologielandschaften erfolgreich zu verknüpfen. Im Ergebnis kann so sichergestellt werden, dass mit dem Bereitstellen integrierter Architekturentwürfe Entscheidungsträger über die Daten verfügen, die sie be nötigen, um Geschäftsergebnisse zu erzielen.
Praxistipp
In einer datengesteuerten digitalen Wirtschaft müssen Unternehmen verstehen, wie sie Daten besser nutzen können, um ihr Geschäftswachstum anzukurbeln. Aufgabe der Enterprise-Architekten muss es sein, für Unternehmensorganisationen ganzheitliche Konzepte sowie logische und physische Datenmodelle zu entwickeln, wie Daten erfasst und aus verschiedenen Systemen, Applikationen und Prozessen fließen, um Geschäftsdaten realtime in Systemen/Applikationen sowie für fundierte Entscheidungen bereitzustellen.
Enterprise IT-Architekten sind wertvolle Treiber und Enabler der Digitalisierung bzw. digitaler Transformation: Eine besondere Schlüsselrolle für Enterprise-Architekten liegt in der Planung und Umsetzung digitaler Transformationen. Digitalisierung mittels EAM – so eine weit verbreitete These – spielt für Unternehmen eine erfolgskritische Rolle im Wettbewerb. Denn nahezu alle digitalen Transformationen benötigen vor allem Daten und das Wissen um Zusammenhänge zu den betroffenen Architekturbereichen.
EAM-Kompetenz ist für die Auswahl und für die erfolgreiche Steuerung digitaler Transformationsvorhaben nahezu unverzichtbar. Ausgangspunkt für das Umsetzen digitaler Transformationsvorhaben bzw. komplexer Projekte ist in der Regel ein vereinbartes Portfolio, das aufzeigt, welche digitalen Vorhaben in Angriff genommen werden sollen. Für alle digitalen Projekte des Portfolios sind frühzeitig Überlegungen darüber anzustellen, welche Unternehmens-IT-Architekturen (Entwicklungswerkzeuge, Applikationen, Daten, Devices, Infrastrukturen und Plattformen) bezüglich der Projektentwicklung und Projektumsetzung hilfreich sind und dabei Ergebnisse liefern, die im Einklang mit den aktuellen – ggf. zu adaptierenden – Architekturvorhaben stehen.
EAM ist ein unverzichtbarer Enabler für das Erfüllen regulativer und resilienter Anforderungen: EA-Managementsysteme verfügen über Metamodelle, die wichtige Grundlageninformationen zum Produkt-, Daten- und Applikationsportfolio „auf Knopfdruck“ den Verantwortlichen und Stakeholdern bereitstellen können. Dies gilt etwa für die Lieferung von Auswertungen zu regulatorischen Anforderungen, die gemäß DSGVO oder für zahlreiche Audits zu erfüllen sind.
Beachten Sie:
Handlungsfelder und Deliverables von EAM ändern sich vielfach signifikant. Beispielsweise geht es heute weniger um Risikovermeidung, sondern eher hin zu Konzepten, die die Anpassungsfähigkeit und den Umgang mit Unsicherheiten ermöglichen – denn nur so ist der Weg zu agilen und resilienten Unternehmen sowie datengetriebenen Organisationen erfolgreich. Erst wenn mit EAM-Unterstützung wesentliche Daten des Unternehmens strukturiert bereitgestellt und beherrscht werden, können durch die Analyse dieser Daten Stärken und Schwächen des Unternehmens in Hinblick auf zukünftige Herausforderungen erkannt und in Zusammenarbeit mit dem Business die richtigen Innovationen angestoßen werden.
| 4.2 | Ordnungsrahmen und Grundausrichtungen für das Architekturmanagement |
Um die IT-Landschaft sicher steuern (lenken) und zukunftsorientiert weiterentwickeln (planen) zu können, ist für das IT-Management ein tragfähiges Gesamtbild der Enterprise-IT-Architekturen als Orientierungsrahmen unverzichtbar: die Ist-Architektur und Ziel-Architektur von Infrastruktur sowie Anwendungs- und Datenlandschaft. Dazu sind Gestaltungsprinzipien und Systementscheidungen zu formulieren, ebenso wie „strategische“ Technologien und Produkte (quasi als Standards) vereinbart und sodann kommuniziert werden sollten. Im Sinne des Strategic Alignment muss daraus auch die Konzeption von Zukunftsszenarien oder verbindlichen „Roadmaps“ für die weitere Entwicklung der Unternehmens-IT ableitbar sein. Gleiches gilt für jegliche Erarbeitung konkreter Vorgaben und Standards und die Möglichkeit einer sachgerechten Bewertung und Kontrolle.
Der Auftrag zur Entwicklung bzw. Steuerung eines komplexen Informationssystems in einem großen Unternehmen (also der IT- oder Enterprise-Architektur) lässt sich mit einem Auftrag zur Erschließung eines Wohngebiets in einer Stadt vergleichen. In beiden Fällen gibt es
gewachsene Strukturen (oft über lange Zeiträume),
viele unterschiedliche Akteure mit unterschiedlichen Interessen,
lange Zeiträume für die Umsetzung struktureller Änderungen,
Steuerungs- und Kontrollstrukturen (Governance) auf verschiedensten Ebenen der Organisation.
Im Rahmen des Managements von Enterprise IT-Architekturen bedarf es in Analogie dazu
der Festlegung eines Ordnungsrahmens mit der Beschreibung der grundlegenden Architekturelemente,
der Formulierung einer Vision und von daraus abgeleiteten strategischen Architekturzielen sowie
der Entwicklung und der laufenden Verfolgung (der Einhaltung) von Architekturprinzipien.
| 4.2.1 | Grundelemente einer Enterprise- bzw. IT-Architektur |
Um zu einem geeigneten Ordnungsrahmen zu gelangen, wird eine Enterprise-Architektur für Unternehmen häufig in Form folgender Grundbausteine beschrieben:
Geschäftsarchitektur und Organisation (Geschäftsfelder, Geschäftsprozesse, Geschäftsfunktionen, Organisationseinheiten)
Anwendungsarchitektur (Applikationsarchitekturen, die beispielsweise als Business-Layer bzw. Knowledge-Layer im Schichtenmodell abgebildet werden)
Daten-/Informationsarchitektur (Datenkataloge für Daten- und Geschäftsobjekte, Data Fabric, Data Lakes/DW)
Technologiearchitektur (IT-Infrastrukturen, IT-Services, Plattformen u. a.)
Ein organisatorischer Rahmen (Rollen, Aufgaben, Prozesse) ist ebenso notwendig wie die Abgrenzung der Domänen. All dies bildet dann den Ordnungsrahmen für das Management der Enterprise IT-Architekturen. Ein entsprechendes Orientierungsgerüst zeigt (in Anlehnung an Accenture) Bild 4.3.
Bild 4.3 Ordnungsrahmen für das Enterprise Architecture Management
Orientiert an dieser Festlegung kann die Konkretisierung eines Ordnungsrahmens für die jeweilige Organisation erfolgen. Zur Klarheit der begrifflichen Einordnung der Vielzahl praktischer Vorschläge finden Sie nachfolgend eine Zuordnung von meist synonym gebrauchten Bezeichnungen der Architekturelemente (Tabelle 4.1):
Tabelle 4.1 Einordnung der Architekturbegriffe
Begriff |
Synonym verwendete Begriffe |
Applikationsarchitektur (engl. Application Architecture) |
|
Datenarchitektur (engl. Data Architecture) |
|
Geschäftsarchitektur (engl. Business Architecture) |
|
Technologiearchitektur |
|
Softwarearchitektur |
|
| 4.2.2 | Architekturvisionen entwickeln |
Im Rahmen des Visioning ist die grundlegende strategische Ausrichtung der Enterprise-Architektur zu vereinbaren. Dabei gilt es insbesondere, Verständnis und Ordnungsrahmen der Unternehmensarchitektur festzulegen und – ausgehend von der Unternehmensstrategie – die wesentlichen Optionen (Handlungsfelder und Use Cases) in den verschiedenen Architekturbereichen abzustecken. Zwei Fragen stellen sich zu Beginn des Visioning:
1. Was müssen Unternehmen in welchen Schritten kurz-, mittel- und langfristig tun, um die angestrebten Ziele zu den verschiedenen Architekturbereichen (Domänen) durch die Nutzung von EAM-Instrumenten und Tools zu erreichen?
2. Welchen Nutzen bietet EAM in den verschiedenen Domänen?
Aus den Zielen zu den Architekturbereichen und damit einhergehenden Maßnahmen kann eine EA-Vision entwickelt und dokumentiert werden. Ein Beispiel für eine EA-Vision-Map zeigt die nachfolgende Abbildung für einen betrachteten Zeitraum von drei bis fünf Jahren:
Bild 4.4 EA-Vision-Map: Ziele/Aktivitäten (gemäß Zeithorizont)
Nachfolgend sind ausgewählte Nutzenfaktoren herausgestellt, die in Studien immer wieder genannt und durch zahlreiche Praxisprojekte bestätigt werden. Sie bedürfen für jedes Unternehmen in den jeweiligen Domänen einer Überprüfung, inwiefern diese im Anwendungsfall realisierbar erscheinen:
Informationssysteme mit hochwertigem Architekturstandard und hohem Integrationsgrad leisten einen höheren Beitrag zum Unternehmenserfolg bzw. zur Steigerung der Unternehmensproduktivität: IT wird reaktionsschneller, flexibler und neue Aufgaben und Geschäftsanforderungen können besser erfüllt werden.
Erhöhung der Innovationskraft durch Business-IT- und digitale Lösungen: Unternehmen haben einen Überblick über ihre IT-Investitionen, die das Unternehmenswachstum unterstützen. Die Business-IT-Landschaft wird übersichtlicher, sodass IT-Innovationen schneller bereitgestellt werden können.
Die Qualität von Business-IT-Projekten bzw. digitaler Transformationsvorhaben wird gesteigert: Die Projekte bleiben nicht nur im vorgesehenen zeitlichen und finanziellen Rahmen, sondern stehen im Einklang mit der Geschäfts- und IT-Strategie des Unternehmens.
Die Kosten der IT-Landschaft bzw. des IT-Betriebs sind transparent und zeigen Kostensenkungspotenziale auf: Dies ermöglicht ein Erkennen der Kostentreiber und das Senken der Betriebskosten.
Sicherung von Compliance: Ein ganzheitlicher Governance-Ansatz hilft, Projekte besser zu steuern, um Compliance-Kontrollen durchzusetzen. Klar definierte Zuständigkeiten und nachvollziehbare Prozesse verbessern die Einhaltung von Compliance-Vorgaben.
| 4.2.3 | Zielsetzungen und Handlungsprinzipien für das Enterprise-IT-Architekturmanagement |
Grundvoraussetzung für die ebenso ganzheitliche wie nachhaltige Optimierung der IT-Landschaft ist die Festlegung von Architekturprinzipien, die eine wesentliche Leitlinie für das Handeln bei der Planung und Entwicklung von Architekturen bilden. Eine angestrebte eindeutige Neuausrichtung der gesamten Architektur bedarf darüber hinaus der Formulierung der strategischen Zielrichtung auf Basis der übergeordneten Unternehmensziele.
Wie sehen die wesentlichen Rahmenbedingungen und Zielsetzungen bei Einführung eines systematischen Enterprise IT-Architekturmanagements aus? Detailziele, die sich – etwa orientiert an einer Balanced Scorecard – daraus ableiten lassen, zeigt das Referenz-Anwendungsbeispiel in Tabelle 4.2.
Tabelle 4.2 Enterprise-Architektur-Zielkatalog (Beispiel aus einer Referenzorganisation)
Zielbereiche |
Zielsetzungen |
Finanzielle Ziele |
|
Kundenziele |
|
Architekturprozessziele (IT-Service-Ziele) |
|
Personalziele |
|
Ziele zu den IT-Systemen/IT-Services |
|
Ziele zu den Business-IT- Projekten |
|
Weitere Teilziele sind schließlich für die jeweils festgelegten Architekturbereiche daraus abzuleiten. Ein Beispielergebnis zeigt Bild 4.5.
Bild 4.5 Vier Architekturbereiche und zugeordnete Zielsetzungen
| 4.3 | Hauptbereiche der Enterprise Architecture – Dokumentation und Integration |
Voraussetzung zur Entwicklung, Planung und Steuerung von Enterprise IT-Architekturen ist es, die Ist-Situation der jeweiligen Unternehmensorganisation und ihre Architekturelemente in geeigneter Form zu dokumentieren. Dazu bieten sich mittlerweile zahlreiche Beschreibungsmodelle und Dokumentationsformen an, wobei natürlich vor allem in Abhängigkeit von dem jeweiligen Architekturbereich (der Domäne) Unterschiede gegeben sind. Um die Zusammenhänge zwischen den Architekturbereichen abbilden zu können, ist es notwendig, ein entsprechendes Design der EA zu entwerfen und zu implementieren. Dies erfolgt mittels eines sogenannten EA-Metamodells, das am besten toolgestützt erfolgt.
Im Wesentlichen finden sich folgende Argumente, warum Enterprise IT-Architekturen einheitlich und aussagekräftig dokumentiert werden müssen:
Eine Dokumentation der Enterprise- IT-Landschaft ist unerlässlich, um Zusammenhänge zwischen Geschäftsprozessen, Anwendungen (IT-Applikationen), Daten- und Informationsobjekten sowie IT-Plattformen und IT-Komponenten zu verstehen.
Ohne aktuelle Architekturdokumentation befinden wir uns im Hinblick auf Planungen und Entscheidungen zu Enterprise IT-Architekturen im „Blindflug“.
Eine transparente Architekturdokumentation ist ein hervorragendes Kommunikationsinstrument für das IT-Management (gegenüber Kunden und weiteren Stakeholdern).
Eine Architekturdokumentation schafft Transparenz hinsichtlich der angewandten Methoden und Verfahren in den Architekturbereichen und der verwendeten technologischen Umsetzungen. Sie erhöht letztlich die Sicherheit im täglichen Handeln für verschiedene IT-Bereiche – wie etwa im IT-System- und IT-Servicemanagement, im IT-Projektmanagement u. a.).
Die Bereiche der Unternehmens-IT-Architektur – Geschäftsarchitektur, Applikationsarchitektur, Technologiearchitektur (IT-Infrastrukturen und IT-Plattformen) sowie Daten- und Informationsarchitektur – geben den Rahmen für Umsetzungsmöglichkeiten in der Praxis. Gleichzeitig ermöglichen sie gezielte strategische Überlegungen verschiedenster Art.
Merke:
Von besonderer Relevanz für die Architekturdokumentation ist die ganzheitliche Betrachtung auf der Ebene der Gesamtorganisation. Die Erfassung und Beschreibung von Architekturen sollten „im Großen“ ansetzen (quasi als Big Picture) sowie die Wechselwirkungen zwischen den skizzierten Bausteinen der Architektur berücksichtigen.
Für jede Architekturvariante sind nachfolgend die wichtigsten Merkmale angegeben, die zur Beschreibung und Dokumentation wesentlich sein können. Orientierung dazu bietet Tabelle 4.3.
Tabelle 4.3 Architekturvarianten und Darstellungs-/Dokumentationsformen
Varianten |
Darstellungen/Elemente |
Geschäftsarchitekturen (fachliche Architekturen, Prozessarchitektur) |
Die Geschäfte, Geschäftsfelder, Geschäftsfunktionen bzw. Geschäftsprozesse werden standardmäßig durch Business Capability Maps, Wertschöpfungsketten und Fachlandkarten bzw. Prozesslandkarten abgebildet. In Detailabbildungen wird dann etwa ein Geschäftsprozess durch ein Modellierungsverfahren (BPMN-Notation) erfasst und abgebildet. |
Applikationsarchitekturen |
Eine Applikationsarchitektur skizziert die Ist-Applikationslandschaft bzw. als Soll-Architektur die Ausrichtung der künftigen Anwendungslandschaft. Für die wichtigsten Anwendungsgruppen sind die Applikationen zu clustern und in Diagrammen (Cluster-Darstellungen) abzubilden. |
Technologiearchitekturen |
Eine Technologiearchitektur (Infrastrukturarchitektur)
|
Daten- und Informationsarchitekturen |
Die Datenobjekte werden in Datenglossaren systematisiert und in Datenkatalogen erfasst. Darüber hinaus sind Informationsflussdarstellungen sowie Dokumentationen zur gesamten Datenorganisation wichtig (etwa Datenquellen, Speicherorganisation, Regelungen zum Data Ownership sowie zu Zugriffsberechtigungen etc.). |
| 4.3.1 | Dokumentationsformen für Enterprise-Architekturen |
Grundsätzlich ist festzustellen, dass sich durch eine strukturierte Dokumentation der Unternehmensarchitekturen ein wichtiger Nutzen für jede Organisation ergibt: Die inventarisierte Enterprise IT-Architektur schafft Transparenz und macht so Auswirkungen geplanter Änderungen auf Anwendungen, Geschäftsprozesse und weitere Elemente der Architektur vorhersehbar. Damit verbundene Ausfallrisiken lassen sich zielgerichteter erkennen und abschätzen. Prinzipiell unterscheidet man drei Arten der Dokumentation:
Textuelle Beschreibung der IT-Architektur (Enterprise Architecture)
Tabellarische Darstellung der IT-Bebauung
Grafische Darstellungen zu den Architekturen (in der Regel als vernetzte Darstellungen zur Visualisierung von Zusammenhängen und Schnittstellen)
Bei der textuellen Dokumentationsvariante handelt es sich um eine reine bzw. primär verbale Darlegung zu den Architekturdomänen und ihren Elementen. Diese Dokumentationsart ist nur in sehr eingeschränkter Form und für kleinere Systeme sinnvoll. Sobald es sich um ein etwas umfangreicheres System handelt, geht schnell der Überblick verloren („Textwust“).
Die Dokumentationsform Tabelle ermöglicht es sehr gut, die Zusammenhänge zwischen zwei Größen (z. B. Applikationen und unterstützte Geschäftsprozesse) darzustellen und daraufhin verschiedene Analysen vorzunehmen (z. B. Gap-Analysen).
Die grafische Form der Dokumentation verwendet freie oder standardisierte Grafikelemente und eignet sich sowohl für ein Big Picture (als Überblick) als auch besonders gut zur Darstellung einzelner Architekturkomponenten und deren Vernetzungen.
Zu beachten ist: Zentrale Einflussfaktoren für die Festlegung der Dokumentationsform für die Enterprise-Architekturen (die IT-Bebauung und deren Vernetzung) sind die Ziele und Fragestellungen bzw. Anforderungen der verschiedenen Stakeholder. Ein wichtiges Hilfsmittel zur Beantwortung der Fragestellungen sind verschiedene Visualisierungen und Auswertungen.
Im Einzelnen sind die folgenden grafischen Dokumentationstypen für Enterprise-Architekturen verbreitet:
1. Anwendungslandkarte: Diese Visualisierungsform gibt eine Übersicht über die wichtigsten Anwendungen (Applikationen) des Unternehmens, indem sie die Anwendungen und ihre Schnittstellen aufzeigt. Schnittstellen können in eigenen Diagrammen verfeinert dokumentiert werden.
2. Clustergrafiken: Applikationen und Geschäftsarchitekturen lassen sich gut über eine sogenannte Clustergrafik visualisieren. So können beispielsweise Geschäftsprozesse oder Funktionen in fachlichen Blöcken gruppiert werden (als fachliche Domänen), um etwa einen fachlichen Rahmen für die Weiterentwicklung der IT-Bebauung bereitzustellen. In ähnlicher Form sind Anwendungen (Applikationen) in Applikationsblöcken zusammenzufassen, um etwa besondere Integrationszusammenhänge oder gleiche Adressatengruppen zu dokumentieren.
3. Zuordnungstabellen: Mit Zuordnungstabellen besteht die Möglichkeit, die Art der Beziehung zwischen den wesentlichen Elementen der Enterprise-Architektur zu visualisieren. So lässt sich beispielsweise sehr übersichtlich darstellen, welche Applikationen welche Geschäftsprozesse unterstützen. Auf diese Weise erhält man einen guten Überblick über die Zusammenhänge von Geschäftsarchitekturen und Applikationsarchitekturen.
4. Bebauungsplangrafik: Sie ermöglicht die Darstellung von Zusammenhängen zwischen den Elementen der Unternehmensarchitektur in Form einer Matrix. Durch eine flexible Zuordnung von Elementen zu Zeilen, Spalten und Inhalt der Grafik können eine Vielzahl von Fragestellungen beantwortet werden. Zudem lassen sich Eigenschaften der Inhaltselemente über unterschiedliche Farben und Linientypen visualisieren, um so zusätzliche Informationen bereitzustellen (etwa hinsichtlich der Bewertung).
5. Portfolio-Grafik: Sie dient zur Visualisierung von „Wertigkeiten“ unter Bebauungselementen oder Strategien für Bebauungselemente auf einen Blick.
Hinweis
Umfang und Art der Informationen, die zu den IT-Architekturen dokumentiert werden, orientieren sich an den Zielsetzungen und den vorhandenen bzw. geplanten Architekturmanagementprozessen. Während bestimmte Informationen für alle Prozesse vorzuhalten sind, kann für weitere Elemente der Unternehmensarchitektur, z. B. Schnittstellen und Daten, eine spezifische Detaillierung erfolgen. Der Erhebungs- und Pflegeaufwand bleibt auf diese Weise kalkulierbar.
| 4.3.2 | Applikationsarchitektur |
Die Applikationsarchitektur (Application Architecture) stellt eine Übersicht der eingesetzten Anwendungssysteme, deren Interaktionen und Beziehungen zu Kerngeschäftsprozessen der Organisation sowie zur Daten- und Infrastrukturebene bereit. In der konkreten Beschreibung der Anwendungsarchitektur werden ergänzend dann die zwischen den Applikationen bestehenden Beziehungen und Schnittstellen analysiert und festgehalten.
Bild 4.6 zeigt ein Beispiel einer Applikationslandkarte, die von einem EAM-Tool relativ problemlos erzeugt werden kann, wenn sämtliche Basisdaten zu den Applikationen (Name der Applikation, Owner etc.) sowie wesentliche Bereiche (wie Organisationseinheiten, Domänen, Lokationen, User etc.) zugeordnet werden können.
Zur Beschreibung der IT-Anwendungen (Vertrieb u. a.) empfiehlt sich eine Gliederung entlang der Hauptprozesse des Unternehmens (Kern-, Management- und Unterstützungsprozesse). Mit diesem Vorgehen können aus der Prozesssicht heraus Vorgaben für einheitliche Technologien zur Integration und Homogenisierung der Anwendungslandschaft entwickelt werden. Entsprechende Architekturkonzepte liefern für alle relevanten Planungsbereiche der IT konkrete, gegenseitig abgestimmte Konzepte bzw. „Bebauungspläne“ fachlicher und technischer Art, die zeigen, wie eine vorhandene IT-Strategie im Unternehmen umgesetzt werden soll und kann.
Bild 4.6 Applikationslandkarte – Applikationen und nutzende Fachbereiche
Aufbauend auf Standards, die vom Unternehmen für Geschäftsprozesse und Daten zu erarbeiten und vorzugeben sind, werden Architekturkomponenten zur Prozessunterstützung definiert. Die Architekturkomponenten decken durch unterschiedliche Applikationen verschiedene Funktionsbereiche des Unternehmens ab. Das lässt sich beispielsweise sehr anschaulich durch eine Funktionstabelle (Zuordnungstabelle) wiedergeben.
Bild 4.7 Zuordnungstabelle – zeigt Applikationen und zugeordnete Geschäftsfunktionen/Prozesse
Voraussetzung für eine Zuordnung ist, dass folgende Festlegungen getroffen werden:
Festlegung von Applikationsverantwortlichen (Owner-Prinzip)
Zuordnung von Organisationseinheiten bzw. von Usern (nutzende Organisationseinheiten, vorhandene bzw. lizenzierte User) zu den vorhandenen Applikationen
Bei der Planung und Entwicklung von IT-Applikationsarchitekturen gilt es darüber hinaus zu beachten, dass mitunter neue geschäftliche Lösungen (etwa aufgrund neuer und veränderter Geschäftsfelder), welche den Kundennutzen erhöhen und/oder die Kosten senken, anstehen. Für die Detailbeschreibung der jeweiligen Applikationsarchitektur kann folgende Unterscheidung vorgenommen werden:
Die Anwendersicht dient der Darstellung der Soll-Funktionalität der Anwendungen, bezogen auf die Unternehmensprozesse.
Die technische Sicht zeigt die Applikationen aus IT-Sicht mit ihren Bausteinen (Funktionen), ihrem Zusammenwirken sowie der datenmäßigen Integration.
Das Systemdesign zeigt die Designprinzipien und genutzte Standards beim Aufbau der Applikationen, inklusive der Integration von eingekauften Komponenten. Dies ist mehr die Sicht für Solution-Architekten.
Beachten Sie:
Die Dokumentation der Anwendungen (Applikationen) zielt unter anderem auf die Vorgabe von einheitlichen Technologien zur Integration und Homogenisierung der Anwendungslandschaft. Eine Anwendungsarchitektur bestimmt so die Ausrichtung der künftigen Anwendungslandschaft und macht konkrete Entwicklungsvorgaben. Für die wichtigsten Anwendungsgruppen sind verbindliche Architekturprinzipien und Leitlinien aufzustellen, wobei für jede Plattform grundsätzlich die gleichen Prinzipien und Leitlinien gelten.
| 4.3.3 | Geschäftsarchitektur (Business Architecture) |
Die Geschäftsarchitektur ist Teil der Unternehmensarchitektur. Sie beschreibt im Wesentlichen die Grundstrukturen des Geschäfts (Geschäftsfelder inkl. der Unternehmensziele), die dem Unternehmen bzw. den Geschäftsfeldern zugrunde liegenden (durch IT unterstützten) Business Capabilities und Geschäftsprozesse, die hierfür erforderlichen Steuerungsmechanismen und Ressourcen sowie strukturelle Anpassungen in der Organisation des Anwenders (z. B. Rollen und Prozesse für das Architekturmanagement).
Die Geschäftsarchitektur präzisiert die Business-Strategie, Steuerungsmechanismen, Organisation und Kerngeschäftsprozesse (Definition nach TOGAF). Objekte, die im Rahmen einer Dokumentation der Geschäftsarchitektur primär erfasst und dargestellt werden, sind:
die Grundstrukturen des Geschäfts (inkl. der Darstellung der Geschäftsziele),
Prozesse/Geschäftsprozesse,
Geschäftsobjekte,
Business Capabilities (Geschäftsfunktionen),
Organisationsstrukturen (Organisationseinheiten) und
Ressourcen (Akteure, Rollen etc.).
Im Rahmen einer Geschäftsarchitektur ist es notwendig, die Geschäftsfunktionen und Geschäftsprozesse zu erfassen, mit ausgewählten Kriterien zu bewerten und in eine für die Unternehmens-IT verwendbare Form zu bringen. Notwendige EA-Aktivitäten können daher sein:
Anforderungen des Business an die IT identifizieren und verstehen (Business-Analyse, Demand-Management)
Geschäftsfunktionen und Geschäftsprozesse modellieren (Geschäftsfeldentwicklung, Business Capability Management und Prozessmanagement)
Geschäftsfunktionen und Geschäftsprozesse mittels standardisierter und individueller Kriterien bewerten und Handlungsbedarf identifizieren (etwa Initiativen zur Digitalisierung oder Automatisierung von Geschäftsprozessen)
Geschäftsfunktionen und Geschäftsprozesse mit Anwendungen, Informationen und IT-Komponenten verbinden
Um eine Dokumentation vornehmen zu können, ist oft vorab eine Erhebung der Ist-Situation notwendig. Darstellungsformen für Geschäftsarchitekturen (fachliche Architekturen, Prozessarchitekturen) gibt es sehr viele. Als Beispiele, die am weitesten verbreitet sind, seien genannt:
Bebauungspläne (Fachstrukturen)
Prozesslandkarten und Wertschöpfungsdiagramme
Swim-Lane-Diagramme und Prozessketten
Business Capability Maps
Ein Beispiel für eine Prozesslandkarte gibt Bild 4.8.
Bild 4.8 Prozesslandkarte mit Wertschöpfungsketten – Beispiel
Für eine Dokumentation der Geschäftsprozesse ist es unverzichtbar, die Geschäftsprozesse zu systematisieren. Dabei findet sich für eine Klassifizierung/Kategorisierung die Unterscheidung in Kern-, Unterstützungs- und Managementprozesse. Folgende Teilaktivitäten zur ganzheitlichen Dokumentation und Umsetzung der Geschäftsarchitektur können dabei vorkommen:
Festlegung einer prozessorientierten Ausrichtung auf strategischer Ebene (Identifikation der Geschäftsfelder und Geschäftsprozesse);
Erstellen von Wertschöpfungsdiagrammen und Prozesslandkarten (in der alle wesentlichen Geschäftsprozesse identifiziert und definiert sind);
Benennen der Prozessverantwortlichen sowie Festlegung der Aufgaben, Rechte und Pflichten (Organisation und Ressourcen);
Einführung und Umsetzung eines mit den Unternehmenszielen abgestimmten Prozesscontrollings (Planung, Kontrolle, Informationsbereitstellung).
Beachten Sie:
In der Geschäftsarchitektur werden die wesentlichen Geschäftsfelder, Dienstleistungen (Services) und die dafür benötigten Funktionen (Aufgaben), Prozesse, Lokationen, Rollen und Informationen sowie deren Beziehungen untereinander aufgenommen. Vorteile der Abbildung der Geschäftsarchitektur mit ihren wesentlichen Elementen (Geschäftsprozesse, Geschäftsfunktionen) sowie der Erfassung von Bewertungsattributen liegen vor allem in einer Unterstützung des Anforderungsmanagements für IT- bzw. digitale Lösungen.
| 4.3.4 | Datenarchitektur |
Die Datenarchitektur hat für die Arbeiten im Enterprise Architecture Management in den letzten Jahren zunehmende Bedeutung erlangt. Das ist vor allem damit begründet, dass die Geschäfte, Produkte und Prozesse vieler Unternehmen immer mehr auf Daten basieren. Außerdem sind die Anforderungen (der Kunden/Data Consumer) enorm gestiegen – etwa im Hinblick auf Data Analytics sowie bezüglich der Qualität und des Zeitpunktes der Datenbereitstellung (z. B. Data Streaming).
Grundsätzlich beschreibt die Datenarchitektur die Struktur des logischen und physischen Datenbestands einer Organisation sowie die Ressourcen zur Datenhaltung (A Data Architecture describes the structure of an organization's logical and physical data assets and data management resources = Definition nach TOGAF).
Organisatorische Voraussetzungen zur Dokumentation und Analyse der Datenarchitektur sind, dass
die unternehmensweit für einen Architekturentwurf bedeutsamen Daten (möglichst in einem Datenglossar bzw. Datenkatalog) festgelegt sind sowie Data Owner und Data Consumer definiert sind,
für einzelne Sichten (z. B. Vertriebssicht der Kundendaten, Finanzsicht der Kundendaten) die jeweils zuständigen Organisationseinheiten identifiziert werden und
Kompetenzen, Verantwortlichkeiten sowie Werkzeuge für die Planung und den Entwurf von Datenstrukturen und Plattformen im Unternehmen vereinbart sind.
Eine Grundlage für die Abbildung der Datenarchitektur sind die Erhebung und die Analyse der bestehenden Anwendungen und Informationsquellen. Daten müssen konsistent und redundanzfrei verwaltet werden. Dazu sind die Datenobjekte in der Organisation systematisch zu erfassen, zu strukturieren und Anwendungen zuzuordnen. Auf diese Weise lassen sich Abhängigkeiten erkennen, die bei der Planung und Weiterentwicklung der Anwendungen zu berücksichtigen sind. Durch ein adäquates Datenmanagement wird außerdem die Konzeption der zukünftigen Datenarchitektur ermöglicht.
Praxistipp
Die zur Realisierung von Geschäftsprozessen sowie zur Datenanalyse benötigten Daten müssen identifiziert und dokumentiert sowie mit ihren Beziehungen in einer Datenarchitektur beschrieben werden. Die Beschreibung sollte in einem Modell und einer Darstellungsform erfolgen, die die Gesamtheit der Daten vollständig für alle an Informationssystem-Entwicklungsprozessen beteiligten Akteure verständlich und konsistent wiedergibt.
Für die Erhebung der Daten aus Architektursicht bedürfen folgende Fragen einer Klärung:
Gibt es ein Verzeichnis aller Daten (Datenglossar, Datenkatalog) des Unternehmens?
Gibt es eine Klassifikation der Unternehmensdaten nach geeigneten Kriterien?
Ist sichergestellt, dass alle Daten Eigner haben sowie die Pflichten und Rechte in Bezug auf die Datenverwendung bzw. Datenbereitstellung geklärt sind?
Ist geklärt, wie für die Korrektheit und Vollständigkeit der Unternehmensdaten gesorgt wird?
Gibt es Regelungen hinsichtlich der Datenverwendung?
Gibt es Regelungen in Hinblick auf die Datenspeicherung (was, wo, wie, wie lange . . .)?
Wichtige Ziele und Aktivitäten zum Aufbau und zur Nutzung einer Datenarchitektur umfassen:
Systematische Ordnung (Strukturierung) und Erfassung der Datenobjekte in der Organisation
Abbildung der Ergebnisse in einem Datenkatalog. Auf diese Weise lassen sich Abhängigkeiten erkennen, die etwa bei der Planung und Weiterentwicklung der Anwendungen zu berücksichtigen sind.
Aufbau einer Data Fabric. Basierend auf den strukturierten Datenobjekten sind folgende Komponenten einer Data Fabric zu etablieren: Data catalog (Unternehmensdaten werden über mehrere Datenquellen hinweg kategorisiert, um darauf zuzugreifen), Master data management, Metadata management, Data preparation/data quality (Data quality tools), Data integration (extract, transform, and load (ETL) processes; and transformation), Data analytics sowie Data visualization.
Datenmodellierung für konzeptionelle, logische und physische Datenentwürfe (= Datenmodelle bereitstellen)
Design-Konzepte für die Verbindung der Datenmodelle (Datenkataloge) mit Geschäftsprozessen, Business Capabilities, Informationsflüssen und Applikationen
Daten-Analyseoptionen ermöglichen (durch gezielte Nutzung von Informationen für Planungs- und Steuerungsaufgaben sowie für die GRC-Verwendung)
Auswertungen bereitstellen, die die Verbindung zwischen Datenmodellen, Entitäten, Attributen und Daten-Plattformen erfordern.
Ein wichtiger qualitätsunterstützender Faktor ist die Redundanzfreiheit der Stamm- und Bewegungsdaten. Für jedes Datum ist eindeutig festgelegt, in welchem Informationssystem dessen Original gespeichert ist. Ein wichtiges Element spielt in diesem Architektursegment ein zentrales Daten-Repository, das beispielsweise über eine IoT-Plattform realisiert werden kann (vgl. [HH18]; Hoffmann, Jörg; Heimes, Pit: Informationssystem-Architekturen).
Bezüglich der Abbildung der logischen Datenarchitektur ist festzustellen, dass die Darstellung der Informations- bzw. Datenarchitekturen klassischerweise über ERM-Diagramme erfolgt. Diese geben eine Datenübersicht und schaffen eine geeignete Grundlage für eine Beschreibung strukturierter Daten. Die detaillierten Daten können dann verwendet werden, um Input-/Output-Daten von Aktivitäten, den Datenfluss und den Datenaustausch zwischen den Prozessbeteiligten zu dokumentieren. Auch dienen die Datenobjekte als Grundlage, um den Datenaustausch zwischen den Applikationen zu beschreiben. Sie können darüber hinaus den Schnittstellen hinterlegt werden.
Integrierte Entwürfe und Datenflüsse abbilden
Hier ist das Konzept des Data Lakehouse zu erwähnen. Es ermöglicht die Überwindung traditioneller Daten-Silos, indem es die Kombination der besten Eigenschaften eines Data Lakes mit den Funktionalitäten eines Data Warehouses verbindet. Das Data Lakehouse entwickelt sich so in Verbindung mit einer integrierten Data Fabric zunehmend zum neuen Standard für Datenarchitekturen.
Eine weitere Option zur Abbildung von Datenarchitekturen besteht darin, festzulegen, wie Daten aus den verschiedenen Datensystemen, IT-Systemen sowie Anwendungen, zentral gespeichert, konsumiert, integriert und verwaltet werden sollen. Zu beachten ist: Im Endausbau sind Daten-Infrastrukturen nicht nur analytisch, sondern auch operational eingesetzt, d. h. sie müssen nicht nur Streaming- bzw. echtzeitfähig sein, sondern auch den operationalen Einsatz von künstlicher Intelligenz ermöglichen.
Praxistipp
Unternehmen benötigen heute mehr denn je eine umfassende architektonische und datenorientierte Struktur, um ein agiles Integrationsdesign aufzubauen, welches sich flexibel an die sich schnell ändernden Anforderungen eines heterogenen Datenökosystems anpassen kann. Data Fabric und Data Lakehouses stellen dafür neue Optionen dar.
| 4.3.5 | Technologiearchitektur |
Eine effiziente Steuerung der Technologielandschaften setzt ein umfassendes Wissen über die eingesetzten Technologien und Plattformen voraus. Damit Unternehmen alle Änderungen im Griff behalten, die sich durch neue Releases oder neue Technologien ergeben oder die durch Projekte und Übernahmen einfließen, ist eine robuste, effektive und effiziente Verwaltung des Technologieportfolios (= der Technologiearchitektur) unerlässlich.
Die Technologiearchitektur nimmt eine ganzheitliche Sicht auf die Systeminfrastruktur einer Organisation (eines Unternehmens) vor. Dazu zählen sowohl das technische System mit den diversen Komponenten (Hardware, Plattformen, Standorte, Netzwerke) als auch die Konfiguration sowie (im weiteren Sinne) das Management des Systems. Im Kern zeigt die Technologiearchitektur die Elemente der technischen Basissysteme, die technischen Konzepte, Standards und Produktvorgaben.
Aus Infrastruktursicht werden die verschiedenen IT-Komponenten in infrastrukturrelevante Schichten gegliedert, beispielsweise um für ein IT-Arbeitsplatz-, Server- und Host-Umfeld einen Orientierungsrahmen zu finden. Dieses Vorgehen zielt gleichzeitig auf die Vorgabe verbindlicher Standards und Produkte zur Integration und Homogenisierung der Infrastruktur.
Zur Beschreibung der Ist-Architekturen ist es von Vorteil, wenn ein ordentliches Asset-Management im Einsatz ist. Um einen Überblick über eine komplexe IT-Infrastruktur zu bekommen, ist es notwendig, alle Komponenten zu erfassen.
Für einen Unternehmenskontext können folgende Teilbereiche einer Technologiearchitektur unterschieden werden:
IT-Infrastrukturen (wie Server, Data Center etc.)
Digital Workplaces (etwa der PC-Arbeitsplatz, das Home Office oder mobile Systeme)
IT-Plattformen (z. B. Datenplattformen, IoT-Plattformen etc.)
Netzwerke (z. B. Inhouse Netze/LAN, WAN, öffentliche Netze)
Cloud-Technologien (IaaS = Infrastructure as a Service, PaaS = Platform as a Service)
Intelligente Technologien (KI, Hyperautomation u. a.)
In der Beschreibung der Infrastrukturarchitektur mit Karten auf Typebene werden primär die eingesetzten Systeme beschrieben. Ergänzend lassen sich Informationen zur physikalischen Ebene (Instanzen) angeben, denen dann Informationen wie eingesetzte Hardware, Netzwerksegmente, Systembetreuung, Ports oder IT-Adressen zugeordnet werden.
Diagrammtypen zur Dokumentation der Technologiearchitektur sind u. a. auch Netzwerkdiagramme. Bei einer Darstellung in Netzwerkdiagrammen besteht die Möglichkeit, den Zusammenhang zwischen Netzwerken, Routern, Switches und verwendeter Hardware (Server, Drucker etc.) darzustellen. Es besteht dabei durchaus die Option, die verwendeten Symbole benutzerdefiniert anzupassen.
Im Rahmen einer Technologiearchitektur werden die IT-Komponenten in infrastrukturrelevante Schichten gegliedert, beispielsweise um für ein PC-, Server- und Host-Umfeld einen Orientierungsrahmen zu finden. Die Technologiearchitektur gibt dabei letztlich den Rahmen für eine Organisation vor, innerhalb dessen Anwendungen beschafft, implementiert und betrieben werden können.
Welche Vorteile hat bereits die Basisdokumentation der Technologiearchitektur? Es lässt sich verlässlich sagen, welche Technologien wo eingesetzt werden:
Bei Änderungen des Technologieportfolios ist es möglich, die Auswirkungen auf das Anwendungsportfolio schnell zu analysieren und umgekehrt.
Auswahl und Einführung von Technologiestandards sowie deren Durchsetzung
Kosten und Risiken werden deutlich, die durch den Einsatz falscher Technologien eintreten.
Sie erkennen, welche neuen Technologien einen wirtschaftlichen Nutzen bringen.
Hinweis:
Das Infrastrukturkonzept hat den Vorteil, dass es die Anwendersicht auf die Systeme mit der IT-Sicht auf die Infrastruktur verbindet. Auf diese Weise lassen sich Beurteilungskriterien aus der Anwendersicht (Funktionalität, Flexibilität, Zuverlässigkeit und Schnelligkeit des Bereitstellens von neuen Funktionen) mit Beurteilungskriterien aus der IT-Sicht verbinden (Sicherstellen der Funktionsfähigkeit, Integrationsfähigkeit, Kostenreduktion durch Standardisierung).
Für den Entwurf und die Gestaltung einer zukunftsorientierten Technologielandkarte sollten nachhaltige Gestaltungsgrundsätze und Vorgehensweisen vereinbart sein. Beispiele sind etwa:
Ausgangslage für den Technologieentwurf ist in der Regel keine „grüne Wiese“. Greenfield ist daher beim Design der Technologielandkarte nur selten ein möglicher Ansatz. Zumeist muss auf ein vorhandenes Portfolio aufgesetzt werden, so dass der Mixedfield- oder Brownfield-Ansatz zu verfolgen ist.
Modularität als Designprinzip sollte im Zentrum stehen. Denn Hardware-Schnittstellen sollten gegeben und umsetzbar sein.
Die IT-Welt ist hybrid. Konventionelle Ansätze gilt es, mit agilen Architekturen zu verknüpfen.
Security muss integriert bei den Technologieentwürfen mitgedacht werden. Beispiele sind etwa eine integrierte Firewall oder der Zero-Trust-Ansatz.
Beachten Sie:
Die Architekturdokumentation (Beschreibung und Bewertung der IT-Architekturen) muss in regelmäßigen Abständen aktualisiert werden. So können Veränderungen in der IT-Architektur widergespiegelt und somit die Leistungsfähigkeit der IT-Systeme und IT-Prozesse verbessert werden. Die Architekturdokumentation wird unternehmensweit eingesetzt und zu jeder Architekturentscheidung herangezogen.
Die Architekturkomponenten sind so zu beschreiben, dass Entwicklungs- und Betriebsanforderungen abgedeckt werden. Die Architektur wird die strategischen Prozesse und Architekturmodelle unterstützen und agiert somit bereichsübergreifend. Es bietet Vorteile, gerade für die Dokumentation der Architekturen Tool-Unterstützung zu nutzen.
| 4.3.6 | EA-Metamodell und Unternehmensmodellierung |
Ausgehend von dem vereinbarten Ordnungsrahmen sind im nächsten Schritt die relevanten Architekturelemente im Detail für die einzelnen Architekturbereiche bzw. für die Abbildung der Beziehungen zwischen den Architekturbereichen und Architekturelementen zu beschreiben.
Notwendig ist es, das Design der EA (das sog. EA-Metamodell) zu entwerfen und zu implementieren. Dies umfasst Entwerfen und Implementieren einer Unternehmensarchitektur, die die Geschäftsaktivität des Unternehmens oder der Behörde optimal unterstützt. Alle Architekturebenen (Geschäfts-, Anwendungs-, Technologie-, Informationsarchitektur) fließen in umfassende Architekturlösungen ein. In einem Architektur-Framework werden der aktuelle und zukünftige Status beschrieben sowie Richtlinien festgelegt, über die sich die Integrations- und Transformationsmaßnahmen steuern lassen.
Ist ein EAM-Tool vorhanden, so verfügt dieses in der Regel über ein entsprechendes Metamodell. Dieses kann ggf. auf die spezifischen Anforderungen des Anwenders angepasst werden. Das Metamodell stellt die wesentliche Basis für das IT-Enterprise-Architecture-Management dar. Eine damit auf die jeweilige Organisation abgestimmte Abbildung aller relevanten Architekturelemente ermöglicht innovative Planungen und sichere Steuerung der Business-IT-Landschaft.
Bild 4.9 EA-Metamodell (Quelle: Opitz-Consulting) und EA-Repository – die Informationsbasis für das Architekturmanagement
Um eine umfassende (flächendeckende) Architekturentwicklung zu ermöglichen, hat es sich bewährt, dass diese auf den angesprochenen Ebenen der Geschäftsarchitektur, der Informationssystemarchitekturen (Applikations- und Datenarchitektur) sowie der Technologiearchitektur erfolgt.
Auf allen Ebenen wird zunächst sowohl die IST-Architektur (Baseline) als auch die Zielarchitektur (Target) beschrieben. Die Ebenen werden miteinander verknüpft und im Zielbild aufeinander abgestimmt. Dies wird durch Nutzung einer Modellierungsmethodik auf der Basis des EA-Repository ermöglicht. Als Standard gilt weltweit das EA-Modell Archimate mit der dazugehörigen Modellierungsmethodik.
| 4.4 | E AM-Use-Cases – Beispiele für unternehmensspezifische Umsetzungen |
Natürlich sind gezieltes Planen und Verwalten der Enterprise Architecture bzw. der IT-Architekturen kein Selbstzweck. Ziel ist letztlich die Bereitstellung von geeigneten Applikationen und einer agilen IT-Infrastruktur, die einen zuverlässigen IT-Betrieb gewährleisten und dabei die Geschäftsprozesse und -funktionen des Unternehmens optimal unterstützen.
Um diese Zielsetzungen zu erreichen, muss eine integrierte Sicht auf alle relevanten Aspekte der IT-Anwendungs- und Systemlandschaft erfolgen, wobei eine Verbindung zu den unterstützten Geschäftsprozessen hergestellt wird. Leistbar ist dies heute durch ein Architekturmanagement, das den Schwerpunkt nicht nur auf die IT-Elemente legt, sondern als integraler Bestandteil des Business behandelt wird und daher in einem Metamodell insbesondere auf Organisationseinheiten, Geschäftsfelder, Geschäftsobjekte, Geschäftsfunktionen und Geschäftsprozesse Bezug nimmt.
Eine Einordnung denkbarer Use Cases für EAM gibt Bild 4.10.
Bild 4.10 EA-Use-Cases – Beispiele
Nachfolgend werden einige dieser EA-Use-Cases skizziert, um einen konkreteren Einblick in die möglichen Rollen und Prozesse von Enterprise-IT-Architekten bzw. vorhandener Applikations-, Business-, Data- und Plattformarchitekten zu geben. Dabei werden je Use Case eine typische Ausgangssituation formuliert und darauf bezogene Potenziale und Nutzenfaktoren durch Unternehmensarchitekturmanagement mit ausgewählten EAM-Tools und Instrumenten dargelegt.
| 4.4.1 | Use Case „Architekturlandschaft planen und ausgestalten“ |
Die Umsetzung der Konzepte des Architekturmanagements verändert in vielen Organisationen die Art und Weise, wie die Planung, Entwicklung und Einführung von Informationssystemen durchgeführt werden. Vorhandene Rollen und Prozesse im Unternehmen bedürfen dann einer Veränderung, um die Architekturen erfolgreich planen und einführen zu können.
Nur in seltenen Fällen wird eine IT-Architektur wie vom Reißbrett nach vorgegebenen Standards und mit einheitlicher Methodik modelliert und implementiert – vielmehr beherrschen gewachsene Systeme mit unterschiedlichen Lebenszyklen die IT-Landschaft von Organisationen. Durch die immer weiter fortschreitende Vernetzung von Systemen und Applikationen entsteht – wie eingangs bereits ausführlich dargelegt – ein komplexes Geflecht von Beziehungen und Abhängigkeiten. Dieses Geflecht muss handhabbar, steuerbar und stringent gestaltet sein und den Architekten als Planern Mechanismen zur Verfügung stellen, damit sie die Anforderungen aus der Unternehmens- und IT-Strategie erfüllen können. Dazu ist auch eine Zuweisung der entstehenden Kosten an Geschäftsprozesse vonnöten, um die Erfolge der IT zur Unterstützung der Unternehmensstrategie messbar zu machen.
Praxistipp:
IT-Architekturen müssen immer die Geschäftsprozesse des Unternehmens bzw. die Geschäftsfunktionen unterstützen! Da das Geschäft und damit die Geschäftsprozesse einer Organisation dynamisch sind, ergeben sich jeden Tag neue Herausforderungen. Durch Dokumentation der Architekturlandschaft (Enterprise Architecture) und die Etablierung eines architekturellem Denkens und Handelns im Management und bei den Professionals gelingt so eine agile Umsetzung (etwa auch bei dem nachfolgend skizzierten Use Case).
| 4.4.1.1 | Generelle Vorgehensweise zur Architekturplanung |
Im Rahmen des Architekturmanagements sind Entscheidungen darüber zu treffen, wie eine standardisierte Entwicklung, Integration, Installation und Wartung (Modifikation) von IT-Systemen (IT-Architekturen und digitalen Technologien) aufgrund von IT-Strategien erfolgen kann. Einen beispielhaften Überblick über einen möglichen Prozess in der Praxis und dabei einbezogene Akteure (Gruppen) gibt Bild 4.11.
Grundsätzlich gilt, dass die Erarbeitung einer IT-Strategie und der davon abgeleiteten IT-Architektur und Infrastruktur ein inkrementeller, iterativer Prozess ist. Dies soll auch Bild 4.11 als Praxisbeispiel veranschaulichen. Jeder Durchlauf soll den Reifegrad des Ergebnisses erhöhen und nach Möglichkeit zusätzliche Bereiche abdecken. Die Initiierung eines Durchlaufs kann sowohl zeitgesteuert (reguläre Planung und Fortschreibung von Strategie und IT-Architekturen, mindestens einmal im Jahr) als auch ereignisgesteuert sein (gestartete bzw. laufende Projekte, Umweltänderungen).
Bild 4.11 Entscheidungen zu IT-Architekturen
Im Beispielfall sind in einem ersten Schritt vom Architekturteam die Anforderungen der Fachbereiche (Kunden) und die sich daraus ergebenden Auswirkungen auf die IT-Strategie zu analysieren. Die wesentlichen Treiber für die IT-Strategie werden festgehalten. Danach werden die daraus abgeleiteten Informationsbedürfnisse aufgezeigt. Im nächsten Schritt werden die aktuellen Markttrends analysiert und auf ihre Relevanz für das Unternehmen hin untersucht. Aus all diesen Grundlagen wird dann eine für Fachbereich und IT gemeinsame Vision der strategischen Anforderungen an den IT-Betrieb abgeleitet bzw. fortgeschrieben.
Ausgehend von den strategischen Anforderungen wird im Beispielfall vom Linienmanagement des IT-Bereichs im Rahmen eines Workshops die IT-Strategie der Organisation entwickelt bzw. angepasst. Diese beschreibt die Rolle der IT im sich ändernden Umfeld und liefert übergeordnete Zielsetzungen für alle Bereiche, von der technischen Architektur über anzustrebende Kooperationen bis hin zum Personaleinsatz und zur Personalentwicklung. Ein weiteres Ergebnis des Workshops sind eine eventuell erforderliche Aktualisierung der Q-Policy und die aktuellen Qualitätsziele für das laufende Jahr.
Aufbauend auf den strategischen Anforderungen und der IT-Strategie wird unter Berücksichtigung der aus den Projekten des Unternehmens kommenden Anforderungen die konzeptuelle Architektur entwickelt bzw. in späteren Durchläufen adaptiert:
Ein wesentliches Ergebnis sind die Architekturprinzipien. Diese stellen einen Satz logischer und konsistenter Grundsätze dar, die für alle technologischen Entscheidungen als Leitlinie dienen. Für jedes Prinzip werden die Begründung und die sich daraus ergebenden Auswirkungen dargestellt.
Weiterer Inhalt der konzeptuellen Architektur sind die Definition und Abgrenzung der für das Unternehmen relevanten Domänen – logisch zusammengehörende Teilbereiche der Applikationen, Daten sowie der Infrastruktur (wie beispielsweise Betriebssysteme, Netzwerk oder Anwendungen).
Für jede Domäne sollte es ein von einem Domänenarchitekten geleitetes Domänenteam geben. Dieses
legt Designprinzipien für die Domäne fest,
identifiziert die für die Domäne relevanten Technologien und
beschäftigt sich mit den dafür verfügbaren Standards.
Produkte und deren Lebenszyklus werden festgelegt und darauf aufbauend werden Konfigurationen erarbeitet. Für jede Domäne werden die Ergebnisse in der Domänenarchitektur (als Soll-Architektur) festgehalten.
Diese Architektur wird anschließend mit dem Ist-Zustand abgeglichen und bei entsprechendem Bedarf wird ein Migrationsplan erstellt. Danach erfolgt die Implementierung der erforderlichen Änderungen. Nach erfolgter Implementierung wird die Beschreibung der aktuellen Domäne (Applikationen, Infrastruktur etc.) entsprechend adaptiert, um beim nächsten Durchlauf für den erforderlichen Abgleich zur Verfügung zu stehen.
Es gibt Schnittstellen zu praktisch allen Prozessen, da die strategischen Vorgaben von allen zu berücksichtigen sind. Dies betrifft natürlich vor allem den Systementwicklungsprozess. Weil der Systementwicklungsprozess eine sehr breite Palette an Entwicklungs- und Integrationstätigkeiten abdeckt (beispielsweise Entwicklung und Wartung von Anwendungssoftware, Installation von Systemsoftware und Hardware, Release-Wechsel, Customizing von Standardsoftware, aber auch Rapid Application Development, Entwicklung von Web- und digitalen Lösungen etc.), steht im Normalverfahren auf oberster Ebene ein allgemeines Prozessmodell, das aus verschiedenen Phasen besteht:
Zielanalyse
Entwicklung/Integration
Abnahme
Dieser Umsetzungsprozess aus dem Architekturmanagement wird über einen Projektauftrag oder über eine IT-Anforderung oder einen internen Auftrag angestoßen. Auslöser für den Prozess sind Anforderungen eines Auftraggebers zur Erstellung oder Modifikation eines IT-Systems.
Im Normalverfahren ist zu Beginn des Systementwicklungsprozesses vom beauftragten Systementwickler eine Zielanalyse durchzuführen. Dabei sind folgende Fragen zu klären:
Welche Ziele will der Auftraggeber mit der Anforderung erreichen?
Welche groben inhaltlichen bzw. funktionalen Vorgaben macht der Auftraggeber zur Realisierung seiner Anforderung?
Welche technischen Rahmenbedingungen werden vom Auftraggeber bzw. IT-intern (z. B. durch vorhandene Architekturkonzepte, IT-Infrastruktur und IT-Systeme) vorgegeben?
Welche organisatorischen Rahmenbedingungen sind vorgegeben?
Welche Verfügbarkeit (Kritikalität) der IT-Lösung wird gefordert?
Welche IT-Sicherheitsanforderungen werden vom Auftraggeber bzw. IT-intern vorgegeben?
Welche weiteren Qualitätskriterien (z. B. hinsichtlich Bedienbarkeit, Performanz, Dokumentation, Produktionsfähigkeit) werden vom Auftraggeber bzw. IT-intern vorgegeben?
Was kann die Zielerreichung gefährden (kritische Erfolgsfaktoren, Risikoanalyse)?
Welchen Endtermin für den Einsatz der entsprechenden Lösung fordert der Auftraggeber? Welche Meilensteine und zugehörigen Zwischentermine sind erforderlich?
Welcher Aufwand (IT-Personal und Nicht-IT-Personal) wird für das Vorhaben geschätzt?
Welche Informationen benötigt der Auftraggeber während des Vorhabens?
Die oben genannten Punkte sind in einem Pflichtenheft zu dokumentieren. Insbesondere in IT-Projekten ist jedenfalls ein Pflichtenheft zu erstellen.
Die Phase „Entwicklung/Integration“ als Kernstück des allgemeinen Prozesses enthält grundsätzlich die Teilphasen:
Analyse: Festlegung der detaillierten Anforderungen an das konkrete Vorhaben oder Teilvorhaben
Design: Festlegung der technischen Umsetzung der Anforderungen
Implementierung: Umsetzung der Anforderungen wie im Design vorgegeben
Test: Test des resultierenden IT-Systems oder -Teilsystems
Die Phase „Entwicklung/Integration“ kann abhängig von der konkreten Aufgabenstellung sehr unterschiedlich gestaltet sein: Die vier oben genannten Teilphasen können inkrementell, parallel oder iterativ durchlaufen werden; zusätzliche Teilphasen lassen sich definieren; Teilphasen können wegfallen etc. Der genaue Ablauf wird in verschiedenen Submodellen konkret beschrieben.
Ein Beispiel für ein Submodell stellt die Multi-Tier-Architektur dar. Bei dieser Art der Anwendungsarchitektur wird die Applikation in mehrere diskrete Komponenten aufgeteilt. Meist wird eine Dreischichtenarchitektur (Three-Tier) angewendet, in der in Datenbank, Enterprise-Anwendungslogik und Präsentation (Weboberfläche oder Client) eingeteilt wird.
Beachten Sie:
Mithilfe einer stringenten und effektiven Vorgehensmethodik im Design von IT-Landschaften und eines integrierten, übergreifenden Managements über sämtliche IT-Domänen kann die vorhandene Komplexität der IT-Architektur und der IT-Systeme auf ein optimales Maß reduziert und somit eine Balance aus Effektivität, Effizienz und Flexibilität gefunden und hergestellt werden.
| 4.4.1.2 | Applikationslandschaft planen – Varianten, Methoden |
Ohne strategische Planungsüberlegungen zur IT-Landschaft besteht die Gefahr, dass in IT-Systeme (zum Beispiel Applikationen oder Plattformen) investiert wird, die nicht unbedingt in die „Gesamtlandschaft“ des Unternehmens passen. Erst durch das Festlegen von Standards im Rahmen der IT-Strategieentwicklung und das Setzen von Vorgaben im Architekturmanagement können vorhandene Planungsrisiken ausgeräumt werden. Gleichzeitig kann über das Treffen von Vereinbarungen (mit Business und Anwendern) den vielfältigen Anforderungen zu den Applikationen einer Organisation in hohem Maße Rechnung getragen werden.
Strategische Planungsüberlegungen beginnen heute mit der Planung der Applikationslandschaft. Als Ausgangssituation ist hier oft festzustellen:
Applikationsplanungen erfolgen sporadisch bzw. nach unterschiedlichen Formaten (je nach Anwendungsbereich).
Eine unternehmensweite Applikationsstrategie ist ansatzweise vorhanden.
Um die Applikations-Roadmap up-to-date zu halten, fällt oft ein hoher Aufwand an.
Um Fehlentwicklungen und Probleme zu vermeiden, bietet sich eine Vereinbarung an, dass für die Applikationen der Fachbereiche eine Applikationsplanung dahingehend vorzunehmen, dass
eine laufende Bewertung der Ist-Applikationslandschaft (Life-Cycle Management etc.) vorgenommen wird,
eine abgestimmte Analyse zu neu gewünschten Applikationen erfolgt (in Verbindung mit Demand-Management und Projekt-Portfoliomanagement),
ein fundiertes Roadmapping für die Applikationslandschaft für die nächsten Jahre etabliert werden kann,
eine fundierte Informationsgrundlage für Jahresplanungs-Umsetzungsgespräche mit Kunden (Fachbereichen) gegeben ist.
Festzustellen ist, dass in der Praxis oft folgende Varianten, Aktivitäten, Verfahren und Ergebnisse (Artefakte) zur Applikationsplanung vereinbart werden, um eine ganzheitliche Umsetzung der zuvor skizzierten Teilaktivitäten zu realisieren:
Bild 4.12 Strategische Architekturplanung – Beispiel Applikationsplanung
Um zu abgestimmten Vereinbarungen über die künftig zu nutzenden und zu betreuenden IT-Systeme zu gelangen, ist ein strategisches Planungsdokument hilfreich, welches das avisierte IT-Applikationsportfolio (= Soll-Systemlandschaft) bzw. Projekte enthält, mit denen sich die Ziele bzw. Ziellandschaften erreichen lassen.
| 4.4.2 | Use Case „IT-Konsolidierungsprojekte“ |
Im Rahmen von IT-Konsolidierungsprojekten kann den Zielen reduzierter Gesamtkosten, gesteigerter Service Levels und erhöhter Flexibilität in besonderer Weise Rechnung getragen werden. Wesentliche Ansatzpunkte der IT-Konsolidierung sind Vereinfachung, Standardisierung, Modularisierung und Optimierung der IT-Landschaft.
Dazu empfiehlt sich ein schrittweises Vorgehen, erste Maßnahmen sollten aber rasch eingeleitet werden:
In einem ersten Schritt sollte die vorhandene Hardware-Vielfalt auf Arbeitsplatzebene auf ein vernünftiges Ausmaß zurückgeschraubt werden bzw. ein ausgewogenes Workplace-Konzept entwickelt werden.
Parallel zur Vereinheitlichung der Endgeräte (Endpoints) sollten Serverkonfigurationen entwickelt und standardisiert werden.
Ein weiterer logischer Schritt zur Kosteneinsparung liegt in der Standardisierung der Software- und Netzwerkdienste.
Der eigentliche Weg zur IT-Konsolidierung kann auf verschiedenen Ebenen begonnen werden. Die Wahl des Einstiegspunkts ist dabei abhängig von dem aktuellen Organisationsstand der Infrastruktur und den individuellen Unternehmenszielen. Im Wesentlichen lassen sich folgende Konsolidierungsebenen unterscheiden:
Hardware-Konsolidierung: Dienste, Applikationen und Datenbanken werden möglichst auf wenige, dafür hochverfügbare und dynamische Systeme zusammengeführt. Dies betrifft vor allem Server, Speichersysteme und Netzwerke sowie – damit in Beziehung – auch die Cloud-Optionen.
Applikationskonsolidierung: Hier geht es heute primär um eine stärkere Digitalisierung und Integration der Anwendungssysteme sowie um die Zentralisierung von Funktionalitäten der Anwendungssysteme und ihre Konzentration auf wenige Komponenten (etwa als Microservices).
Datenkonsolidierung: In Unternehmen gibt es Daten, redundante Daten, fehlerhafte Daten und fehlerhafte, redundante Daten. Oft sind sie in unterschiedlichen Datenbanken gespeichert. Über eine Konsolidierung in eine homogene Struktur lassen sich aus all diesen Daten pragmatisch und effizient konsistente Informationen gewinnen. Architekturwerkzeuge (wie etwa Crud) bieten hier gute Ansatzpunkte.
Prozesskonsolidierung: Die IT-Leistungsprozesse (Systemmanagementprozesse, IT-Serviceprozesse) sind zu definieren und zu beschreiben. So lassen sich Optimierungsansätze herausfiltern.
Beachten Sie:
Die Gartner-Group geht davon aus, dass sich mit einheitlichen Anwendungen die IT-Kosten um mehr als 25 % senken lassen. Allerdings kann man mit unflexiblen Standards keinen Wettbewerbsvorteil erzielen. Hier gilt es einen Kompromiss zu finden.
In welchem Umfang in dem jeweiligen Anwendungsfall Konsolidierungsaktivitäten nötig sind, hängt natürlich von der spezifischen Ausgangssituation der Anwender ab. In der Regel wird eine umfassende IT-Konsolidierung nur durch ausdrückliche Inangriffnahme eines Projekts erfolgreich realisiert werden können.
Fazit:
Im Rahmen von IT-Konsolidierungsprojekten kann den Zielen reduzierter Gesamtkosten, gesteigerter Service-Level und erhöhter Flexibilität Rechnung getragen werden. Wesentliche Stoßrichtungen der IT-Konsolidierung sind Vereinfachung, Standardisierung, Modularisierung und Optimierung der IT-Landschaft.
| 4.4.3 | EA-Use-Case: Business Demand Management unterstützen |
Typische Use Cases, die vor allem aus Sicht der Business Architecture von Relevanz sind, betreffen das Business Demand Management sowie das Digitalisieren von Arbeits- und Geschäftsprozessen. Nachfolgende Zusammenstellung zeigt typische Ausgangssituationen, die durch unternehmensweites Demand Management erschließbaren Potenziale sowie den Nutzen für Unternehmen, Fachbereiche und IT.
Tabelle 4.4 EA-Use-Case: Business Demand Management unterstützen
EA-Use-Case/Merkmale |
Feststellungen im Anwendungskontext |
Ausgangssituation |
|
Potenziale durch unternehmensweites Architekturmanagement |
|
Nutzen für Unternehmen, Fachbereich und IT |
|
| 4.4.4 | EA-Use-Cases mit Fokus „Data Architecture“ |
Typische Use Cases, die vor allem aus Sicht der Data Architecture von Relevanz sind, betreffen Information Life Cycle Management sowie den Aufbau eines Master-Datenmanagements. Die nachfolgende Abbildung zeigt typische Ausgangssituationen für ein Information Life Cycle Management, die durch unternehmensweites Architekturmanagement erschließbaren Potenziale sowie den Nutzen für Unternehmen, Fachbereiche und IT.
Tabelle 4.5 EA-Use-Case: Information Life Cycle Management
EA-Use-Case/Merkmale |
Feststellungen im Anwendungskontext |
Ausgangssituation |
|
Potenziale durch unternehmensweites Architekturmanagement |
|
Nutzen für Unternehmen, Fachbereich und IT |
|