ESA Klausur

🔵 "The fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution." 🟡 Merksatz Dozent: Architektur ist viel mehr als Hardware + Software — gerade das schwer beherrschbare "environment" gehört dazu.

🔵 (1) Konzeptionelles Framework, um logische, physische oder organisatorische Strukturen zu beschreiben — heutige UND zukünftige. (2) Menge von Richtlinien und Direktiven, um ein konsistentes Ganzes zu gewährleisten. 🔵 Einflussfaktoren: Organisation, Entscheidungskompetenz, Unternehmensrichtlinien, Managementanforderungen, Unternehmenspolitik/Machtkämpfe.

🔵 Unternehmensarchitektur = Klammer über: (1) Geschäftsarchitektur (Geschäftsmodelle, Geschäftsprozesse) und (2) IT-Unternehmensarchitektur (von IT-Strategie bis in die operativen Systeme). 🔵 Die IT-Unternehmensarchitektur teilt sich in: Architektur der Informationssysteme (= Anwendungsportfolio) und Architektur der Infrastruktur. (Literatur: Keller)

🔵 WAHR. Das Anwendungsportfolio = Architektur der Informationssysteme und ist Teil der IT-Unternehmensarchitektur, die wiederum Teil der Unternehmensarchitektur ist.

🔵 1) Strategie (IT-Strategie aus Business-Strategie abgeleitet) • 2) Geschäftsarchitektur (Geschäftsmodell + Geschäftsprozessmanagement) • 3) Facharchitektur / Informationsarchitektur (Bebauungspläne, Anwendungsportfoliomanagement) • 4) Anwendungsarchitektur (Projektarchitektur, Management der Softwareplattformen) • 5) Basis-/IT-Infrastruktur (System- und Infrastrukturarchitektur). 🟡 Dozent: "Daraus baue ich definitiv eine Klausurfrage."

🔵 Strategie + Geschäftsarchitektur → Enterprise-Architekt • Facharchitektur → Subject Matter Expert (SME) • Anwendungsarchitektur → SME / Projekt- bzw. Lösungsarchitekt • Basis-/IT-Infrastruktur → technischer Architekt / Solution Architect. 🔵 Die Grenzen sind bewusst unscharf und überlappend.

🔵 Die Ebenen begrifflich kennen und richtig anordnen: Strategie ganz oben, Technik als Basis ganz unten — "dann haben Sie schon zwei von fünf Ebenen sicher, und es geht nur noch um die richtige Anordnung der drei weiteren". 🔵 Möglich als offene Frage ("Malen Sie die Pyramide auf und ordnen Sie die Rollen zu") oder als Zuordnungs-/MC-Frage. 🔵 Dieselbe Grob-ins-Feine-Logik findet sich in Zachman, SABSA und TOGAF wieder.

🔵 HORIZONTAL: sehr tief in der ganzen Breite EINES Themenfeldes — z.B. Netzwerkarchitektur. VERTIKAL: ein Thema über den kompletten Technologie-Stack hinweg, dafür auf höherem Level — z.B. Sicherheitsarchitektur. 🔵 Konsequenz: unterschiedliche Architekturrollen; "der eine Architekt, der alles kann" funktioniert nicht.

🔵 Niemand weiß, was vorhanden ist und was Systeme können • funktionale Redundanzen (dasselbe System mehrfach im Haus) • fehlende Kommunikationsschnittstellen • Unmut und Ineffizienz • steigende Kosten • sinkende Geschwindigkeit • keine Datenqualität. 🟡 Pointe des Dozenten: "Ich habe auf dieser Folie nicht ein einziges Mal das Wort Sicherheit in den Mund genommen."

🔵 Stabilität (Servicemanagement, Kontinuität, geringe Synchronität) → Effizienz (IT-Konsolidierung, integriertes Service Management) → Flexibilität (adaptive Architektur und Prozesse, Management nahezu in Echtzeit). 🔵 Zwei Achsen: Flexibilität des Geschäfts (reagieren → antizipieren → proaktiv → First Mover) und Synchronisation von IT und Geschäft.

🟡 Zitat von George E.P. Box (britischer Statistiker). 🔵 Bedeutung: Frameworks müssen nicht 1:1 befolgt werden — sie müssen zur eigenen Organisation passen. Keinem Modell sklavisch folgen. 🟡 Beispiel des Dozenten: Eine Firewall-Migration "agil" zu machen scheitert, weil Agilität Fehlertoleranz bedeutet — bei Firewall-Regeln nicht akzeptabel.

🔵 Vier-Quadranten-Modell: CORE vs. CONTEXT × Differenzierung vs. Produktivität. 🔵 CORE/Differenzierung = Was hebt uns vom Wettbewerb ab? Individualisierung, schwer skalierbar. 🔵 CONTEXT/Produktivität = Was muss bestmöglich laufen? Standardisierung, Automatisierung, Skalierung, kaum Differenzierung. 🟡 Klausurrelevant laut Rückschau: der Innovationszyklus, die Security-Sicht je Phase und der Sprung Core→Context als Konfliktstelle.

🔵 80er: Back-Office-Automatisierung — Stabilität, Wirtschaftlichkeit (Schufa-Abfrage lief über Nacht). 90er: Front-Office — Auskunft live im Beratungsgespräch. Heute: permanente Anpassung an sich ändernde Gegebenheiten inkl. Geopolitik, 24/7, günstig, automatisiert, zusätzlich KI-Agents. 🔵 Darwin: Nicht die stärkste oder intelligenteste Spezies überlebt, sondern die anpassungsfähigste — gilt auch für Unternehmen und IT-Landschaften.

🔵 Bei Security zählt Geschwindigkeit. Die Architektur ist die Informationsbasis, um schnell auskunftsfähig zu sein: "Nutzen wir dieses Produkt überhaupt?", "Können wir dieses System mal eben patchen?", "Wo sind wir betroffen?" 🔵 Genau diese einfachen Fragen bringen Unternehmen im Ernstfall zum Stolpern.

🔵 1) Stabsstelle vs. Funktion im Geschäftsbereich • 2) weisungsbefugt vs. "einfach da" (beratend) • 3) "Passiert" Architektur einfach — oder wird sie bewusst betrieben? • 4) Gibt es einen gelebten Prozess (Hygienefunktion, Review, neutrale Zweitmeinung)? 🟡 Dozent: "Mit diesen vier Punkten ist das komplette Spannungsfeld beschrieben."

🔵 KLASSISCH (nach Keller): Aufteilung in Leistungsfunktionen Entwicklung/Betrieb → funktionale Silos; Architektur sitzt in "Methoden, Verfahren, Architektur". Folgen: Entwickler im Tagesgeschäft gefangen, schlechte Übergabe Entwicklung→Betrieb. 🔵 MODERN: Manage / Change / Run (bzw. Plan / Build / Run), teils in Tochtergesellschaften; bessere Kontrolle und Steuerung über SLAs, aber viele Schnittstellen und Formalismus = Kommunikations-Overhead. 🟡 Merksatz: Es gibt kein Gut oder Schlecht — Übertreibung in jede Richtung führt zur suboptimalen Lösung.

🔵 ZENTRAL (Chef-Architekt): unternehmensweite Standards, Prinzipien, Vorgaben, Methoden, Werkzeuge, Dokumentationsstandards, Schulung, Support, Überwachung — bündelt konzeptionelle Mehrfacharbeit. 🔵 DEZENTRAL (Domänen-Experte): kennt die Business Unit, ist in den Fachbereichen vernetzt, versteht Anforderungen und leitet aus dem Standard die spezialisierte Architektur ab — "kein Elfenbeinturm, sondern jemand, den man persönlich kennt".

🔵 WAHR. 🟡 Der Dozent hat sich diese Frage in der Vorlesung live notiert. Ebenfalls möglich: "Wäre die Schaffung zentraler UND dezentraler Architektureinheiten ein Ansatz, das Thema nachhaltiger im Unternehmen zu verankern?" → Ja.

🔵 "Architecture Governance is the practice and orientation by which enterprise architectures are managed and controlled at an enterprise-wide level." 🔵 Gute Governance: angemessene Gremien, Kommunikation (kognitives Alignment), Rückkopplung der Prozesse an die Strategie als Normalfall — und vor allem: Entscheidungen werden auch umgesetzt.

🔵 LEGISLATIVE = Festlegung von Regeln (Regelwerke müssen schlank, verständlich, überschneidungsfrei und leicht auffindbar sein — das fördert Akzeptanz). 🔵 EXEKUTIVE = Prüfung: Sind die Zielbilder realistisch und kompatibel zur bestehenden Architektur? (beratender Part). 🔵 JUDIKATIVE = letzte Eskalationsinstanz bei Ressourcenkonflikten und Regelauslegung.

🔵 KOMPETENZEN: Managementaufgabe; Verantwortung, dass die IT-Strategie operationalisiert wird; das letzte Wort ("The Crying Towel"). 🔵 GEFAHREN: Management im Elfenbeinturm; übertriebenes Verlangen nach technischer Perfektion und Eleganz; Kompetenzgerangel und Übersteuerung.

🟡 Rückdelegation = "Wenn du das besser weißt, mach du das Design." Der Enterprise-Architekt übernimmt die Arbeit des Projektarchitekten — im Beispiel des Dozenten mit vier Wochen Zeitverlust, weil dem Kollegen nicht klar war, dass die Aufgabe wirklich übergegangen war. 🟡 Merksatz: "Der Trainer trainiert — er spielt nicht selbst."

🔵 ARCHITEKT: Verantwortung für IT-Portfolio und Bebauungspläne, Qualitätssicherung über viele Projekte hinweg, Eskalationsinstanz — dauerhafte Rolle. 🔵 PROJEKTARCHITEKT: technisch lauffähige Lösung zum Projektabschluss, nutzt fertige Komponenten (Blueprints, gehärtete Images); Neuentwicklung nur in Abstimmung — sie kann zum neuen Blueprint werden; meist nur für die Projektdauer.

🔵 Die Anpassungsgeschwindigkeit der Architektur ist deutlich langsamer als die der Organisation: "Die Umsetzung erfolgt mit dem Ablegen eines neuen Organigramms — unsere Systeme brauchen wesentlich länger." 🔵 Folgen: IT-Landschaft passt nicht mehr zur Organisationsform, es gibt keinen zuständigen Architekten mehr, die Gesamtsicht geht verloren. 🟡 Merksatz: eher Marathon als Sprint.

🔵 1) Machtdistanz • 2) Unsicherheitsvermeidung • 3) Individualismus (vs. Kollektivismus) • 4) Maskulinität (vs. Femininität) • 5) Lang-/Kurzzeitorientierung • 6) Genuss / Indulgence. 🟡 Dozent: "Da kann ich Ihnen garantieren, dass es dazu mindestens eine Frage geben wird" — als fiese Multiple Choice oder als offene Frage nach der Bedeutung aus Architektursicht.

🟡 Geert Hofstede (Niederländer) definiert Kultur vereinfacht als "die Software des Geistes" (Dozent: das "Brain OS"). 🔴 Grundlage: mehrjährige Studie mit 60.000 IBM-Mitarbeitern aus 40 Ländern — ausgelöst durch die Frage, warum bei "einer IBM" so viele Projekte scheiterten. 🔵 Ursprünglich vier Dimensionen, später um zwei ergänzt = sechs.

🔵 MACHTDISTANZ: Werden große Machtunterschiede/Hierarchien akzeptiert? Hoch = Führungskraft entscheidet, kein Widerspruch. Niedrig = flache Hierarchien, Entscheidungen werden hinterfragt. 🔵 UNSICHERHEITSVERMEIDUNG: Wie risikofreudig sind wir? Hoch = altbewährte Muster, ausgeprägtes Regelwerk ("verschlüsselt mit DIESEM Algorithmus und DIESER Schlüssellänge"); niedrig = "verschlüsselt die Sachen". 🔵 INDIVIDUALISMUS: Hoch = lockere Beziehungen, das Individuum im Vordergrund; niedrig = Kollektivismus, Gemeinschaft und Fürsorge.

🔵 MASKULINITÄT: Ausmaß von Dominanz. Maskulin = klar verteilte Geschlechterrollen, Status, Statussymbole, Prestige; feminin = Empathie, Fürsorge, Miteinander, tauschbare Rollen. 🔴 LANG-/KURZZEITORIENTIERUNG: langfristige Planung vs. Hier und Jetzt (Beispiel: Wechsel vom Drei-Monats- auf den Drei-Jahres-Horizont). 🔵 GENUSS (Indulgence): Akzeptanz der Selbstverwirklichung des Einzelnen — hoher Wert = Freiheit als wichtiger Wert, niedriger Wert = strengere Regulierung.

🔵 In Kulturen, die Konflikte flach halten (z.B. asiatisch geprägt), kommt lange kein Feedback — die Vorgabe wird schlicht nicht adaptiert, und es kostet viel Energie herauszufinden, warum. 🔵 Bei Dienstleistern aus Kulturen mit hoher Machtdistanz ist der Weg über die Hierarchie erfolgreich — man übergeht damit aber die Arbeitsebene und verliert deren Support. 🔵 Kern: Selbstreflexion — "Wie ticken wir selbst?"

🔵 BEHERRSCHBAR (mit Erfahrung): fachliche Anforderungen, technologische Anforderungen, Budget, Zeitdruck, Regeln/Policies/Gesetze. 🔵 KAUM BEHERRSCHBAR: Politik im Unternehmen, persönliche Interessen, unvorhergesehene Ereignisse. 🔵 Über allem schwebt die Abschlussfrage der Folie: "Und wird das Ganze dann auch noch sicher?" — Regeln/Policies spielen der Security in die Karten, Zeitdruck arbeitet klar dagegen.

🔵 FORMELLES SYSTEM (~10%, beobachtbare Sachebene): Prozesse, Zahlen, Strukturen, Fakten — "alles, was man im Intranet nachlesen kann". 🔴 INFORMELLES SYSTEM (~90%, nur teilweise beobachtbar): Kultur — Verhalten, Gefühle, Werte und Normen, Grundannahmen; in der Praxis: ungeschriebene Gesetze, Status einzelner Personen, Tabus ("bei uns kein Microsoft"), historische Ansprüche, und vor allem: Wer hat wirklich die Macht zu entscheiden? 🔴 Warnung: Wer ein Tabu nicht kennt, scheitert mit einem sonst guten Konzept.

🔵 URSACHEN: Angst, Wissenslücke, Eigeninteressen, Statusverlust, Jobverlust. 🔵 FORMEN: Intrigen, Fluktuation, Widerspruch, Aufregung, Boykott.

🔴 ACHSEN: Sachliches Risiko (Wird verstanden und akzeptiert, WARUM wir das machen?) × Persönliches Risiko (Habe ich als Person etwas zu gewinnen oder zu verlieren?). 🔵 ARCHETYPEN: PROMOTOR (versteht es, sieht Chance) • SKEPTIKER (nichts zu verlieren, versteht aber nicht warum) • BREMSER (versteht es voll, verliert aber persönlich) • WIDERSTÄNDLER (versteht es nicht UND verliert).

🔵 PROMOTOR → als Leiter/Change Agent einsetzen, Vorbildfunktion. 🔵 SKEPTIKER → Informationen, Fakten, Zahlen; sachliche Informationsbasis aufbauen, aktiv einbinden, Redepart geben. 🔵 BREMSER → persönliche Risiken absichern, Sicherheiten aufzeigen, neue Rolle/Entwicklung anbieten, Einzelgespräche. 🔵 WIDERSTÄNDLER → gezielte Einzelmaßnahmen, Verantwortung im Projekt geben, im Worst Case auf eine Position setzen, wo er keinen Schaden anrichten kann. 🔴 Hinweis: Archetypen in Reinform gibt es in der Praxis kaum.

🔵 Es genügt zu wissen: (1) dass es das Modell gibt, (2) dass sich vier typische Widerstandsformen ableiten lassen (Promotor, Skeptiker, Bremser, Widerständler) und (3) dass die Ableitung über sachliche vs. persönliche Risiken läuft. 🟡 Das Modell muss NICHT gemalt werden — aber wenn behauptet wird, es basiere "auf drei Achsen mit sechs Risikogruppen", muss man das als FALSCH erkennen.

🔵 Wechselseitige Abstimmung von Zielen, Strategien, Architekturen, Leistungen und Prozessen zwischen IT und Fachbereichen. 🔵 Wichtig: Ziele von Business und IT sind aufeinander abgestimmt UND kommuniziert. 🔵 "Wer macht das? Vielleicht jemand aus der Architektur."

🔵 1) Kognitives IT-Alignment — Ausrichtung auf gemeinsames Gedankengut • 2) Strategisches IT-Alignment — Abstimmung von Business- und IT-Strategie • 3) Architektonisches Alignment — Wie gut passen IT-Systeme zu Geschäftsprozessen? • 4) Temporales Alignment — Wie schnell lässt sich die IT-Landschaft an Änderungen des Geschäftsmodells anpassen? • 5) Systemisches IT-Alignment — Ist die IT-Landschaft in der Lage, das Unternehmen zu steuern? 🟡 Dozent: "Das schreit danach, dass man die fünf Dimensionen im Kopf hat."

🔵 STRATEGISCHES, ARCHITEKTONISCHES und TEMPORALES Alignment. 🔵 Nicht beeinflussbar: kognitives (muss vom Management vorgelebt werden) und systemisches Alignment ("wir können nicht sagen, welches die richtigen Daten sind — wir sind Zulieferer"). 🟡 ⚠ KLAUSURFALLE: Es heißt SYSTEMISCH, nicht "systematisch" — der Dozent hat angekündigt, genau diese Nickeligkeit einzubauen.

🔵 Das KOGNITIVE Alignment — gemeinsames Verständnis ALLER Unternehmensteile, gemeinsames Gedankengut, weg vom "wir und die". 🔵 Zur Abgrenzung: Das systemische Alignment ist das, was sich nur rückblickend feststellen lässt.

🔵 Gemeinsames Verständnis ALLER Unternehmensteile, nicht nur der IT. Fehlt es, entstehen Gräben und Plattitüden. 🟡 Wichtig ist eine gemeinsame Sprache: Anekdote des Dozenten — ein Workshop lief bis zum Mittagessen hervorragend, dann stellte sich heraus, dass beide Seiten dieselben Abkürzungen für völlig verschiedene Dinge benutzt hatten. Lösung: ein Abkürzungsregister (Beispiel SAM = Software Asset Management? Security Asset Management? Strategic Alignment Model?).

🔵 STRATEGISCH: Abstimmung von Geschäfts- und IT-Strategie; verhindert Technikeinsatz "nur um der Technik willen". Verortung: Spitze der Modellpyramide nach Dern. 🔴 ARCHITEKTONISCH: Wie flexibel ist die IT-Landschaft, wie schnell können wir neue Technologien einführen? Kernaufgabe = Anwendungsportfolio-Management (Kernapplikationen, schützenswerte Komponenten, End-of-Life-Planung). Fehlannahme: Ähnlichkeit zwischen Software und Geschäftsprozess bedeutet Alignment — das kann Zufall sein (Conway's Law).

🔵 TEMPORAL: Wie schnell lässt sich die IT-Landschaft anpassen? Unterscheidung absehbare (Saisongeschäft) vs. nicht absehbare Änderungen; nicht mehr "viel hilft viel", sondern effiziente Weiterentwicklung. Verortung: technische Ebene der Pyramide. 🔴 SYSTEMISCH: Ist die IT-Landschaft in der Lage, das Unternehmen zu steuern? Kernfrage: "Versetzt mich meine IT in die Lage, die richtigen Entscheidungen zu treffen?" Problem: nur rückblickend feststellbar. Beispiel Nokia (Papiermühle → Kommunikationskonzern → Scheitern am Smartphone).

🔵 TRUSTED OPERATOR (indirekter Impact auf Business Value): "Wir sorgen dafür, dass alles läuft". 🟡 BUSINESS CO-CREATOR (direkter Impact): gemeinsam Projekte machen, IT und Architektur gemeinsam weiterentwickeln — der Lieblingsbegriff des Dozenten, weil er das "wir und die" auflöst. 🔵 CHANGE INSTIGATOR: aus der IT heraus angeschobene Veränderung. 🔵 Realität: ~55% Trusted Operator, ~33-36% Co-Creator. Idealbild: nur ~20% Trusted Operator, ~45% Co-Creator. Ziel ist der Business Co-Creator.

🔵 Zwei rasen aufeinander zu — wer zuerst ausweicht, hat verloren; weichen beide gleichzeitig aus, bekommt jeder nur die Hälfte. 🔵 Übertragen: Niemand macht den ersten Schritt → Druck auf alle Parteien, Stillstand im Unternehmen, Verlust von Zeit, Geld und Ressourcen. 🔵 Der Enterprise-Architekt ist prädestiniert für die Mittlerrolle, weil er beide Seiten versteht.

🔵 1) Effiziente Geschäftsprozesse • 2) Passende Organisationsstrukturen • 3) Softwaresysteme, die zu Prozessen und Strukturen passen. 🔵 CONWAY'S LAW: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." 🔵 Nutzen: In der eingesetzten Software spiegelt sich der GELEBTE Prozess wider — nicht zwingend der effiziente Prozess auf dem Papier.

🔵 Henderson & Venkatraman, 1993. Ausgangspunkt: Unternehmen gewinnen keine großen Vorteile durch IT-Einsatz, weil die Abstimmung zwischen Business und IT unangemessen ist. 🔵 STRATEGIC FIT (vertikal): externe Domäne (Marktpositionierung: Business Scope, Distinctive Competencies, Business Governance) vs. interne Domäne (administrative Struktur, Geschäftsprozesse, Skills). 🔵 FUNCTIONAL INTEGRATION (horizontal): strategische Integration (Business- und IT-Strategie) und operative Integration (Organisations- und IT-Infrastruktur/-Prozesse).

🔵 "Sie werden es nicht im Rahmen einer offenen Frage beschreiben müssen." Es kann aber eine Frage kommen, ob man das Modell verstanden hat: (1) Abstimmung zwischen IT und Business — Tools und Prozesse müssen zum Geschäft passen (interne Sicht), (2) das Ganze dient dem Erfolg am Markt (externe Sicht), (3) alles muss dynamisch und permanent abgestimmt werden.

🔵 Reine Strategie-Synchronisation auf oberster Ebene erzeugt Standardstrategien ("wir machen was mit Cloud") — nicht greifbar, intern nicht verkaufbar. 🟢 Lösung: eine Abstraktionsebene tiefer auf die Sekundär-Funktionsstrategien gehen (Vertriebs-, Produktions-, Einkaufsstrategie), denn dort stehen die konkreten Bedarfe. Alle Pfeile sind bidirektional — die IT bringt Erkenntnisse zurück in die Strategie. 🟡 Dozent: mehr als den Grundgedanken braucht es hier nicht.

🔴 1) Effizienterer Betrieb des Business (niedrigere Betriebskosten, agilere Organisation, unternehmensweiter Ressourceneinsatz, gesteigerte Produktivität) • 2) Effektiverer IT-Betrieb (niedrigere Kosten für Entwicklung/Support/Wartung, Portabilität, Interoperabilität, vereinfachtes Upgrade — für Security besonders: automatisiertes Ausrollen von Sicherheitsupdates) • 3) Verbesserter ROI, reduziertes Risiko (weniger Komplexität, Flexibilität bei make/buy/outsource) • 4) Schnellere, einfachere, günstigere Beschaffung.

🔵 1) STRUKTUREN — grundlegende Struktur bzw. Menge von Strukturen, aus der sich n verschiedene Architekturen bilden lassen (Blaupausen, wiederkehrende Muster). 2) METHODEN — eine Methode, den Zielzustand zu definieren, unter Einbeziehung vorhandener BAUSTEINE und ihrer Abhängigkeiten. 3) WERKZEUGE, gebräuchliches VOKABULAR, empfohlene STANDARDS, Best Practices und Übersichten konformer Produkte. 🟡 Dozent: "Das schreit definitiv nach einer Frage." Merkregel: "Wo fettgedruckte Sachen sind, die kann man sich nicht verkneifen."

🔵 "A Framework for Information Systems Architecture", John Zachman, 1987, IBM Systems Journal — gilt als Startpunkt der Enterprise Architecture (das Thema ist noch keine 40 Jahre alt). 🟡 🔥 Merksatz, den der Dozent explizit einprägen lässt: Die Herausforderung ist das MANAGEMENT DER KOMPLEXITÄT VERMEHRT VERTEILTER SYSTEME. 🔵 Daraus entwickelte Zachman den Multiperspektivansatz: ein System aus allen notwendigen Perspektiven betrachten.

🔵 1) Systemkomplexität und 2) mangelndes Business-Alignment. 🔵 Unter dem Strich: höhere Kosten, weniger Wert. Kosten und Komplexität steigen exponentiell, während die Chancen, Mehrwert zu generieren, sinken. 🟡 Praxisrat des Dozenten zur Framework-Vielfalt: "Wenn Ihr Chef sagt, wir brauchen ein Framework — nehmen Sie entweder TOGAF, oder ducken Sie sich und rennen weg."

🔵 ZACHMAN (wegen des Hintergrunds / Startpunkt der EA) • TOGAF (gilt als Weltmarktführer) • SABSA (Security-Fokus) • und als "viertes" ZERO TRUST, das man ebenfalls als Framework bezeichnen kann.

🔵 EAM = inhaltliches Fundament für das Management der IT-Landschaft, das Business-IT-Alignment und die Weiterentwicklung des Geschäfts (EAM, Enterprise Architecture und Architektur werden synonym verwendet). 🔵 Ergebnistypen: Visualisierungen, Grafiken, Listen, Steuerungssichten. 🔵 Sie beantworten die einfachen W-Fragen: Was? Wer? Wo? Warum? Womit? Wie? Wieso? Wann? Wohin?

🔵 EAMe2 = "einfach und effektiv". Ausgangsproblem: Die Ableitung des EAM aus einem Framework ist sehr aufwendig und teuer. 🔵 Kernfrage: Wie viel Komplexität kann ich aus der Dokumentation herausnehmen — und was braucht welche Zielgruppe? Je länger ein Dokument/eine Policy, desto höher die Chance, dass sie nicht gelesen wird. 🟡 Zitate: Einstein — "Mach die Dinge so einfach wie möglich, aber nicht einfacher"; Saint-Exupéry — "Perfektion ist nicht dann erreicht, wenn man nichts mehr hinzufügen, sondern wenn man nichts mehr weglassen kann." 🔴 Bestes Ergebnis in der Praxis: einfache Grafik PLUS Detailliste.

🔵 1) Informationsbedarf der Stakeholder ermitteln (Transparenz schaffen) • 2) Strategische Planung der IT-Landschaft (Soll-Landschaft und IT-Roadmap) • 3) Aktives Vorgehen vom Ist zum Soll. 🔵 Effektivität = die richtigen Dinge tun: aus Unternehmensstrategie und Geschäftsanforderungen die künftige IT-Landschaft ableiten und regelmäßig abgleichen.

🟡 Musterlösung des Dozenten: 1) Kennenlernen — CEO/Geschäftsführung, Stakeholder, dann die Leute (Organigramm, Struktur, Kultur; vor allem: Was ist das Ziel meiner Rolle?). 2) Kick-off und Workshops mit allen (international verteilten) Architekturteams. 3) IST-AUFNAHME: welche Tools, welche Frameworks, was sind die wichtigsten Applikationen (ohne die Standardantwort "E-Mail"), vorhandene Dokumentation, Schnittstellen, kritischste Prozesse, Metriken. 4) Zieldefinition mit KPIs und Reporting. 5) Nach 100 Tagen erste Ergebnisse präsentieren. 🔵 Erkenntnis: Auf EA-Ebene braucht man nicht jedes Detail — der Wert liegt oft im Wachrütteln und darin, Kommunikation in Gang zu bringen.

🔵 "Ein IT-Architekturstil, in dem Services (Dienste) die zentrale Rolle spielen. Die IT-Landschaft wird in modulare Services strukturiert. Jeder Service trägt direkt oder indirekt zur Wertschöpfung bei. Er kann einfach und flexibel kombiniert und regelbasiert gesteuert werden." 🔵 SOA ist ein Paradigma (Denkmuster) zur Realisierung/Pflege von Geschäftsprozessen über mehrere große, verteilte Systeme. 🔵 SOA wird heute nicht mehr forciert, lebt aber in Microservices weiter.

🔵 1) SERVICE • 2) ESB (Enterprise Service Bus) • 3) LOSE KOPPLUNG. 🟡 Dozent explizit: "Sollte im Januar eine Frage nach den drei technischen Konzepten im Mittelpunkt der SOA kommen: Service, ESB und lose Kopplung. Das sind Sachen, die man sich merken kann." 🔵 Blackbox-Bild: Wir wissen, was hineingeht und was herauskommt; wie es implementiert ist, ist egal. Fällt ein Service aus, leitet der ESB die Kommunikation auf einen anderen Service um.

🔵 Macht die unternehmensspezifischen Vorgaben für die technische Umsetzung: Technologie, Softwarearchitektur, Infrastruktur, Aspekte für Entwicklung und Betrieb — und vor allem die Governance (Überwachung der involvierten Systeme und ihres Zusammenspiels).

🔴 BOTTOM-UP (opportunistisch, projektgetrieben): greifbar, klare Projektanforderungen, schnelle Erfahrung — Risiko: in einem Bereich SOA, im anderen klassisch → nicht weniger komplex. 🔴 TOP-DOWN (strategisch): getrieben von den Anforderungen der Business-Bereiche, reduziert Redundanz-Risiko. 🟢 EMPFEHLUNG: Hybridansatz — strategisch die Richtung festlegen und parallel in Projekten implementieren; den Entwicklungszyklus regelmäßig gegen die Strategie spiegeln.

🔵 KOMPONIEREN: mehrere elementare Services zu neuen zusammensetzen, Services austauschen, Features ergänzen → Geschäftsprozesse neu komponieren. 🔵 ORCHESTRIEREN: Prozesssicht — Wie bilden wir die Geschäftslogik ab, wie steuert der ESB die Kommunikation? 🔵 CHOREOGRAFIE: Koordination über Unternehmensgrenzen hinweg.

🔵 MONOLITH: gewachsene Systeme, Funktionalitäten sind miteinander verzahnt — fällt eine Komponente aus, ist das Gesamtsystem gestört; Skalierung nur als Ganzes. 🔵 SOA: löst das durch modulare, GROBGRANULARE Services (z.B. der komplette Bestellprozess); gemeinsames Repository. 🔵 MICROSERVICES: FEINGRANULAR (z.B. "Artikel in den Warenkorb legen"); jeder Service hat seinen eigenen Datenspeicher. 🔵 SERVERLESS: nur noch Code. 🔵 Wichtig: Monolithen sind nicht per se schlecht — oft ist eine Mischung richtig. Details werden NICHT gefragt, aber die Herleitung muss sitzen.

🔵 TOGAF = The Open Group Architecture Framework, erstmals 1995 veröffentlicht, basiert im Kern auf TAFIM (Technical Architecture Framework for Information Management) des US-Verteidigungsministeriums. 🔴 Foliensatz zeigt Version 9.2; seit April 2022 gibt es die 10th Edition — gleiche Kernkonzepte, moderner dargestellt, zusätzlich Domain Specifications (u.a. Security Architecture, Risikomanagement, Informationssicherheit im Zusammenspiel mit der ADM).

🟡 1) ADM — Architecture Development Method (grafisch UND methodisch der Kern) • 2) ADM Guidelines and Techniques • 3) Architecture Content Framework (der Dokumentationsstandard) • 4) Enterprise Continuum and Tools • 5) TOGAF Reference Models / Referenzmaterialien • 6) Architecture Capability Framework (Organisation, Skills, Verantwortlichkeiten, Rollen — laut Dozent das Alleinstellungsmerkmal von TOGAF). 🟡 Die Grafik muss NICHT gezeichnet werden können.

🔵 WAHR. 🔵 Das Architecture Capability Framework und der Skills Resource Pool behandeln Organisation, Rollen, Verantwortlichkeiten und Skills — in vielen anderen Frameworks ist Organisation gar kein Thema. 🟡 Kritische Lesart des Dozenten: die Skill-Liste besser als STAKEHOLDER-CHECKLISTE lesen — Bereiche, mit denen man sich vernetzen muss.

🔵 1) BUSINESS ARCHITECTURE — Business-Strategie, Governance, Organisation, Kern-Geschäftsprozesse (Rolle: Enterprise-Architekt). 2) DATA ARCHITECTURE — Struktur der logischen und physischen Daten-Assets und der Ressourcen zu deren Management (Rolle: eher SME). 3) APPLICATION ARCHITECTURE — Blaupause für die Entwicklung individueller Applikationen, deren Interaktion und Beziehung zu den Kern-Geschäftsprozessen. 4) TECHNOLOGY ARCHITECTURE — SW/HW-Kapazitäten zur Unterstützung der Business-, Daten- und Applikations-Services; umfasst IT-Infrastruktur, Middleware, Netzwerke, Prozesse, Standards.

🔵 Preliminary Phase (Framework and Principles) → A: Architecture Vision → B: Business Architecture → C: Information Systems Architecture → D: Technology Architecture → E: Opportunities and Solutions → F: Migration Planning → [Absprung: Implementierung in Projekten] → G: Implementation Governance → H: Architecture Change Management. 🔵 In der MITTE permanent: REQUIREMENTS MANAGEMENT. 🟡 🔥 Dozent: "Zur ADM werden Sie definitiv etwas in der Klausur machen müssen" — Erklären und/oder Zeichnen als eine der drei offenen Fragen.

🔵 PRELIMINARY: Rahmen, Prinzipien, Standards, einzubindende Modelle, geforderte Anpassungen — auch rechtliche Rahmenbedingungen. 🔵 A ARCHITECTURE VISION: Umfang, Fokus, Einflüsse, Vorgaben — "der High-Level-Steckbrief: Was machen wir, warum, aus welchem strategischen Ziel, mit welchem Budget?" 🔵 B BUSINESS ARCHITECTURE: Geschäftsprozessmodelle, Use Cases, Geschäftsmodelle — noch sehr high level. 🔵 C INFORMATION SYSTEMS ARCHITECTURE: Datenmodelle und Applikationen. 🔵 D TECHNOLOGY ARCHITECTURE: Hard- und Software, Cloud-Komponenten. 🔵 Bis hierhin ist NICHTS implementiert — B, C, D sind reine Architekturentwicklung vom Grob- zum Feinkonzept.

🔵 E OPPORTUNITIES AND SOLUTIONS: generelle Implementierungsstrategien — Wie kann ich es umsetzen, kann ich von A nach B migrieren? 🔴 F MIGRATION PLANNING: konkrete Implementierungspläne und Feinplanung der Migration — Achtung, auch hier wird noch NICHT umgesetzt. 🔵 [Danach der hellgraue Absprungpunkt: die eigentliche Implementierung in den Projekten.] 🔵 G IMPLEMENTATION GOVERNANCE: Wie sieht die Projektumwelt aus, Kompatibilität zu anderen Projekten, hat alles funktioniert? 🔵 H ARCHITECTURE CHANGE MANAGEMENT: Planung der nächsten Iteration — praktisch ein Lessons Learned.

🟡 Architecture Context (Preliminary + A) → Architecture Delivery (B bis D — der Dozent merkt es sich als "Business Architecture bis Technology Architecture = Architecture Delivery") → Transition Planning (E + F) → Architecture Governance (G + H). 🟡 🔥 Wichtig: Nur vier gruppierte Punkte aneinanderzureihen wäre in der Klausur ZU WENIG — "Sie müssen die einzelnen Phasen kennen." Aber: keine Minuspunkte, wenn eine Phase nicht exakt benannt ist, solange erkennbar ist, dass es vom Grobgranularen ins Feingranulare geht.

🔵 FALSCH. Rücksprünge sind ausdrücklich möglich. 🔵 Die Kreisdarstellung ist in dieser Hinsicht unglücklich; alternative Darstellungen der Open Group zeigen die Rücksprünge. Im Kern steht permanent das Requirements Management. 🔵 Das Ende eines Zyklus ist direkt der Start der nächsten Iteration.

🔵 FALSCH — es ist eben NICHT auf alle Schritte gemappt. 🔵 Verankerungspunkte: Preliminary/Architecture Context (Prinzipien, Risk Appetite, kritische Komponenten), Phase B (Policies, Risk Assessment, Applicable Law and Regulation Register), Phase D (Security Standards: Verschlüsselung, Authentisierung), Implementierungsphasen (Risk Mitigation Pläne). 🔵 Nicht gemappt u.a. bei Architecture Vision und Architecture Change Management.

🔵 WAHR. 🔵 TOGAF: in der Preliminary Phase. Zachman: in der ersten, sehr abstrakten Ebene (Scope). SABSA: in der Contextual/Business View.

🔵 DELIVERABLES — ARTIFACTS — BUILDING BLOCKS. 🟡 ⚠ KLAUSURFALLE: "Deliverables, MATRICES, Building Blocks" ist FALSCH — Matrizen sind nur eine Untermenge der Artefakte! (Vom Dozenten als bewusste Nickeligkeit gebaut.)

🔵 DELIVERABLES: fest spezifizierte Arbeitsergebnisse, repräsentieren den Output von Projekten oder werden Teil des Architektur-Repository — die Klammer, die n Artefakte umfassen kann. 🔵 ARTIFACTS: beschreiben je einen Aspekt der Architektur; drei Ausprägungen — Kataloge, Matrizen, Diagramme. 🔵 BUILDING BLOCKS: potenziell wiederverwendbare Bausteine, die kombiniert etwas Neues ergeben (z.B. ein Standard-Image oder Blueprint für einen Server-/Cloud-Service).

🔵 KATALOGE = Listen/Stücklisten, z.B. eine Checkliste "ein Webserver muss X, Y, Z können"; in jedem Tool machbar, gut für Wiederverwendbarkeit. 🔵 MATRIZEN = Beziehungen untereinander und Kommunikationsflüsse: wer kommuniziert mit wem, über welchen Port, welches Protokoll (greifbar: Firewall-Regelwerk, Security Groups in der Cloud); durchaus tabellarisch. 🔵 DIAGRAMME = Beziehungen zwischen Komponenten und zu anderen Systemen, zum Erklären (klassisch Visio). 🟡 🔥 Klausur: "Was gibt es da an Dokumentationsbausteinen? Welche gehören wozu?" — Zuordnungsaufgabe wahrscheinlich.

🔵 Legt den breiteren Kontext fest: Wie können generische Lösungen genutzt und spezialisiert werden? 🔵 ARCHITECTURE CONTINUUM: Klassifizierung von Architekturmodellen mit zunehmendem Grad an Spezialisierung (konzeptionelle Sicht). 🔵 SOLUTIONS CONTINUUM: Beschreibung der Implementierung (Migrationskonzepte, technische Umsetzung); Lösungsartefakte lassen sich exakt wiederverwenden. 🔵 Zentrale Herausforderung: Wie generisch darf eine Blaupause sein? Zu generisch → niemand holt sie aus dem Repository. 🔵 Zum Mapping ADM ↔ Kontinuum wird es KEINE Fragen geben.

🔵 Das "Gedächtnis", speichert den ADM-Output auf verschiedenen Abstraktionsebenen: 🔵 ARCHITECTURE METAMODEL — wie wir das Framework im eigenen Unternehmen adaptiert haben (Namenskonventionen, Detaillierungsgrad). 🔵 ARCHITECTURE LANDSCAPE — Dokumentation des Ist-Zustands. 🔵 STANDARDS INFORMATION BASE — externe Normen/Industriestandards UND selbst gesetzte Unternehmensstandards. 🟢 REFERENCE LIBRARY — Referenzimplementierungen, Templates, Patterns, Best Practices. 🔵 GOVERNANCE LOG / ARCHITECTURE CAPABILITY — hier findet sich das Architekturboard wieder.

🔵 Jedes EA-Framework enthält zwei Elemente: (1) die Definition der "Produkte" des Architekturprozesses und (2) die Beschreibung der Methoden. Die meisten Frameworks decken nur EINES davon ab — TOGAF bringt BEIDES mit. 🔵 Deshalb nutzbar als einziges Framework oder zum gezielten Lückenschließen.

🔴 Hoher Dokumentationsaufwand, viele Detailinformationen, kontinuierliche Pflege nötig — mit der ständigen Frage nach dem Mehrwert und der Gefahr doppelter Pflege. 🔵 "TOGAF ist ein Werkzeug, bringt aber nicht automatisch einen guten Architekten ins Unternehmen." 🔵 Frameworks sind als Richtlinie sinnvoll, sollten aber mit Augenmaß eingesetzt werden.

🔵 TOGAF ist primär das Werkzeug des Architekturteams. Über das REQUIREMENTS MANAGEMENT in der Mitte kommen die Stakeholder ins Spiel. 🔵 In der reinen Entwicklung (Preliminary bis Phase D) arbeitet die Architektur weitgehend allein, spiegelt aber laufend gegen die Anforderungen der Fachbereiche. 🔵 Spätestens bei E/F (Transition Planning) ist der Übergang ins Operative — hier braucht man die Betriebsbereiche. 🔵 In großen Organisationen fragt man Repräsentanten, nicht alle Geschäftsbereiche.

🟡 Merksatz des Dozenten: Security rückwirkend zu implementieren ist deutlich aufwendiger — "wenn man Leute an einen komfortablen Modus gewöhnt, bekommt man sie schwer wieder weg". 🔴 Beispiele für schlecht gesetzte Anfangsstandards: das Louvre-Passwort ("Louvre") und der jahrelange Code "00000000" für US-Atomraketen.

🔵 1987 von John Zachman entwickelter Ordnungsrahmen, 1992 gemeinsam mit John Sowa erweitert (beide bei IBM) — im Wesentlichen der bis heute bekannte Stand. 🔵 Unterschied zu TOGAF: KEIN Vorgehensmodell, keine Prozessabfolge, keine vorgeschriebenen Methoden. Der Fokus liegt auf den beteiligten ROLLEN und deren PERSPEKTIVEN. 💡 Bild des Dozenten: Zachman gibt uns eine CHECKLISTE — "denk über dieses und jenes nach; wenn du alles durchdacht hast, hast du eine gute Chance, nichts vergessen zu haben."

🔵 Zeile 1 SCOPE — externe Anforderungen und Treiber, Modell von Unternehmensfunktionen • Zeile 2 BUSINESS MODEL — Business-Einheiten, Prozesse und deren Interaktion • Zeile 3 SYSTEM MODEL — genutzt durch den System Analysten, legt Daten und Softwarefunktionen fest • Zeile 4 TECHNOLOGY MODEL — Tools, Technologien, Material • Zeile 5 COMPONENTS — einzelne unabhängige Module für die Implementierung • Zeile 6 WORKING SYSTEM — Wiedergabe des operativen Systems.

🔵 WHO — Beziehung von Personen zum Unternehmen • WHEN — zeitliche oder Event-basierte Beziehungen, Performance-Kriterien • WHY — Beschreibung der Motivation (Unternehmensziele, Business-Pläne) • WHAT — Beschreibung der Entitäten jeder Perspektive • HOW — Funktionen innerhalb einer Perspektive • WHERE — Örtlichkeiten und Verbindungen innerhalb des Unternehmens.

🔵 1) Spalten haben keine feste Reihenfolge • 2) Jede Spalte repräsentiert ein einfaches Basismodell • 3) Das Basismodell jeder Spalte kommt nur einmal vor • 4) Jede Zeile repräsentiert eine Sichtweise • 5) Jede Zelle kommt nur einmal vor • 6) Die Kombination der Zellen einer Zeile ergibt eine vollständige Beschreibung einer Sicht.

🟡 "Ich glaube nicht, dass zum Framework selbst in der Klausur etwas gefragt wird." Wichtig ist stattdessen: dass wir der KOMPLEXITÄT Herr werden müssen — das hat Zachman schon 1987 gesagt. 🟡 "Diese Struktur würde ich nicht zwingend auswendig lernen, die ADM dagegen schon verinnerlichen." 🔵 Der Grundgedanke zählt: vom Groben ins Feine, vom Abstrakten ins Konkrete.

🔵 Bei Zachman findet man das Wort Security NICHT. 🔵 SABSA baut aber auf Zachman auf und verankert Security über das ganze Modell. 🔵 Zachman selbst sagt, er habe nur Dinge zusammengebracht, die es seit tausenden Jahren gibt — die W-Fragen und das Verfeinern vom Groben ins Feine.

🔵 SABSA wurde 1995 von John Sherwood, Andy Clark und David Lynas für ein Finanzunternehmen entwickelt. 🔵 Systematisches Vorgehen durch alle Ebenen eines Bereichs oder Unternehmens; sechs Ebenen, orientiert an Zachman ("Das ist Zachman in Reinform"). 🔵 SABSA legt eine 6×6-MATRIX über das Unternehmen: horizontal die Detailebenen, vertikal die zu betrachtenden Aspekte. 🔵 Kern: über die Business Attributes entsteht eine Verknüpfung über alle Ebenen hinweg = "TWO WAY TRACEABILITY".

🔵 1) Business View → CONTEXTUAL (Security) Architecture — Geschäftsführung/Vorstand, strategische Ausrichtung • 2) Architect's View → CONCEPTUAL Architecture — EAM/Architektur • 3) Designer's View → LOGICAL Architecture • 4) Builder's View → PHYSICAL Architecture • 5) Tradesman's View → COMPONENT Architecture (welche Hersteller, welche Produkte) • 6) Service Manager's View (ursprünglich Facilities Manager's View) → OPERATIONAL Architecture bzw. Security Service Management Architecture — hochkant, weil sie sich über alles legt.

🔵 INSPECTOR'S VIEW (klassisch der Auditor) und GOVERNOR'S VIEW (z.B. eine übergreifende Konzern-Sicherheitsfunktion). 🔵 Sie überwachen das große Ganze und prüfen punktuell die Implementierung.

🔵 SABSA denkt das OPERATING mit: "Was passiert, nachdem wir die Architektur in Betrieb genommen haben?" — die Service Manager's View / Operational Security Architecture (oft an ITIL ausgerichtet): Störungsbehandlung, Prävention, Backups, Rollenkonzept für Administratoren, Patch-Management, Monitoring. 🔵 In TOGAF gab es an dieser Stelle nur den Absprung in die Projekte.

🔵 WHAT — Was für ein Gebäude/System? • WHY — Warum wollen wir es (zu erreichende Ziele)? • HOW — Wie wird es genutzt? • WHO — Wer wird es nutzen? • WHERE — Wo soll es gebaut werden, was sind die umliegenden Gegebenheiten? • WHEN — Wann wird es genutzt (Brauchen wir das System wirklich 24/7? Wann sind Wartungsfenster möglich?). 🔵 Illustriert an der Gebäude-Analogie.

🔵 Das übergeordnete Grobkonzept: WHAT = Was soll/muss geschützt werden? • WHY = Warum ist die Sicherheit wichtig (Verlinkung auf den Geschäftsprozess)? • HOW = High-Level technische/Management-Security-Strategie, Standard-Technologiebausteine • WHO = Wer ist am Management der Sicherheit beteiligt? • WHERE = Wo greifen die Security-Konzepte (Cloud oder on premise)? • WHEN = Wann muss Security greifen?

🔵 Eine REQUIREMENTS-ENGINEERING-TECHNIK, die die Verbindung zwischen Geschäftsanforderungen und Technologie-/Prozessdesign herstellt. 🔵 Ein Attribut ist ein TAG, das man an etwas hängt; dahinter steht je nach Flughöhe die passende Beschreibung. Ganz oben beim Tag "Security" das strategische Ziel für den Vorstand, ganz unten für den Techniker "muss diese Verschlüsselung implementieren". 🔵 So entsteht Nachvollziehbarkeit in BEIDE Richtungen (two way traceability). 🔴 Beispiel Attribut "Skalierbarkeit": Geschäftsführung = mehr Endkunden; Technik = Auto-Scaling in der Cloud.

🟡 GAR NICHT auswendig — "25 Standardattribute von SABSA auswendig wäre eine ziemlich blöde Auswendig-Aufgabe." 🔵 Verlangt wird nur das Grundprinzip: Ich hänge ein Attribut als Tag an etwas und hinterlege je nach Flughöhe, was es bedeutet — damit begründe ich, warum Security-Werkzeuge nötig sind (Rückverfolgbarkeit). 🔴 Hintergrund: zwei vorgefertigte Taxonomien (ursprünglich IKT-Fokus mit sieben Gruppenüberschriften, neuere Fassung mit Geschäftsfokus) — beide nur Beispiele, beliebig erweiterbar.

🔵 SABSA bringt "normale" Themen in einen Security-Kontext. 🔴 Kette: Service/Funktion → Mechanism → Component. Beispiel: Network Access Control → Stateful Inspection → Cisco ASA. 🔴 Weitere Beispiele: AD Service Utility = user authentication (security related), DNS Service Utility (non-security related). 🔵 Nutzen: Der Techniker sieht, warum "Benutzerfreundlichkeit" gefordert ist, und der Finanzvorstand sieht, warum die Techniker dafür Geld brauchen.

🔵 NATIV: Business Attributes werden von ganz oben (CEO oder Bereichsleitung) bestimmt — top-down aus der Enterprise Architecture. 🔵 GUERILLA: punktuelles Nutzen der SABSA-Perspektiven, um die Zusammenhänge von Architektur und Security zu stabilisieren. 🔵 Wie bei SOA: "Die Wahrheit liegt irgendwo dazwischen."

🔵 FALSCH bzw. präziser: SABSA ist keine Verbesserung, sondern eine ERGÄNZUNG mit Security-Fokus. 🔵 "Im Kern ist es Zachman, aber mit Security-Sicht darauf — und die Attribute machen es besser nutzbar und zugänglicher." 🔵 "SABSA pur würden Sie nicht verstehen, wenn Sie Zachman nicht verstanden haben."

🔵 Zero Trust ist ein FRAMEWORK, das davon ausgeht, dass die Sicherheit eines komplexen Netzwerks immer durch EXTERNE UND INTERNE Bedrohungen gefährdet ist. 🔵 Die Zero-Trust-Architektur wurde 2010 von JOHN KINDERVAG entwickelt. Sie verspricht wirksamen Schutz der wertvollsten Assets; jede Verbindung und jeder Endpunkt wird als Bedrohung angesehen. 🟡 Einordnung des Dozenten: Eigentlich müsste dort nicht "komplexe Netzwerke", sondern "komplexe STRUKTUREN" stehen — Zero Trust ist kein reines Netzwerkthema (genauso zentral: Identity & Access Management und Datenklassifizierung).

🔵 1) LEAST PRIVILEGE — nur so viele Berechtigungen wie nötig und nur zu der Zeit, in der sie gebraucht werden. 2) Jede Verbindung zwischen zwei Punkten wird überprüft und autorisiert — dynamisch und permanent. 🔵 Schlüsselwort: KONTEXT aus so vielen Datenquellen wie möglich. 🔵 Grundprinzip in einem Satz: "NEVER TRUST, ALWAYS VERIFY". 🔵 Zero Trust ist ein Architekturansatz, KEIN Produkt: "Es gibt keine Out-of-the-box-Lösung, auch wenn Hersteller das gern anders verkaufen."

🔵 1) 1980 PERIMETER SECURITY — Schutz des physikalischen Perimeters der Liegenschaft, wenig Vernetzung. 2) 1990 DEFENSE IN DEPTH — mehrere Schichten von Security Controls (Firewalls, IDS/IPS, Proxies) = NORTH-SOUTH-PROTECTION; wenige, sehr gut kontrollierte Breakouts. 3) TODAY HYBRID CYBER — eine große Anzahl an Breakouts (jede Verbindung zu AWS, Azure, Google, SaaS), mobiles Arbeiten → EAST-WEST-PROTECTION; das ist der Stand in den meisten Unternehmen. 4) TOMORROW ZERO TRUST — kein Netzwerk-Perimeter mehr; Vertrauen wird für jede einzelne Interaktion etabliert und konstant validiert. 🟡 Merksatz: "Da steht 'Tomorrow' — aber nicht, wann dieses Morgen ist."

🔵 Das Burgmodell: Daten und Anwendungen liegen im Rechenzentrum innerhalb eines Sicherheitsperimeters; Kontrollen finden beim Betreten/Verlassen statt (VPN, Firewalls). Sobald der User im Netz ist, gilt er als vertrauenswürdig. 🔴 Angreifersicht: Genau dieses interne Vertrauen wird ausgenutzt — "wenn Angreifer einmal drin sind, haben sie freie Hand." 🔵 Heute: verteilte Daten und Nutzer, "Any-Any-Any", multinationales Hosting, Internet als neues Backbone, kein Unternehmensnetzwerk, kein einziger Perimeter. Kernerkenntnis: "Wir können das Internet nicht kontrollieren."

🔵 1) Networks and perimeters → RESOURCES, NOT NETWORKS • 2) Binary trust in devices → SECURE ALL COMMUNICATION • 3) Static access → DYNAMIC, PER-SESSION ACCESS • 4) Trust based on credentials → CONTEXT-BASED, DYNAMIC DECISIONS • 5) Implicit trust inside the network → NO ASSET IS INHERENTLY TRUSTED • 6) Partial monitoring → CONTINUOUS MONITORING, ANALYSIS, AUTOMATION • 7) Static authentication → CONTINUOUS / RE-AUTHENTICATION.

🔵 1) THIRD PARTY RISKS — Gäste, Berater, Hersteller, Lieferanten in unseren Netzen; Supply-Chain-Angriffe. 2) INSIDER THREATS — nicht nur böswillig, vor allem aus Unwissenheit (Klassiker: Berechtigungen bleiben beim Fachbereichswechsel bestehen). 3) EXTERNAL THREATS — Phishing, Ransomware, Malware; Zero Trust wirkt über Segmentierung: jedes Asset ist sein eigener Perimeter → Blast Radius verkleinert sich, Lateral Movement wird eingedämmt. 4) INFORMATION DISCLOSURE — Daten klassifiziert, mehr Verschlüsselung, Integritäts- und Zugriffsüberwachung auf Anomalien. 5) ENDPOINT SECURITY RISK — Remote-Arbeit, BYOD, unsichere Heimnetze; risikobehaftete Geräte früh erkennen und in Quarantäne setzen.

🔵 IDENTITÄTEN: Zero-Trust-Richtlinien steuern; Zugriff aller Benutzer und privilegierten Konten mit SSO, MFA und Lebenszyklusmanagement (personen- UND maschinenbezogen). 🔵 DATEN: kritische Daten erkennen, klassifizieren, verwalten; Zugriff risikoabhängig steuern. 🔵 GERÄTE/WORKFLOWS/APPLIKATIONEN: Security by Design, Überwachung und Verwaltung von Endpunkten. 🔵 ANALYSE UND TRANSPARENZ: Richtlinien permanent überwachen und durchsetzen mittels intelligenter Analyse. 🔵 AUTOMATISIERUNG UND ORCHESTRIERUNG: schnell reagieren (blocken, Quarantäne) und ebenso schnell validieren (Playbooks). 🔵 NETZE UND ENDGERÄTE: moderne Schutztechnologien.

🔵 Kontext ist NICHT nur "welcher Benutzer loggt sich ein", sondern: WELCHER BENUTZER, auf WELCHE DATEN, von WELCHEM RECHNER/welcher Ressource, von WELCHEM ORT, zu WELCHER ZEIT — und ist das TYPISCHES VERHALTEN? 🟢 Ablauf: Signals → Risiko-Score → risikoabhängige Maßnahmen / dynamische Policies. 🔵 Abgrenzung: Es geht nicht um blinde Datensammelwut, sondern darum, Daten anzureichern und daraus den Kontext abzuleiten.

🔵 1) Zusammenhang hinreichend definieren — welche Information bekommen wir woher, was brauchen wir? • 2) Schnell und konsistent validieren (Geschwindigkeit = Erfolgsfaktor, sonst fehlt die Akzeptanz) • 3) Policies aktiv und permanent umsetzen und überprüfen • 4) Sicherheitsverstöße und False Positives schnell beheben, mit minimalen Auswirkungen (gezielt einzelnen Benutzern Zugriff entziehen statt ganze Unternehmensteile abzuschalten) • 5) Permanent verbessern. 🔵 Positiver Nebeneffekt: Kontext bringt mehr Flexibilität — Zugriffe werden möglich, die traditionell pauschal verboten worden wären.

🔵 CONSUMING ENTITIES (Benutzer, Geräte, IoT) stellen Anfragen an PROVIDING ENTITIES (Daten, Applikationen, Cloud-Ressourcen). Dazwischen sitzt die POLICY ENGINE. 🔵 SUPPORTIVE MECHANISMS, die den Kontext liefern: Continuous Monitoring, Policies, Identity (Directory, IdP), Behavior Analysis, Security Logs, Threat Intelligence, historische Daten. 🔴 In fünf Schritten: (1) Welcher Benutzer? (2) Worauf will er zugreifen? (3) Kontext und Risiko der Anfrage (Identität allein reicht nicht — sie kann gestohlen sein). (4) Policy Enforcement (nicht 0/1, sondern abgestuft). (5) Verbindung wird hergestellt. 🟡 Merksatz: Das passiert für JEDEN Zugriff zwischen JEDEM Asset — permanent.

🔵 Szenario: User im USA-Urlaub, nur privater Mac (unmanaged device), will dringend eine Mail bearbeiten, den Anhang herunterladen und im Hotel ausdrucken. 🔵 Common app? Ja → Risk Score 0, Zugriff erlaubt. 🔴 Managed Device? Nein → Risiko steigt → kein SSO mehr, MFA erforderlich. 🔴 Bekannte Location? Nein → Risiko steigt weiter (Risikowert je Land hinterlegbar). 🔴 Download beabsichtigt? Ja → weiteres Risiko → z.B. Browser-Isolation. 🟡 🔥 Merksatz: Zero Trust unterbindet NICHT kategorisch, sondern ergreift ABGESTUFTE zusätzliche Sicherheitsmaßnahmen. In der alten Welt hätte man nur gefragt: "Zugriff aus den USA — ja oder nein?"

🔵 1) VERIFY EXPLICITLY / verify each access explicitly — alle verfügbaren Kontextdaten in Authentifizierung und Autorisierung einbeziehen. "IDENTITY IS THE NEW PERIMETER" (Personen UND Maschinen). 2) (ADAPTIVE) LEAST PRIVILEGE — nur so viel Zugriff wie nötig, JUST-ENOUGH und JUST-IN-TIME; "adaptiv" heißt kontextbasiert. 3) ASSUME BREACH — Sichtbarkeit, Erkennung und Eindämmung von Angriffen bereitstellen; "Wir werden irgendwann alle gehackt werden, wenn wir es nicht schon sind."

🔵 CORE DOMAINS (technisch im Griff haben): Identitäten, Devices, Netzwerke, Daten, Workloads. 🔵 ENABLING LAYER: Automation & Orchestration sowie Telemetrie & Analyse. 🔵 Voraussetzung sind die klassischen Disziplinen, allen voran permanentes Patchmanagement. 🔵 Zero Trust ist TRANSFORMATIV: Es verändert die Architektur über die Zeit, die operativen Prozesse ("ich setze nicht mehr Regeln um, sondern reagiere auf Meldungen") und die Art, wie wir arbeiten (zwei bis drei Klicks mehr) — deshalb müssen viele Menschen mitgenommen werden. Kultur, Business-IT-Alignment.

🔵 NEIN — Zero Trust hebt Komplexität nicht auf, hilft aber, sie besser zu MANAGEN. 🔴 Wir ziehen nicht mehr die große Mauer, sondern sichern jede einzelne Verbindung hinreichend ab; dann ist verteilte Workload kein Problem mehr, sondern gemanagte Komplexität. 💡 Genau diese Transferleistung ist ein Modulziel und ein typischer Kandidat für die offene Zero-Trust-Frage: eine Herausforderung aus dem Semester nennen und zeigen, wie Zero Trust darauf eine Antwort liefert.

🔵 GENE SPAFFORD (Cyber Security Hall of Fame): "The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards — and even then I have my doubts." 🔵 BRUCE SCHNEIER: "You can't defend. You can't prevent. The only thing you can do is detect and respond." 🔵 Genau dabei hilft Zero Trust: Weil jede Identität ihr eigener Perimeter ist, lässt sich die Response nahezu minimal-invasiv ansetzen.

🟡 Die LAYER müssen NICHT auswendig gekannt werden. 🔵 Kernbotschaft: Zero Trust lässt sich mit VORHANDENEN Technologien umsetzen und an unterschiedliche Umgebungen anpassen — "wir müssen keinen Wust neuer Technologien kaufen". 🔵 Zwei Elementtypen: der POLICY DECISION POINT ("das Gehirn — hier geht der Daumen hoch oder runter, hier wird Least Privilege enforced") und die vielen POLICY ENFORCEMENT POINTS, an denen ein Stück Policy durchgesetzt wird.

🟡 Die drei Vorstandsfragen aus der Praxis des Dozenten: "Machen wir was für Security? … Was machen wir denn da? Und machen wir die richtigen Dinge?" 🔵 Kernaussage: Unternehmen, die Veränderungen effektiv managen, sind erfolgreicher. Viele wissen, dass sie Prozesse verbessern müssen, aber nicht wie — sie geben entweder zu wenig aus oder viel Geld für parallele, nicht zielgerichtete Bemühungen.

🔵 CMM = Capability Maturity Model, vom SOFTWARE ENGINEERING INSTITUTE (SEI), frühe 1990er Jahre, ursprünglich SW-CMM für Software; es bot den Rahmen für Reifegradmodelle in vielen Disziplinen, auch der IT-Architektur. 🔵 Untersucht werden: Status der Architekturprozesse, die Architektur selbst und das Engagement (buy-in) für beides. 🔵 Hauptthemen: Prozessimplementierung und Audit, Qualitätsmessungen, Mitarbeiterkompetenzen, Management von Investitionen.

🔵 ACMM = Architecture Capability Maturity Model des US-HANDELSMINISTERIUMS (US Department of Commerce). 🔵 Aufbau: REIFEGRADMODELL + MERKMALE (Charakteristiken) + SCORECARD.

🔵 LEVEL 0 NICHT EXISTENT — kein EA-Programm. 🔵 LEVEL 1 INITIAL / gerade begonnen — informeller, ad-hoc und lokaler Prozess; Erfolg hängt an individuellen Bemühungen; minimale Verknüpfung mit Geschäftsstrategien. 🔵 LEVEL 2 IN ENTWICKLUNG — grundlegender EA-Prozess dokumentiert, klare Rollen; IT-Vision, Prinzipien, Basis- und Zielarchitektur identifiziert; explizite Verknüpfung zu Geschäftsstrategien. 🔵 LEVEL 3 DEFINIERT — Architektur klar definiert und kommuniziert, Prozess wird weitgehend befolgt; Gap-Analyse und Migrationsplan; Standards vollständig; in Budgetplanung integriert; Security Controls integriert. 🔵 LEVEL 4 MANAGED — EA-Prozess ist Teil der Kultur; KPIs/Qualitätskennzahlen; Senior Management direkt eingebunden; Monitoring & Reporting. 🔵 LEVEL 5 MESSBAR — kontinuierliche Verbesserung (KVP), Verfahren für Standards und Ausnahmen, Metriken zur Optimierung, nahezu 100% Befolgung.

🔵 Der Sprung von LEVEL 3 zu LEVEL 4: ab hier kommen KPIs dazu. 🟡 Dozent explizit: "Ich glaube, die Grenze zwischen kein KPI und KPI ist das, was hinreichend ist." 🟡 Faustregel: Je höher der Reifegrad, desto mehr Prozesse, mehr Dokumentation, durchgängigere Befolgung — und ab Level 4 KPIs.

🟡 Es reicht zu wissen: ES GIBT NEUN ANWENDUNGSFELDER/ASPEKTE — sie müssen NICHT auswendig gekonnt werden. 🔵 Zur Orientierung: 1) Architekturprozess • 2) Architekturentwicklung • 3) Geschäftsbezug (business linkage) • 4) Einbindung des Topmanagements • 5) Beteiligung der operativen Einheiten • 6) Kommunikation • 7) IT-Security • 8) Governance • 9) Investitions-/Beschaffungsstrategie.

🔴 SCHRITT 1 — SOLL-ZUSTAND DEFINIEREN: Für JEDE Charakteristik ein gewünschtes Ziel-Level festlegen (nicht per Gießkanne alles auf 5!). Beispiel: Security soll 5, Kommunikation vielleicht nur 3. Die Scorecard muss konsensfähig und optimalerweise mit dem Top-Management abgestimmt sein. 🔵 SCHRITT 2 — IST-ZUSTAND REGELMÄSSIG MESSEN (z.B. jährlich/halbjährlich, im Rahmen der Investitionsplanung). 🟢 SCHRITT 3 — MASSNAHMENKATALOG ABSTIMMEN: "Wie komme ich von A nach B?" — Maßnahmen je Charakteristik hinterlegen, ggf. Soll-Scorecard überarbeiten.

🟡 Praxis-Warnung des Dozenten: Er hatte rot/gelb/grün so gesetzt, dass nur Level 4 und 5 grün waren — "vielleicht war das nicht der geschickteste Schachzug". 🟢 RICHTIG: Der ZIEL-Reifegrad ist grün, egal ob das 2, 3, 4 oder 5 ist. Häufig ist Level 3 vollkommen ausreichend. 🔴 Overengineering-Warnung: Eine quartalsweise zu pflegende Excel-Roadmap mit zu vielen Details war das erste Projekt, bei dem "wir mit dem Thema Architektur erfolgreich gescheitert sind".

🔵 CMMI = Capability Maturity Model INTEGRATION, ebenfalls vom SEI. 🔴 Problem: Die Vielzahl verfügbarer Reifegradmodelle erzeugte die Frage, wie man sie zu einer aussagekräftigen Gesamtreife integriert. 🟢 Antwort: Multi-Modell-Integration, stärkere Verknüpfung mit Unternehmenszielen, mehr Best Practices, größere Transparenz über den Produktlebenszyklus.

🔵 1) Es gibt SECHS Reifegrade (0-5) und NEUN Anwendungsfelder/Aspekte. 2) Das Vorgehen: Soll-Zustand definieren → Ist-Zustand messen → Maßnahmen vereinbaren. 3) Das Modell besteht aus Modell + Scorecard. 4) Je höher der Reifegrad, desto mehr Prozesse/Dokumentation/durchgängige Befolgung — und ab Level 4 KPIs. 5) Der Ziel-Reifegrad wird PRO ASPEKT festgelegt, nicht pauschal. 🟡 NICHT auswendig: die Texte der sechs Reifegrade, die neun Aspekte. 🟡 Erwartung des Dozenten: maximal zwei Fragen aus dem MC-Kontingent.

🔵 Eine einfache, konzeptionelle Technik, um FRÜHZEITIG mögliche Schwachstellen und Bedrohungen an dem zu identifizieren, was man baut — und daraus Sicherheitsmaßnahmen abzuleiten. 🔵 Nicht nur für Architekten, Security-Spezialisten oder Programmierer: "Eine Methode, die jeder von Ihnen beherrscht und tagtäglich mindestens einmal durchführt, ohne es zu wissen." 🔵 Zwei Disziplinen kommen zusammen: der Nicht-Security-Spezialist findet die BEDROHUNGEN, der (Security-)Architekt findet die MASSNAHMEN.

🔵 Sicherheitsniveau von vornherein verbessern (Security by Design) • gutes Aufwand-Nutzen-Verhältnis (Workshop-Charakter, schnell viele Ergebnisse) • Findings aus Penetration Testing reduzieren und die Qualität der Tests verbessern • Lerneffekt/Schwarmintelligenz im Unternehmen • in allen Arten von Teams anwendbar. 🔵 Weiterer Use Case: den Ist-Zustand der Architektur dokumentieren — die Frage "was könnte schiefgehen" liefert die Motivation dafür.

🔵 "JEDER sollte es tun!" 🔵 Analogie: Bedrohungsmodellierung ist wie VERSIONSKONTROLLE — jeder kennt und nutzt sie; manchmal braucht man einen Spezialisten, in großen Projekten sogar Vollzeitkräfte. 🔴 Begründung: Jeder, der mit einem Stück Architektur/IT arbeitet, hat eine andere Sicht darauf, was schiefgehen kann (externer Angreifer vs. unbedarfte Nutzung).

🔵 ITERATIV — "je öfter man es versucht, desto besser die Ergebnisse". Beginn FRÜH im Lebenszyklus, um kritische Sicherheitsanforderungen zu ermitteln, bevor Code geschrieben wird; Grundlage für risikobasierte Sicherheitstests. 🔵 TRIGGER: neues Projekt, größere Veränderungen, neue User Stories/neuer Sprint, neue Technologien (z.B. eine KI-Komponente). 🟡 Merksatz der Folie: Etwa die HÄLFTE der Sicherheitsmängel entsteht durch Implementierungs-/Konfigurationsfehler, die andere Hälfte durch fehlende/falsche Anforderungen oder grundlegende Entwurfsmängel.

🔵 Es gibt KEINEN "richtigen" Weg und keine für alle beste Methode — es kommt auf Projekt, Team und Technologie an. Darstellungsform (Post-its, Whiteboard, Miro, strukturiertes Diagramm) ist Geschmackssache und muss zum Unternehmen passen. 🟢 Alltagsbeispiel: der tägliche Weg zur Arbeit. Was kann schiefgehen? Stau, Baustelle, nicht geräumte Straße. Was tue ich dagegen? Andere Route, U-Bahn. Und rückblickend: War das die richtige Entscheidung? → Das ist bereits ein Threat Model.

🔵 1) WHAT ARE WE WORKING ON? — gemeinsam im Team ein Systemdiagramm erstellen (Datenflussdiagramm, Systemkomponentendiagramm, Zustandsdiagramm); das System buchstäblich in ein Bild bringen, auf das man zeigen kann. 🔵 2) WHAT CAN GO WRONG? — für JEDES Element und JEDE Verbindung im Diagramm die Frage stellen; Annahmen und Bedrohungen dranschreiben. 🔵 3) WHAT ARE WE GOING TO DO ABOUT IT? — Umgang mit den Risiken (→ MEAT). 🔵 4) DID WE DO A GOOD JOB? — Retrospektive: alle wichtigen Bedrohungen erfasst? Die richtigen Controls dokumentiert? Etwas Großes vergessen? (geht erst nach Abschluss).

🔵 M — MITIGATE / Abschwächen: einen Weg finden, die Bedrohung abzuschwächen, z.B. Zugangskontrolle gegen unbefugten Zugriff (Analogie: langsamer fahren). 🔵 E — ELIMINATE / Beseitigen: Geht die Bedrohung von einer Funktion aus, die man nicht braucht → Funktion entfernen bzw. deaktivieren. 🟢 A — ACCEPT / Akzeptieren: bewusst nichts tun, weil es einen guten Grund gibt (jede Maßnahme würde mehr kosten als die Auswirkung) — Grund DOKUMENTIEREN! 💡 T — TRANSFER / Übertragen: Risiko an einen Spezialisten übertragen, z.B. Kreditkartendaten an einen Zahlungsdienstleister. 🟡 Eselsbrücke: funktioniert auf Deutsch wie Englisch — Mitigieren, Eliminieren, Akzeptieren, Transferieren.

🔵 SCHRITT 1 (What are we working on?): Ziel = Hunger stillen. Drei Optionen: liefern lassen / abholen / selbst backen (+ Bezahlung). 🔵 SCHRITT 2 (What can go wrong?): Liefern → Unfall, Stau, kalte/verspätete Lieferung, falsche Pizza. Abholen → Portemonnaie vergessen, verfahren, Laden geschlossen. Selbst backen → Finger verbrannt, Zutaten vergessen, Ofen defekt, Blech fällt runter, eingeschlafen. 🔵 SCHRITT 3 (What are we going to do about it?): Lieferdienst aus der Nähe, festes Zeitfenster bestätigen, Warmhaltebox, vorbestellen, Ofenhandschuh, Fertigpizza vorhalten, Timer stellen, Kartenzahlung. 🟢 Erkenntnis: Einzelne Maßnahmen adressieren oft gleich MEHRERE Bedrohungen. 🟡 ⚠ In der Klausur bitte NICHT Pizza nehmen — das war das Vorlesungsbeispiel!

🔴 Ein Threat Model auf einem Blatt Papier aufmalen können — für ein BELIEBIGES Beispiel, es muss nicht IT-bezogen sein (aber nicht Pizza). 🔵 Umfang: nicht viel mehr als das Tafelbild aus der Übung; lieber ein, zwei zusätzliche Bedrohungen ergänzen, wenn Zeit bleibt. 🔵 LESBARKEIT zählt — keine kryptische Handschrift. 🔴 ⚠ BITTE NICHT FARBIG arbeiten — je nach Scan/Foto kommt die Farbigkeit nicht rüber. 🟢 Darstellung: Bedrohungen über den jeweiligen Zweig schreiben, Maßnahmen/Mitigation darunter oder an den Rand. 🔵 Es reicht zu zeigen, dass man das Vorgehen verstanden hat — keine technische Tiefe verlangt. 🔵 Hilfsmittel: "ein ausgeschlafener, gesunder Geist, ein Stift und zwei, drei Zettel."

🔵 1) Security auf sehr einfache, aber strukturierte, methodische Art besprechen — unter Einbindung ganzer Projektteams (teambildender Charakter, nicht exklusiv für Security-Leute). 2) Das Ergebnis als KOMMUNIKATIONSBASIS nutzen — ausdrücklich NICHT als "Rechtfertigung" (das würde eine Misstrauenskultur unterstellen) — und als Basis für Penetrationstests.

🔵 Termin: 17. Januar. Dauer: 90 Minuten. 🔵 Insgesamt 33 Fragen: 3 OFFENE Fragen + 30 GESCHLOSSENE Fragen. 🔵 Die 30 geschlossenen: großer Teil Wahr/Falsch, dazu Anordnungsaufgaben (Dinge in die richtige Reihenfolge bringen) und Auswahlaufgaben. 🟡 Punkteverteilung steht an jeder Frage — Faustregel: Punkte ≈ empfohlene Bearbeitungsminuten. Die drei offenen Fragen geben jeweils gleich viele Punkte.

🔵 1) THREAT MODEL aufmalen/durchführen (fast sicher). 2) TOGAF ADM — erklären und/oder zeichnen (schriftlich möglich; Zeichnen erlaubt; die Schritte grob zu kennen schadet nicht). 3) ZERO TRUST — "ein Thema, wo man sich ein bisschen drüber auslassen kann, ohne alle Fakten zu brauchen"; typische Fragestellung: eine im Semester diskutierte Herausforderung und wie Zero Trust darauf eine Antwort liefert.

🔵 Bei MC steht "bis zu N Antworten sind richtig" dabei — WER ALLES AUSWÄHLT, LIEGT MIT HOHER WAHRSCHEINLICHKEIT FALSCH. 🔵 In der Testklausur entsprach die Zahl hinter "bis zu" der Anzahl der richtigen Antworten. 🔵 Zu den Fragen gibt es keine hilfreichen Überschriften (nur kryptische Portalbezeichnungen), aber aus der Frage selbst geht das Themengebiet hervor (teils als "Kontext: …"-Vorspann).

🔵 Ein LEERES BLATT bei den offenen Fragen — "sehr viel gewonnene Zeit und verschenkte Punkte". 🔵 Durchfallquote: "nicht viel"; Verteilung ungefähr Normalverteilung mit leichter Verschiebung ins Positive. 🔵 Antwortform bei offenen Fragen: handschriftlich, per Tastatur oder gemischt — alles möglich.

🔵 Folien MIT Sticker sind auf jeden Fall anzuschauen. Folien OHNE Sticker sind NICHT ausgeschlossen. 🔵 Manchmal sitzt der Sticker auf einer zusammenfassenden Folie, während der eigentliche Inhalt drei, vier Folien dahinter steht — dann lohnt es sich, mehr als einen Satz zu lernen. 🔵 "Wenn Sie neben den Folien auch zugehört haben, sollten Sie allen relevanten Content haben."

🟡 Teufelsquadrat nach Sneed (F63) — "dazu wird es nichts zu fragen geben" • CIO-Prioritäten-Tabellen (F89-90) — "Tabellen müssen Sie sich nicht einprägen" • Strategie-Prozess-Synchronisation (F104-106) — "die zwei Folien können Sie geistig ausblenden", nur den Grundgedanken der Sekundär-Funktionsstrategien • Mapping ADM ↔ Enterprise Continuum (F164-165) • Zachman-Struktur auswendig (F181) • SOA-vs-Microservices-Details (F140-148) • Layer der Zero-Trust-Referenzarchitektur (F216) • Paint-Dokumentation (F21) • Business-IT-Alignment als Buzzword (F81, kein Sticker).

🔵 "Kenne dein Unternehmen, verstehe die Organisation, mach dir Gedanken über die Rollen." Deshalb kam die Modellpyramide immer wieder vor — derselbe Grundgedanke "vom Groben ins Feine" findet sich in Zachman, SABSA und TOGAF. 🔵 Clever vs. smart: Der Smarte IMPLEMENTIERT eine gute Lösung — nicht übersteuern, kein Overengineering, keine 100%-Konzeptlösung. 🟡 Klausur: "Seien Sie nicht zu panisch. Zeigen Sie, dass Sie das gesamte Thema Architektur verstanden haben."