Einsatz von Komplexitätsmodellen zur Unterstützung von Bebauungsplanung und Architekturtransformation

Transkript

1 Dr. Christian Schmidt Einsatz von Komplexitätsmodellen zur Unterstützung von Bebauungsplanung und Architekturtransformation 8. Jahrestagung Enterprise Architecture Berlin,

2 Die K-Frage des Unternehmensarchitekten Was ist der richtige Umgang mit Komplexität? Welche Rolle spielt Komplexität im Zielsystem des Architekten? Wie kann Komplexität gemessen werden? Welche Stakeholder interessieren sich für Komplexitätsanalysen? Welche Einsatzszenarien gibt es für Komplexitätskennzahlen? Welche Erfahrungen gibt es im Kontext der Bebauungsplanung? Was ist zu beachten und welche Fehler sind zu vermeiden? Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

3 Über uns Unsere Tätigkeitsfelder 1. Entwicklung EAM 2. Enterprise Architecture 3. IT-Strategie und IT- Office Governance Hilfe zur Selbsthilfe Erweitern Sie Ihren Radius Für die optimale Ausrichtung Ihrer IT Aufbau von EAM- Funktionen EAM-Health Checks / Neuausrichtung von EAM-Funktionen Entwicklung der Geschäftsarchitektur Einführung von EAM-Tools Schulung von Architekten Erfassung von Ist- Landschaften Durchführung von Bebauungsplanungen Steuerung von Transformationsprojekten Entwicklung technischer Standards Entwicklung von Lösungsarchitekturen Implementierung von Governance-Frameworks (insb. COBIT) Entwicklung der IT-Strategie Aufbau des Portfoliomanagements Entwicklung der IT- Organisation Implementierung von Risikomanagement-Frameworks Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

4 Über uns Mitgliedschaften und Forschungskooperationen Organisationen: Communities: EA Community Rhein-Main Forschungspartner: Forschungsprojekte: CEAR Complexity in Enterprise Architectures CALM³ Complexity of Application Landscapes Models, Measures, Management Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

5 Über uns Veröffentlichungen unserer Berater Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

6 Agenda 1. Komplexität im Zielsystem des Architekten 2. Verfahren zur Messung von Komplexität 3. Anwendung am Beispiel der Bebauungsplanung 4. Fazit und Empfehlungen Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

7 Die K-Frage des Unternehmensarchitekten Was ist der richtige Umgang mit Komplexität? Manche Zeitgenossen sehen ihre Berufung darin, den letzten Winkel ihrer Landschaft zu erforschen und auch das kleinste Tool zu inventarisieren Andere dagegen halten es lieber mit dem Vogel-Strauss: was ich nicht sehen kann, tut mir nicht weh und davon will ich auch nichts wissen CIO Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

8 Fakten zum Thema IT-Komplexität Beobachtungen aus dem Projekt-Alltag Ein großes Industrieunternehmen besitzt über Geschäftsanwendungen Eine große Bank setzt mehr als 20 verschiedene DBMS-Versionen ein Komplexität ist überall Eine Universalbank schaltet wegen unklaren Seiteneffekten seit Jahren keine Batch-Jobs ab Der Vorstand einer Versicherung wurde entgegen der IT-Strategie mit ipads ausgestattet Der Kapitalmarktbereich einer Landesbank entwickelte sein eigenes Data Warehouse Komplexität entsteht ständig neu Bei einem Audit identifizierte eine Rückversicherung 50 bisher unbekannte IDV-Anwendungen Das EA-Tool einer Versicherung erreichte nach einem Jahr das 3-fache der erwarteten Größe Während eines Projektes verdoppelte sich die Zahl der bekannten Ist-Anwendungen Komplexität wird häufig unterschätzt Zwei auf einer Konferenz vertretene Architekten eines Pharma-Konzerns kannten sich nicht Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

9 Das Gesetz der steigenden Komplexität Komplexität steigt sofern dies nicht aktiv verhindert wird Nach dem Zweiten Gesetz der Software-Evolution steigt die Komplexität eines im Einsatz befindlichen Software-Systems mit der Zeit an, wenn keine aktiven Maßnahmen dagegen ergriffen werden [Le97]. Es ist davon auszugehen, dass das Gesetz auch auf der Ebene der Unternehmensarchitektur gilt [SB11]. Komplexität Bestandteile IT- Komplexitäts- Überschuss Notwendige IT-Komplexität Geschäfts- Komplexitäts- Überschuss Treiber Mergers & Acquisitions Lokale Optimierung / Politik Entwicklung der Technologie / IT-Industrie Mergers & Acquisitions Lokale Optimierung / Politik Notwendige Geschäfts- Komplexität Geschäftsmodell Regulierung / Aufsicht siehe auch [Ru13] Zeit Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

10 Die zentrale Rolle von Komplexität Treiber und Auswirkungen von IT-Komplexität Die TOP 5 Treiber und Auswirkungen von IT-Komplexität nach einer Umfrage innerhalb der CALM3- Arbeitsgruppe [Sc13]. 1. Lokale Optimierungsstrategien der Fachbereiche 1. Anstieg von Kommunikationsaufwänden 2. Steigende Geschäfts- Komplexität 2. Anstieg von Entwicklungskosten 3. Steigende gesetzliche Regulierung IT Komplexität 3. Anstieg von Wartungskosten 4. Technologischer Fortschritt 4. Anstieg der Umsetzungszeit neuer Anforderungen 5. Kurzfristige Optimierungsstrategien der Fachbereiche CALM³ Complexity of Application Landscapes Models, Measures, Management 5. Anstieg durchschnittlicher Einarbeitungszeit Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

11 Business Architect IT Architect Die Rolle des Unternehmensarchitekten Aktives Management des Komplexitätsüberschusses Aufgrund der negativen Wirkungen sollte eine Architektur grundsätzlich nur so komplex wie nötig sein. Es ist eine Kern-Aufgabe des Architekten, den Komplexitätsüberschuss zu managen. Komplexität Bestandteile IT- Komplexitäts- Überschuss Notwendige IT-Komplexität Instrumente Bebauungspläne Books of Standards Referenz- Architekturen Governance- Prozesse etc. Geschäfts- Komplexitäts- Überschuss Notwendige Geschäfts- Komplexität Shared Service Centers / Zentralisierung Standard -Prozesse Sourcing etc. Dabei sind allerdings auch nicht-funktionale Anforderungen (wie Hersteller-Unabhängigkeit, Sicherheit) und spezifische Kontextfaktoren (wie z. B. Geschäftsmodell, Sourcing-Strategie) zu berücksichtigen. Zeit Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

12 Das Komplexitäts-Kontinuum Die richtige Komplexität am richtigen Platz Minimale Komplexität ist häufig weder notwendig noch angemessen. Stattdessen sollte ein nach Architektur-Domänen differenziertes Ziel-Niveau für die Komplexität definiert werden. geringe Komplexität hohe Komplexität geringere Betriebskosten geringere Wartungskosten geringere Beschaffungskosten höhere Agilität / geringerer Änderungsaufwand etc. BD1 BD2 Business Architecture BD3 BD4 AD1 AD2 Application Architecture AD3 AD4 TD1 TD2 Technical Architecture TD3 TD4 höherer Kunden- Wert höherer Geschäftswert höhere Robustheit geringere Herstellerabhängigkeit etc. Beispielsweise kann in differenzierenden Front-End-Domänen ein höheres Komplexitäts-Niveau toleriert werden als im nicht-differenzierenden Backend-Bereich. Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

14 Die verschiedenen Gesichter der Komplexität Stakeholder und ihr Verständnis von Komplexität Komplexität ist ein unscharfer Begriff. Unterschiedliche Stakeholder verbinden damit meist unterschiedliche Vorstellungen und Aspekte. Chief Information Officer (CIO) Darstellung exemplarisch Head of Solution Development Anzahl Anwendungen Anzahl Entwicklungslinien Anzahl Schnittstellen Anzahl Services Anzahl Vendor-Beziehungen Enterprise Architect Line of Business Manager Anzahl Produkte Anzahl Prozessvarianten Software Developer Anzahl Frameworks Lines of code Applikationen pro Capability Anzahl Plattformen Anzahl Schnittstellen Head of Operations Anzahl Plattformen Anzahl Abhängigkeiten Domain Architect Anzahl Applikationen (innerhalb der Domäne) Anzahl Interfaces (innerhalb der Domäne) Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

15 Traditionelle Ansätze zur Messung von Komplexität Einsatz spezifischer Komplexitätsindikatoren Bestehende Ansätze zur Messung von Komplexität basieren zumeist auf einer Menge von spezifischen Komplexitätsindikatoren. Hieraus ergeben sich eine Reihe von Problemen: Wie kann die Vollständigkeit gewährleistet werden? Wie können die Daten verglichen werden? Wie können Messwerte aggregiert werden? Welche Aussagekraft besitzen Durchschnittswerte? Stehen Daten in der benötigten Form zur Verfügung? Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

16 Generisches Verfahren nach CEAR Allgemeine Definition struktureller Komplexität Nach einer Literaturanalyse (47 Beiträge aus knapp Publikationen in internationalen Journalen / Konferenzen) wird Komplexität in der Literatur mehrheitlich mit folgenden Aspekten assoziiert [SWK13]: Busines Architecture Application Architecture Technical Architecture Elemente (T) Beziehungen (R) Anzahl (N) Heterogenität (H) N T N R (43 Nennungen) (24 Nennungen) H T H R (31 Nennungen) (10 Nennungen) vgl. auch [SM03] Die strukturelle Komplexität einer Unternehmensarchitektur kann entsprechend definiert werden als ein Tupel C EA = (N T, H T, N R, H R ). Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

17 Anteil Quantifizierung von Heterogenität Heterogenität als statistische Eigenschaft Die Quantifizierung von Komplexität ist damit im Wesentlichen auf die Quantifizierung von Heterogenität zurückgeführt. Definition: Heterogenität ist allgemein definiert als die Verschiedenartigkeit von Elementen oder Beziehungen eines Systems hinsichtlich bestimmter Charakteristika (Attributausprägungen). Heterogenität kann als statistische Eigenschaft aufgefasst werden und in Form von Häufigkeitsverteilungen beschrieben werden. 60% 50% Die Interpretation als Häufigkeitsverteilung ermöglicht die Anwendung erprobter statistischer Maßzahlen. Insbesondere können die in verschiedenen Bereichen der Wissenschaft eingesetzten und gut untersuchten Konzentrationsmaße adaptiert werden (z. B. Herfindahl-Hirschmann- Index, Simson-Index, Entropie-Maß) [Wi12]. 40% 30% 20% 10% 0% DB/2 MS SQL Oracle Sybase Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

18 Quantifizierung von Heterogenität Anforderungen an geeignete Kennzahlen Anforderung Szenario A Szenario B Erwartetes Ergebnis 100% 100% Zusätzliche Attributwerte 50% 0% MS SQL Oracle 50% 0% MS SQL Oracle DB/2 Het(A) < Het(B) Verschiebung in der Klassifikation 100% 50% 0% MS SQL Oracle 100% 50% 0% MS SQL Oracle Het(A) < Het(B) Auswirkung kleiner Zahlen 100% 50% 0% MS SQL Oracle 100% 50% 0% MS SQL Oracle DB/2 Het(A) < Het(B) Keine Auswirkung proportionaler Änderungen MS SQL Oracle MS SQL Oracle Het(A) = Het(B) vgl. [SWK13] Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

19 Quantifizierung von Heterogenität Das Entropie-Maß Die Anforderungen werden am besten durch das von Shannon eingeführte Entropie-Maß erfüllt [Sh48] [JB79] [SWK13]: 60% 50% 40% 30% EM = 1.12 n EM = f i ln 1 f i i=1 with f i = x i x j n j=1 20% 10% 0% DB/2 MS SQL Oracle Sybase Die Interpretation wird erleichtert durch das sogenannte Numbers Equivalent, welches die äquivalente Zahl gleichverteilter Werte wiedergibt: 60% 50% 40% 30% EM = 1.10 EM A = e EM 20% 10% EM A = e 1.12 = % DB/2 MS SQL Oracle Sybase Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

20 Operationalisierung Modellanwendung auf der Basis von EA-Repositories Eine sinnvolle Modellanwendung erfordert eine weitergehende Differenzierung von Element- und Beziehungstypen sowie die Verfügbarkeit entsprechender Modell-Daten. EA Metamodel aus: [TOG13] EA Repository Architektur-Repositories mit ihrem anhand von Metamodellen strukturierten Datenbestand bilden hierfür die ideale Grundlage [SWS13]. Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

21 Komplexitätsaspekte Typen von Komplexitätsaspekten in Metamodellen Typ 1: Elementtypen ET 1 Attr. 1 Attr. 2 Anzahl der Elementinstanzen eines Typs Heterogenität der Elementinstanzen eines Typs hinsichtlich bestimmter (eigener) Merkmale Typ 2: Relationstypen (Spezialfall von Typ 3) ET 1 Attr. 1 Attr. 2 ET 2 Attr. 1 Attr. 2 Anzahl der Relationsinstanzen eines Typs Heterogenität der Relationsinstanzen eines Typs hinsichtlich bestimmter Merkmale der an der Beziehung beteiligten Elementtypen Typ 3: Pfadtypen ET 1 Attr. 1 Attr. 2 ET Attr. 1 Attr. 2 ET n Attr. 1 Attr. 2 Anzahl der Relationsinstanzfolgen eines Typs Heterogenität der Relationsinstanzfolgen eines Typs hinsichtlich bestimmter Merkmale der auf dem Pfad liegenden Elementtypen [SWS13] Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

22 Beispiel: Komplexitätsaspekt vom Typ 1 Anwendungen nach Herstellern SAP FI Elena SAP FI SAP FS-CD XIA ResQ XIA ResQ 100% 80% 60% 40% 20% Standardisierung 100% 80% 60% 40% 20% 0% 0% SAP SD TW CG SAP SD TW N = 4 H = 1.39 N = 4 H = 1.04 Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

23 Beispiel: Komplexitätsaspekt vom Typ 1 Anwendungen nach Herstellern SAP FI Elena SAP FI Elena XIA ResQ ResQ 100% 80% 60% 40% 20% Deaktivierung 100% 80% 60% 40% 20% 0% 0% SAP SD TW CG SAP TW CG N = 4 H = 1.39 N = 3 H = 1.10 Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

24 Beispiel: Komplexitätsaspekt vom Typ 2/3 Anwendungsnutzung nach Anwendungen SAP FI UK Branch SAP FI UK Branch XIA DK Branch XIA DK Branch 100% 80% 60% 40% 20% Entflechtung 100% 80% 60% 40% 20% 0% 0% SAP FI XIA SAP FI XIA N = 4 H = 0.69 N = 2 H = 0.69 Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

25 Beispiel: Komplexitätsaspekt vom Typ 2/3 Anwendungsnutzung nach Anwendungen SAP FI UK Branch SAP FI UK Branch XIA DK Branch XIA DK Branch 100% 80% 60% 40% 20% Konsolidierung 100% 80% 60% 40% 20% 0% 0% SAP FI XIA SAP FI XIA N = 2 H = 0.69 N = 2 H = 0 Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

27 Anwendungsbeispiel Einsatz im Rahmen der Zielarchitekturplanung [SWS13] Projektsteckbrief Gegenstand: Branche: Bebauungsplanung Kern-Landschaft Spezialversicherung Zeitraum: Mai Dez Treiber: Ziele: Methodik: hohe Redundanz, mangelnde Akzeptanz von Kernsystemen, extensiver Einsatz von End- User-Applikationen (Access, Excel, etc.) Eliminierung von End-User-Applikationen, technologische Homogenisierung und Ausrichtung auf Gruppen-Standards, Einführung zentraler Integrationsplattform TOGAF ADM / ADD [TOG13] Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

28 Technical Architecture Application Architecture Business Architecture Anwendungsbeispiel Metamodell des Anwenderunternehmens Line of Business Business Function Organization Unit Application System Information Entity Application Domain Application Component Application Interface Platform Technical Domain Infrastructure System Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

29 Technical Architecture Application Architecture Business Architecture Anwendungsbeispiel Metamodell und betrachtete Komplexitätsaspekte Line of Business Business Function Organization Unit Application System 1 6 Information Entity Application Domain 8 Application Component 7 Application Interface 2 Platform Technical Domain Infrastructure System Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

30 Betrachtete Komplexitätsaspekte Interpretation von Anzahl und Heterogenität (1) Komplexitätsaspekt Interpretation N Interpretation H 1 Application System nach Application Vendor Anzahl aller vorhandenen (produktiven) Anwendungen Konzentration der Anwendungen nach Herstellern (Typ 1) Sinkt mit der Außerbetriebnahme von Anwendungen Sinkt mit Verlagerung von Spezialzu Standard-Anbietern 2 Application Interface nach Interface Type Anzahl aller vorhandenen Applikationsschnittstellen Konzentration der Schnittstellen nach Schnittstellen-Technologie (Typ 1) Sinkt mit der Außerbetriebnahme von Schnittstellen Sinkt mit Verlagerung von Spezialzu Standard-Technologien 3 Function Implementation nach Application Name (Typ 2) Anzahl der Funktions-Implementierungen durch Applikationen Sinkt mit dem Rückbau von Funktions-Implementierungen Konzentration der Funktions-Impletierung durch Anwendungen Sinkt mit Funktions-Verlagerung von Rand- zu Kern-Anwendungen 4 Application Usage nach Application Name Anzahl der Nutzung von Applikationen durch Org. Units Konzentration der Anwendungsnutzung nach Anwendungen (Typ 2) Sinkt mit der Rückführung der Anwendungsnutzung in Org. Units Sinkt mit Verlagerung von lokalen zu globalen Anwendungen Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

31 Betrachtete Komplexitätsaspekte Interpretation von Anzahl und Heterogenität (2) Komplexitätsaspekt Interpretation N Interpretation H 5 LoB Support nach Application Name Anzahl der Unterstützung von Business Lines durch Anwendungen Konzentration der LoB- Unterstützung nach Anwendungen (Typ 2) Sinkt mit der Rückführung der Unterstützung von LoBs Sinkt mit Verlagerung von LoB-spezifischen zu globalen Anwendungen 6 Information Usage nach Application Name Anzahl der Informationsobjekt- Nutzungen durch Applikationen Konzentration der Datennutzung nach Applikationen (Typ 2) Sinkt mit der Einschränkung der Datennutzung durch Applikationen Sinkt mit Verlagerung von Randzu integrierten Kern-Systemen 7 Interface Usage nach Interface Name Anzahl der Schnittstellen-Nutzung durch Applikationen Konzentration der Schnittstellennutzung nach Schnittstellen (Typ 2) Sinkt mit der Reduktion der Schnittstellen-Nutzung Sinkt mit Verlagerung von Spezialzu Standard-Schnittstellen / Services 8 Platform Usage nach Platform Name Anzahl der Plattform-Nutzung durch Anwendungen Konzentration der Plattform- Nutzung nach Plattformen (Typ 3) Sinkt mit der Reduktion der Plattform-Nutzung durch Applikationen Sinkt mit Verlagerung von Spezialauf Standard-Plattformen Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

32 Technical Architecture Application Architecture Business Architecture Ergebnisse Veränderung der Komplexitätskennzahlen (Ist vs. Ziel) Line of Business Business Function Organization Unit -54% -20% % -19% -32% -20% -55% -21% 1 Application System -34% -27% 68% 6 7 Information Entity Application Interface -3% 2-80% -7% 8 7% -18% Legende Platform N (delta in %) H (delta in %) Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

33 Ergebnisse Interpretation der Veränderungen (1) Komplexitätsaspekt Werte Ist / Ziel Interpretation 1 Application System nach Application Vendor (51; 3,90) (23; 3,08) Eliminierung von End-User-Applikationen (EUC) und Sonderverarbeitungen führt zu Reduktion von N. (Typ 1) H bleibt hoch, weil Individualanwendungen weiterhin tragende Rolle spielen. 2 Application Interface nach Interface Type (40; 3,36) (39; 0,66) Schnittstellenkonsolidierung und Einführung neuer Schnittstellen halten sich die Waage. (Typ 1) Einführung zentraler Integrationsplattformen (EAI / ETL) führt zu signifikanter Reduktion von H. 3 Function Implementation nach Application Name (Typ 2) (148; 3,09) (108; 2,50) Funktionale Entflechtung (v. a. im Technical Accounting) führt zu deutlicher Reduktion von N. Zentralisierung der Funktionalität in wenigen Kernsystemen führt zu reduziertem H. 4 Application Usage nach Application Name (65; 3,88) (44; 3,12) Anwendungskonsolidierung (insb. EUC) führt allgemein zu Reduktion von N. (Typ 2) Eliminierung von lokalen Anwendungen (u. a. GL) bedingt Reduktion von H (Standortkonsolidierung). Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

34 Ergebnisse Interpretation der Veränderungen (2) Komplexitätsaspekt Werte Ist / Ziel Interpretation 5 LoB Support nach Application Name (91; 3,90) (42; 3,11) Anwendungskonsolidierung (insb. EUC) führt allgemein zu Reduktion von N. (Typ 2) Eliminierung LoB-spezifischer Applikationen (z. B. im Exposure Management) führt zu Reduktion von H. 6 Information Usage nach Application Name (182; 3,33) (120; 2,43) Anwendungskonsolidierung und Daten-Entflechtung führen zu Reduktion von N. (Typ 2) Konzentration der Datennutzung in Kernanwendungen / Reporting führt zu Reduktion von H. 7 Interface Usage nach Interface Name (40; 3,69) (67; 3,45) Einführung neuer Anwendungen und Schnittstellen (Automatisierung) bedingt Anstieg von N. (Typ 2) Stärkere Schnittstellen-Wiederverwendung bedingt Reduktion von H. 8 Platform Usage * nach Platform Name (29; 2,18) (31; 1,78) Einführung neuer Anwendungen (z. B. CRM, Solvency II) bedingt leichten Anstieg von N. (Typ 3) Techn. Standardisierung führt zu deutlicher Reduktion der von H. *) ohne Berücksichtigung von Client-Plattformen Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

36 Lessons Learned Bewertung und Einsatzerfahrungen Die Ergebnisse der Modellanwendung konnten die qualitativen Einschätzungen der beteiligten Architekten sehr gut bestätigen und untermauern. Insgesamt wurde das Verfahren wie folgt beurteilt: Vorteile: ganzheitlicher / multidimensionaler Ansatz vollständige Abdeckung aller Metamodell- Aspekte flexible Anwendung auf allen Architektur- Ebenen und Detail-Stufen incl. Drill-Down einheitliche Interpretation und vereinfachte Aggregation der Kennzahlen vollständige Metamodell- und Tool- Neutralität einfache Anwendung auf Basis verfügbarer Architektur-Daten höhere Genauigkeit durch Verwendung von Konzentrationsmaßen Nachteile / beim Einsatz zu beachten: Fokus ausschließlich auf struktureller Komplexität der für den Umgang mit Komplexität wichtige Aspekt der Modularität ist schwer abzubilden Komplexitätsaspekte müssen sorgfältig definiert und interpretiert werden Es besteht das Risiko, Komplexität aus dem betrachteten Modellausschnitt heraus zu optimieren (z. B. durch Verlagerung in die Subsystemebene) globale Minimierung kann zu lokalem Anstieg der Komplexität führen (kann aber durch Drill-Down-Anwendung erkannt und entsprechend behandelt werden) Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

37 Mögliche Erweiterungen Ergänzung um Kennzahlen aus der Netzwerkanalyse Kennzahlen aus dem Bereich der Netzwerkanalyse können eine sinnvolle Ergänzung des vorgestellten Verfahrens darstellen [SF12]. Sie eignen sich insb. für die Analyse von Kommunikationsbeziehungen zwischen aktiven Systemelementen (z. B. Anwendungen und Schnittstellen). Zentralität Nähezentralität: kürzeste Verbindung eines Knotens zu allen anderen Knoten Zwischenzentralität: Anzahl kürzestester Verbindungen, die über einen Knoten laufen Eigenvektorzentralität: Ausmaß, in dem ein Knoten mit anderen zentralen Knoten verbunden ist Modularität Modularität: Anzahl Kanten, die in Gruppen fallen minus der erwarteten Anzahl in einem äquivalenten Netzwerk mit zufälligen Kanten Cluster-Koeffizient: durchschnittlicher Anteil der Nachbarn eines Knotens, die ebenfalls Nachbarn sind Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

38 Anwendungsszenarien Mögliche Einsatzfelder für Komplexitätsanalysen 1. Entscheidungsunterstützung / Simulation bei (größeren) Architektur-Entscheidungen (z. B. Bebauungsplanung und Architekturtransformation) 2. Vergleichende Analysen innerhalb einer Organisation (z. B. zur Erklärung von Kosten- und Flexibilitäts-Unterschieden) 3. Unternehmensübergreifende Architektur-Benchmarkings (in Ergänzung zu bestehenden Kosten-Benchmarkings, etc.) 4. Systematische Zielwertplanung als Bestandteil einer übergreifenden kontinuierlichen Architektur-Steuerung (z. B. differenziert nach Architekturebenen und Domänen) 5. Informationsbereitstellung für das IT-Risikomanagement bzw. das Management operationeller Risiken (Komplexitätsmodelle und Kennzahlen) Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

39 Allgemeine Empfehlungen Einsatz von Komplexitätsmodellen 1. Ausrichtung an Stakeholdern die Stakeholder für Komplexitätsanalysen und ihre jeweiligen Interessen müssen von Anfang an klar identifiziert werden die Kennzahlen-Ermittlung ist auf die Anforderungen der Stakeholder auszurichten Komplexitätsanalysen sollten nicht losgelöst von konkreten Fragestellungen / Treibern durchgeführt werden insb. vergleichende Ist-Analysen (z. B. zwischen Domänen) sollten nur bei klarem Top-Management-Mandat angestellt werden Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

40 Allgemeine Empfehlungen Einsatz von Komplexitätsmodellen 2. Konsequentes Daten-Management das Reporting sollte ausschließlich auf dem Datenbestand des EAM-Tools aufsetzen und möglichst vollständig automatisiert werden alle Stakeholder müssen über die Auswirkungen der Rohdaten auf die Kennzahlen informiert sein und eine Möglichkeit haben, diese zeitnah zu aktualisieren es muss eine einheitliche und verbindliche Lösung für den Umgang mit fehlenden Daten (Missing Data) definiert werden Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

41 Allgemeine Empfehlungen Einsatz von Komplexitätsmodellen 3. Qualitative Analyse und Interpretation Komplexitätsbetrachtungen erfordern eine gründliche Analyse, die nur von qualifizierten Architekten durchgeführt werden kann dazu sind oft Drill-Down-Schritte oder ergänzende Betrachtungen notwendig Analyse-Ergebnisse sollten immer qualitativ aufbereitet und interpretiert werden (im Sinne eines Berichts) Komplexitätskennzahlen sollten niemals alleinige Basis für Architektur- Entscheidungen sein Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

42 Allgemeine Empfehlungen Einsatz von Komplexitätsmodellen 4. Kompensation für lokalen Komplexitätsanstieg die globale Minimierung von Komplexität kann lokal zu gegenteiligen Effekten führen so steigen insb. bei Anwendungs- Konsolidierungen meist die Abhängigkeiten des Ziel-Systems und damit auch der Abstimmungs- und Veränderungsaufwand dies sollte durch entsprechende Analysen (z. B. Drill-Down) im Vorfeld erkannt werden für den Erfolg der Umsetzung ist eine rechtzeitige Kommunikation der Veränderungen und eine Bereitstellung zusätzlicher Ressourcen essentiell Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

43 Allgemeine Empfehlungen Einsatz von Komplexitätsmodellen 5. Vom Business- zur IT-Architektur im Interesse maximaler Effektivität sollten Komplexitätsoptimierungen (soweit möglich) zunächst beim Business ansetzen dies erfordert allerdings ein entsprechendes Bewusstsein sowie Handlungsbereitschaft auf Seiten des Business (insb. des Top- Managements) ein umfassender Ansatz für das Management der Geschäftsarchitektur ist hierfür der beste Hebel Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

44 Ausblick Es gibt noch viel zu tun A long way of research ahead but the time seemed right to make a start Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

45 Literatur [IEE11] [JB79] [Le97] [Ro79] [Ru13] [SB11] [Sc13] IEEE Computer Society (Hrsg.): Systems and Software Engineering Architecture Description (ISO/IEC/IEEE 42010:2011). IEEE Computer Society, New York, Jacquemin, A. P.; Berry, C. H.: Entropy Measure of Diversification and Corporate Growth. The Journal of Industrial Economics (27:4), 1979; S Lehman, M. M.: Laws of software evolution revisited. In: (Montangero, C. Hrsg.): Software Process Technology Proceedings of the 5th European Workshop on Software Process Technology (EWSPT 96), Nancy, Springer, Berlin; S Ropohl, G.: Eine Systemtheorie der Technik Zur Grundlegung der Allgemeinen Technologie. Carl Hanser, München, Rutz, U.: IT Complexity Commerzbank Overview on Commerzbank Initiative. Präsentation EAMKON Konferenz, Stuttgart, April Schmidt, C.; Buxmann, P.: Outcomes and Success Factors of Enterprise IT Architecture Management: Empirical Insight from the International Financial Services Industry. European Journal of Information Systems (20), 2011; S Schneider, A.: CALM3 Workshop 3. Präsentation beim 3. Workshop CALM3 (Complexity of Application Landscapes Models, Measures, Management). Technische Universtität München, August [Sh48] Shannon, C. E.: A Mathematical Theory of Communication. Bell System Technical Journal, 27, 1948; und [SM03] Schneberger, S. L.; McLean, E. R.: The Complexity Cross: Implications for Practice. Communications of the ACM, 46 (9), 2003; S Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

46 Literatur [SF12] Simon, D.; Fischbach, K.: IT Landscape Management Using Network Analysis. In: (Poels, G. Hrsg.): Enterprise Information Systems of the Future, 6th IFIP WG 8.9 Working Conference, CONFENIS 2012, Springer, 2012; S [St73] Stachowiak, H.: Allgemeine Modelltheorie. Springer, Wien, New York, [SWS13] [SWK13] Schmidt, C.; Widjaja, T.; Schütz, A.: Messung der Komplexität von IT-Landschaften auf der Basis von Architektur-Metamodellen: Ein generischer Ansatz und dessen Anwendung im Rahmen der Architektur- Transformation. Informatik 2013 Beiträge der 43. Jahrestagung der Gesellschaft für Informatik. Köllen Verlag, Bonn. Schütz, A.; Widjaja, T.; Kaiser, J.: Complexity in Enterprise Architectures Conceptualization and Introduction of a Measure from a System Theoretic Perspective. European Conference on Information Systems (ECIS), Utrecht, [TOG13] The Open Group (Hrsg.): TOGAF (The Open Group Architecture Framework) V [Wi12] Widjaja, T.; Kaiser, J.; Tepel, D.; Buxmann, P.: Heterogeneity in IT Landscapes and Monopoly Power of Firms: A Model to Quantify Heterogeneity. International Conference on Information Systems (ICIS), Orlando, Dr. Christian Schmidt Einsatz von Komplexitätsmodellen 8. Jahrestagung Enterprise Architecture 24. September

47 Vielen Dank für Ihre Aufmerksamkeit