TU Chemnitz Ringvorlesung Architekturplanung einer IT-Infrastruktur

Transkript

1 TU Chemnitz Ringvorlesung Architekturplanung einer IT-Infrastruktur Torsten Naumann, Advisory IT Architect Diplom-Informatiker

2 Agenda 1. Einleitung und Ziel 2. Was ist IT Architektur? 3. Die Herausforderung 4. Methodisches Vorgehen 5. Zusammenfassung 6. Karriere bei IBM 2 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

3 Curriculum Vitae - Torsten Naumann Advisory IT Architect, Diplom-Informatiker Beruflicher Werdegang heute Advisory IT Architect, Application Infrastructure, IBM ITS IT Specialist, Application Infrastructure, IBM ITS IT Spezialist für Netzwerke und Systeme, debis Systemhaus GEI mbh 1997 Freier Mitarbeiter, Netzwerkplanung, Online- Projekt, Rheinpfalz Verlag und Druckerei Freier Mitarbeiter, Netzwerkplannug, Freie Presse Online, Softwareentwickler im Fraunhofer Institut IWU - Chemnitz Mitgründer des Chemnitzer StudentenNetzes Studium der Informatik, TU Chemnitz Abitur und Ausbildung zum Facharbeiter für Instandhaltung Veröffentlichungen Redbook WebSphere Application Server 4.0 Advanced Edition Handbook (Co-Author) Fachartikel zu Netzwerkverkehrsmessung in ix Multiuser Multitasking Magazin (Heise Verlag) Schwerpunkte Solution Design von Application Infrastructure Lösungen Infrastruktur Architektur Assessments Technische Leitung und Koordination Kommunikation und Präsentation Projekterfahrung Solution Design einer zentralen WebSphere Tivoli Infrastructure Solution für einen großen Fahrzeugehersteller (2008, Lead IT Architect) IT Infrastructure Assessements von WebSphere und Open Source basierten Infrastrukturen im Banksektor (IT Architect, u.a. im Ausland, ) Planung und Durchführung von Plattformmigrationen u.a. von Borland JBuilder und Tomcat zu WebSphere ( ) Technische Koordination bei der Implementierung einer B2T (Business to Trade) Plattform für einen grossen Mobilfunkgeräte Anbieter (IT Spezialist, Auslandseinsatz, 2000) Implementierung und Betrieb von WebSphere Infrastruktur Lösungen in verschieden Branchen vorrangig Finanz (IT Spezialist, ) 3 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

4 Einleitung und Ziel 4 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

5 Ziel der Vorlesung Am Ende dieser Vorlesung sollen sie in der Lage sein zu: Definieren Was ist eine IT Architektur? Welche unterschiedlichen IT Architektur Typen gibt es? Was sind die wichtigsten Artefakte (Work Products)? Nichtfunktionale Anforderungen, System Kontext, AOD, Architektur Entscheidungen, Komponenten Modell, Operationales Modell Verstehen der Methodik und der Verwendung standardisierter Work Products des Grundgedankens (Idee) wie eine IT Architektur (Infrastruktur) zu entwerfen ist. Was ist nicht Gegenstand: die technische Lösung im Detail zu verstehen. Application Architecture 5 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

6 Motivation Realität Unternehmen (mittlere und große) betreiben Systeme über sehr lange Zeiträume Systeme unterliegen in ihrem Lebenszyklus einer Evolution (Änderungen) Anzahl der Systeme steigt stetig Damit wächst die Komplexität Steigende Anzahl der Komponenten und Schnittstellen Abhängigkeit von anderen Systemen (DB-Backends, Transaktionssysteme, Clearing, etc.) Neue Softwareprodukte, neue Hardware Reale Herausforderungen Heterogene Hard- und Softwarelandschaften, erhöhen die Kosten und das Risiko für den Betrieb Lizenzkosten, Wartungsverträge, Manpower Neue Konzepte und Paradigmen J2EE, Service Orientierte Architektur (SOA), Web 2.0, Virtualiserung (HW, OS, Middleware) Aufwand für Planung und Pflege dieser Infrastrukturen All das ist notwendig um den Geschäftsbetrieb des Unternehmens zu gewährleisten (wenn notwendig 24x7)! 6 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

7 Was ist IT Architektur? 7 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

8 Der Begriff der Architektur Architektur Duden: Baukunst, Baustil, Bauart Herkunft Das Wort Architektur ist zusammengesetzt aus den griechischen Wörtern αρχη [arché] (= Anfang, Ursprung, Grundlage, das Erste ) und τεχνη [techné] = Kunst, Handwerk, auch tectum aus dem Lateinischen - Gebäude. Es ließe sich daher wörtlich mit Erstes Handwerk oder Erste Kunst übersetzen. Architekt Duden: Baukünstler, Baumeister Herkunft Architekten: altgriechisch architékton = Oberster Handwerker (Zimmermann), Baukünstler, Baumeister. 8 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

9 Der Begriff der IT Architektur Oxford English: 1 : The art or science of building or constructing edifices of any kind 2 : The action or process of building 6 : Computing. The conceptual structure and overall logical organization of a computer or computer-based system from the point of view of its use or design; a particular realization of this F. Brooks in W. Buchholz in Planning Computer Systems: ii. 5 : Computer architecture, like other architecture, is the art of determining the needs of the user...and then designing to meet those needs as effectively as possible. IBM Architectural Description Standard: The architecture of an IT system is the structure or structures of the system, which comprise software and hardware components, the externally visible properties of those components, and the relationships among them. (Adapted from Bass, et al.) 9 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

10 Veröffentlichungen und Standardisierungen The Open Group The Open Group Architecture Framework, IBM IBM Systems Journal *, Vol. 38, No. 1, 1999, Enterprise solutions structure A standard for business architecture description A standard for architecture description Technical reference architectures An introduction to the IBM Views and Viewpoints Framework for IT systems, * Selbt Microsoft referenziert diese Veröffentlichung: 10 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

11 Die erfolgreiche Umsetzung der Geschäftsstrategie in eine effiziente IT Lösung erfordert Architecural Thinking auf verschiedenen Ebenen und in unterschiedlichen Architekturtypen. Strategie Business Opportunity Business Strategy Information Technology Strategy Technology Availability Unternehmensweiter Fokus Planung Enterprise Architecture Business Architecture - Processes - Information - People - Locations Transition Plan IT Architecture - Applications - Data - Technology Enterprise Architecture Der Bebauungsplan der Stadt" Projekt Fokus Design und Implementi erung Business Operating Environment and IT Infrastructure IT Solutions Solution Architecture Funktionall Aspekte Operationalle Aspekte Die Infrastruktur und das Design eines einzelnes Gebäudes" 11 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

12 Durch Architectural Thinking auf der Ebene der Lösungsarchitektur entsteht eine komplette System Architektur die mehreren Zwecken dient. Architectural Thinking Aufschlüsseln der Komplexität des IT-Systems Analyse der geforderten Funktionalität zur Identifikation der erforderlichen technischen Komponenten Bereitstellen einer Basis für die Spezifikation des physischen Computer Systems Definition der Strukturierung und der Strategie ther Verbindungen des System Elemente Bereitstellen der Standards und Regeln zur Zusammensetzung und Zerlegung der System Elemente Analyse der Service Level Anforderungen für den Entwurf der Betriebsmittel und prozesse Bereitstellen eines Entscheidungspfades, für die weitere Systementwicklung Qualitäten (Nichtfunktionale Anforderungen) Performance and Capacity Availability Manageability Security Usability Portability Reliability Maintainability Scalability Safety Extensibility Benutzung von Architektur Prinzipien Separation of concerns Information hiding Design by interface Separation of interface and implementation Partitioning and distributing responsibilities 12 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

13 Die Herausforderung 13 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

14 Es soll ein Technologie Update in Verbindung mit einem veränderten Kontext, neuen Anforderungen und Randbedingungen konzipiert werden. Der Kunde ist einer der weltweit größten Hersteller von Fahrzeugen. Veralte Software in Produktion Update auf die aktuellen Produktversionen J2EE Application Server (Websphere Application Server 6.1 Network Deployment) Access Management (Tivoli Access Manager for e-business 6.0) Überholte Technologien Einbeziehung neuer Technologien und Konzepte Desktop Single Sign-On Single Sign-On für alle Web Frontends (WebSphere (J2EE), SAP Portal) Ineffizienzen im Betrieb Berücksichtigung von Erfahrungen (Lessons Learned) aus dem Betrieb der alten Umgebung Verbesserung der Managebarkeit Konsolidierung von Komponenten Reduzierung von Komplexität Anwenden des neuen Netzwerkzonenkonzeptes 14 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

15 Fallbeispiel Die nichtfunktionalen Anforderungen im Bereich der Sicherheit (Auszug) werden die Infrastruktur Architektur maßgeblich beeinflussen. Nr. SEC_NF_01 SEC_NF_02 SEC_NF_03 SEC_NF_04 Anforderungen an die Sicherheit Der Zugriff auf Anwendungen aus dem Internet darf nicht mit internen Benutzerkennungen möglich sein. Durch z.b. Denial-of-Service Attacken aus dem Internet dürfen in keinem Fall interne User in Ihrer täglichen Arbeit beeinträchtigt werden. Kein dirketer Zugriff auf Security Komponenten aus der DMZ und dem Intranet. Über die TAM Komponenten soll ein Single Sign-On mit WebSphere AS und SAP Portal möglich sein. SEC_NF_05 Aus Sicherheitsgründen erfolgt die Kommunikation zwischen den Security- Komponenten grundsätzlich über eine SSL-Verbindung. Dies ist jeweils bei der Konfiguration zu berücksichtigen. Jede Authentifizierung bei der Passwörter im Klartext über die Leitung gehen, muss SSL gesichert sein. Geforderte Schlüsselstärke 128 Bit 15 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

16 Methodisches Vorgehen 16 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

17 Architektur Work Products geben eine konsistente Sicht inklusive der geschäftlichen, Anwendungs- und Infrastruktur-Ebene über die gesamte Architektur und deren Aufbau. Architectural Template Use Case Model Reference Architecture Fit/Gap Analysis Architecture Overview Diagram Component Model Standards Non-functional Requirements Current IT Environment Service Level Char. Analysis Class Diagram KEY Input WPs to to the Architecture Domain Functional Shared System Context UI Conceptual Model UI Design Guidelines Deployment Units Performance Model Operational Model Parametric Costs Technical Transaction Map Software Distribution Plan IT Services Strategy Technical Prototype Viability Assessment Change Cases Operational Architectural Decisions 17 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

18 Wie funktionert der Ablauf? Current IT Environment Business Case System Context Diagram Business Roles and Locations User Groups Reference Architecture Analyse Verifikation Komplettierung Priorisierung System Context Use Case Model NFRs Process Definition Architectural Thinking AOD Component Model Operational Model Architecural Decisions 18 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

19 1. Nichtfunktionale Anforderungen 19 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

20 Welche Arten von Anforderungen gibt es? Funktionale Anforderungen Funktionen, die notwendig sind, damit die Nutzer ihre Arbeit tun können. Beantworten die Frage was will der Kunde (aber nicht wie das erreicht wird). Nichtfunktionale Anforderungen Qualitäten Definieren die Erwartungen und Eigenschaften die das System erfüllen und besitzen soll. Runtime Z.B. Performance or Availability Non-runtime Z.B. Scalability, Maintainability Rahmenbedingungen Gegebenheiten, welche innerhalb des Projektes nicht geändert werden können. Z.B. Gesetzte Technologien, Verfügbare Skills, Budget 20 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

21 Was sind die Zusammenhänge bzgl. der Anforderungen? Project Context Enterprise Architecture Business Case Requirements Gathering and Analysis Functional Requirements Nonfunctional Requirements Future Requirements Qualities Constraints Runtime Non-runtime Business Technology 21 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

22 Nichtfunktionale Anforderungen müssen prezise dokumentiert werden. Sie sind ausschlaggebend für Architekturentscheidungen. Failover 1 Geforderte Verfügbarkeit der Anwendung (24x7, geplante Downtimes, wieviel ungeplante Downtime ist aus Business-Sicht tolerierbar?) 2 Failover muss für den Benutzer transparent sein? 2.1 Wenn nein, was ist eine tolerierbare Aktion wenn nicht transparent (Neuanmeldung + Neueingabe aller Daten )? 3 Wie gross ist eine durchschnittliche HTTPSession in kb? 3.1 Vergrössert sich die Session (linear zur Anzahl der Requests, Anwendungswechsel) oder ist sie nach der Initalisierung stabil? 3.2 Sind die Sessionobjekte(-bäume) serialisierbar? 4 Sind alle Komponenten der HW-Infrastruktur mind. hochverfügbar ausgelegt? (ganze Kette bis Backend, inkl. Netzwerk, FW, etc.) 4.1 Wie schnell steht bei einem HW Ausfall Ersatz HW zur Verfügung? 4.2 Ist bei Ausfall eines RZ sichergestellt, dass die verbleibende HW die gesamte Last tragen kann? Führen zu Throughput 5 Anzahl der User pro Anwendung am Tag, in der Stunde, concurrent? 6 Wird die HTTPSession garantiert beim Verlassen der JVM invalidiert? 6.1 Wie lange ist der Sessiontimeout? d.h. wie lange müssen die Sessiondaten vorgehalten werden 7 Ist die Transaktionsrate bei allen Transaktiontypen bekannt? 7.1 Wenn ja wie hoch ist diese (pro Tag, pro Stunde (normale Stunden und evtl. Peakzeiten)) 7.2 Ist der realistische Produktionsmix der Transaktionen bekannt? (essentiell für realistsiche Berechnungen und Tests) 8 Wie ist das Verhältnis von UserRequest <-> ServletRequest <-> DB Zugriffe <-> Backendtransaktionen? 9 Wie gross sind die übermittelten Daten pro TX? 10 Können die TX in Punkto Komplexität, Datenübertragung und geforderter Antwortzeit kategorisiert werden? 10.1 Wenn ja, welche Kategorien gibt es? (einfach, komplex, Langläufer) 11 Sind die Peakzeiten bekannt? 11.1 Wieviel höher sind die Tx-Raten in diesen Zeiten? 12 Erhöht sich das Requestaufkommen durch die neuen und geänderten Anwendungen in Release 4.0? 12.1 Wenn ja, um wieviel? 12.2 Um wieviel erhöht sich die Zahl der Nutzer? Performance 13 Welche Anwortzeiten werden gefordert? 13.1 pro TX-Typ? 13.2 Gibt es in dieser Hinsicht Abnahmekriterien (z.b. 90 % unter x sec.)? 13.3 Wenn ja, was sind die Abnahmekriterien? 14 Wird die Antwortzteit gemonitored? 15 Sind WAN Strecken in die Kommunikation zum Backend involviert? Beziehen sich auf Architectural Decisions Sonstige Daten/Anmerkungen/Fragen 30 Mit welchen Tools werden die Lasttests vorgenommen? 31 Gibt es klare, definierte technische Abnahmekriterien im Bezug auf Antwortzeiten, Durchsatz, Verfügbarkeit? 32 Was sind die technischen Abhnahmekriterien? 33 Steht eine separate Lasttestumgebung zur Verfügung? 33.1 Wenn nein, welche Komponenten werden mit anderen Systemen geteilt? 34 Enthält die Anwendung eigene Traceausgaben die für Performance Messungen verwendet werden? 35 Gibt es für alle Komponenten auf dem Anwendungspfad ein Monitoring? 36 Bestehen definierte TestCases für die entsprechenden Lasttests? 36.1 Sind die Lasttestszenarien definiert? 36.2 Existieren bereits Scripts? 22 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

23 Die Sicherheitsanforderungen (nichtfunktionale) des Kunden an die Architektur der Plattform. Fallbeispiel Nr. SEC_NF_01 SEC_NF_02 SEC_NF_03 SEC_NF_04 Anforderungen an die Sicherheit Der Zugriff auf Anwendungen aus dem Internet darf nicht mit internen Benutzerkennungen möglich sein. Durch z.b. Denial-of-Service Attacken aus dem Internet dürfen in keinem Fall interne User in Ihrer täglichen Arbeit beeinträchtigt werden. Kein dirketer Zugriff auf Security Komponenten aus der DMZ und dem Intranet. Über die Access Manager Komponenten soll ein Single Sign-On mit WebSphere Application Server und SAP Portal möglich sein. SEC_NF_05 Aus Sicherheitsgründen erfolgt die Kommunikation zwischen den Security- Komponenten grundsätzlich über eine SSL-Verbindung. Dies ist jeweils bei der Konfiguration zu berücksichtigen. Jede Authentifizierung bei der Passwörter im Klartext über die Leitung gehen, muss SSL gesichert sein. Geforderte Schlüsselstärke 128 Bit 23 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

24 Fallbeispiel Die Anforderungen (nichtfunktionale) an die Managebarkeit des Kunden an die Architektur der Plattform. Nr. MAN_NF_01 MAN_NF_02 MAN_NF_03 MAN_NF_04 MAN_NF_05 Anforderungen an die Sicherheit Anzahl der Installation reduzieren. Möglichst alle Anwendungen nur einmal zentral vorhalten, um den Verwaltungsaufwand (Deployment, Wartung, etc.) zu reduzieren. Die Notwendigkeit der verschiedenen Installationen (WAS 5.1) in den einzelnen Netzsegmenten ist aus heutiger Sicht überflüssig und bietet nicht die ursprünglich versprochene Sicherheit. Die Vielzahl der eingesetzten Komponenten kann aus heutiger Sicht reduziert werden. Einzelne Funktionalitäten können heute durch Kombination verschiedener Produkte alternativ gelöst werden. Aktuell ist hier der Einsatz von WebSEAL als LoadBalancer für die HTTP Server zu nennen. Die Edge Komponenten sollten weitgehend konsolidiert wenn möglich eliminiert werden. Durch die Installationen von Anwendungen in verschiedenen Netzsegmenten mit Zugriff auf Backend-Systeme in anderen Netzsegmenten bestehen Verbindungen teilweise über mehr als eine Firewallgrenze hinweg. Diese Vorgehensweise erscheint aus heutiger Sicht aufwändig, fehleranfällig und unflexibel. Die Anwendungslogs müssen zentral bereitgestellt werden. Entwickler müssen diese Logs herunterladen und einsehen können. Dezentrale Pflege von Berechtigungen durch Fachbereich 24 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

25 2. System Context 25 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

26 Warum spielt der System Context eine Rolle? The Tacoma Narrows Bridge Disaster, near the city of Tacoma, Washington, USA November 7, 1940 QuickTime Movie 26 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

27 Nicht jedes Detail hat eine Funktion im ursprünglichen Sinne. Sydney Harbour Bridge 27 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

28 Der System Context definiert das System als eine Entität und identifiziert die Schnittstellen zwischen dem System und externen Entitäten. System Context Nutzer des System Business Partner Externe Systeme mit direkter Kommunikation ins Unternehmen Externe Ereignisse auf die das System reagieren muss Ereignisse die das System generiert, worauf externe Systeme reagieren müssen Daten von außerhalb des Systems, die verarbeitet werden müssen Daten die das System erzeugt und an die Außenwelt kommuniziert Geschäftliche und/oder Technische Ein- und Ausgaben Externe Geräte Volumen Informationen Zugriffszeiten Consumer Intranet Broker Supplier Supplier Internet System Payroll System Zusammenfassung: Der System Context dient der Definition des kompletten Umfangs des Systems. Regulator VPN Print run 28 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

29 Fallbeispiel System Context Diagram Internet WebServices Active Directory X.500 Internet User 01:Browse Content10: Call Internet Use Applications Web Services 09: Authentication 08: Update User, Group Records Intranet User 02: Browse Content Use Applications Integrated WAS 61 TAM 6.0 Plattform 07: Authentication / Authorization WAS 5.1 Plattform Administrator 03: Administer System 11: Administer User Access Rights 04: Send / Receive Messages 05: CRUD Data 06: CRUD Data Start / Stop processes FB Administrator Internal MQ Servers Internal DB Servers Internal SAP Systems 29 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

30 Fallbeispiel Jede externe Entität wird typisiert und beschrieben. Name Typ Beschreibung Gehört zu Internet User Actor Nutzer der aus dem Internet mit Hilfe eines handelsüblichen Browsers per HTTP(S) auf das System zugreift. Extern Intranet User Actor Nutzer der aus dem Intranet mit Hilfe eines handelsüblichen Browsers per HTTP(S) auf das System zugreift. Kunde Administrator Actor Administrator, der aus dem Intranet administrative Tätigkeiten auf allen Systemen ausführen kann. Dies geschieht über gesicherte Kanäle (SSH, etc.) Kunde FB Administrator Actor Administratoren aus den Fachbereichen zur Vergabe von Rechten für die Fachbereichsanwendungen (dezentrale Administration) (siehe MAN_NF_05) Kunde Internet Web Services External System Im Internet angebotene Web Services, die aktive vom System angefragt werden. Extern Active Directory External System Active Directory für die SSO-Integration mit der Windows Anmeldung Kunde X.500 External System User Registry aus der die Updates (Neue User, Änderungen, Löschungen, etc.) in das System importiert werden. Kunde WAS 5.1 Plattform External System Alte WAS 5.1 Plattform, welche nach einer Migration die Security Komponenten (TAM, TDS) der neuen Plattform (Infrastruktur) mit benutzen soll. Kunde Internal MQ Servers External System Im MAN Intranet existierende MQ Server, welche Anwendungsdaten bereitstellen und verarbeiten. Kunde Internal DB Servers External System Im MAN Intranet existierende Datenbank Server, welche Anwendungsdaten enthalten. Kunde Internal SAP Systems External System Im MAN Intranet existierende SAP Backend Systeme Kunde 30 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

31 Alle Daten- und Kontrollflüssen zwischen dem System und der Außenwelt werden qualifiziert beschrieben. (Auszug) Fallbeispiel Flow Input/Output Eigenschafte n, Volumen Zugriffze it 01: Browse Content / Use Applications Input: HTTP(s) Request (Statischer und Dynamischer Inhalt), Selbstregistrierung Output: HTML Pages, Cookies, etc. synchron 7 x 24 02: Browse Content / Use Applications Input: HTTP(s) Request Output: HTML Pages, Cookies, etc. synchron 6 19h 03: Administer System Input: Interactive (synchron) session using SSH, SCP, XWin Output: Synchron session synchron : Send / Receive Messages Input: Send MQ Messages Publish, Subscribe Topics Output: Receive MQ Messages asynchron 31 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

32 3. Architectural Overview Diagram 32 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

33 Das Architectural Overview Diagram wird zu einem frühen Zeitpunkt erstellt und zeigt den grundsätzlichen Aufbau des Systems. Was ist ein AOD? Das Architecture Overview Diagram (AOD) enthält eine schematische Darstellung der grundlegenden Ideen und geplanten Building Blocks (Komponenten). Es zeigt eine Übersicht der wichtigsten Konzeptionellen Elemente und deren Beziehungen. Welchem Zweck dient es? Es dient der Kommunikation des konzeptionellen Aufbaus des IT Systems mit Auftraggebern. Es ist eine High-Level Vision der Architektur und des Scope der vorgeschlagenen IT Systems für die Entwickler. Es dient der Untersuchung und Evaluierung von Architekturellen Alternativen. Es ermöglicht eine frühzeitige Erkenntnis und ermöglicht eine Validierung der Auswirkungen des Architekturellen Ansatzes. Es unterstützt die effektive Kommunikation zwischen den unterschiedlichen Interessengruppen und den Entwicklern. Es erleichtert die Orientierung für neue Teammitglieder, die später zum Projekt kommen. 33 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

34 Welche Informationen fließen in das AOD ein und welchen Work Products dient es als Input. Anforderungen Use Cases NFRs System Context Existing IT and so on... Architecture Overview Diagram IT Lösung Component Model Operational Model 34 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

35 Ein Beispiel eines AOD. Client Browser HTML Page Presentation & Formatting Delivery HTML Page Web Server Formatter HTML Page Integration & Applicn Server State Managemt Applicn Server Legacy Legacy System 1 JVM Java Applet JVM Java Servlet Transaction Managemt Integration Mgmt Static HTML pages SHTML pages Java Applets Java Servlets etc transaction state application state metadata for backend workflow Legacy System 2 Dieses AOD ist aus der Reference Architecture Thin Client Transactional. 35 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

36 Noch ein Beispiel eines AOD. * = Phone/ Screen Phone The Retail Customer * Agent Sales Office Brokers Consultant Account Executive Expert CSR IVR PC/Internet Kiosk Network Infrastructure EFT Private Branding/ White Labeling Administrator FAX Mail Common Business Transactions "Middleware" Data Access Call Management Workflow and Queue Mgmt Reporting, etc. Data Bases Individual Group Mortgage Cust.Info. Contact, etc. Host System Data Bases Enterprise Server Infrastructure Einzelhändler Zugriffspunkte Der Einzelhändler kann aus vielen Zugriffwegen auswählen, wie er mit dem Unternehmen kommunizieren möchte. Die Infrastruktur sollte so generisch wie möglich sein. 36 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

37 Fallbeispiel Das AOD unseres zu entwerfenden Systems. Firewall Firewall Firewall 37 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

38 4. Component Model 38 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

39 Zur Domäne der Komponenten gehört nicht nur Anwendunsgsoftware, sondern u.a. auch System Software und Hardware. In der Softwareentwicklung wird eine Komponente definiert als... ein gekapselter Teil eines Software Systems mit definierten Schnittstellen, über welche der Zugriff auf die Dienste gewährt wird. Komponenten sind jedoch nicht nur Anwendungskomponenten. Sie können auch folgendes sein: Technische Komponenten System-Software Komponenten Hardware Komponenten Komponenten können aus Komponenten bestehen. Ein Subsystem gruppiert Komponenten, kann aber nicht als Komponente bezeichnet werden, da es keine Schnittstellen hat. Objekte sind i.d.r. keine guten bzw. nützlichen Komponenten. 39 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

40 Wofür ist ein Component Model da? Das Component Model dient der Überbrückung der Kluft zwischen Anforderungen und Lösung, durch: Sicherstellung, dass eine detaillierte Spezifikation erstellt wird. Diese kann im Laufe eines Projektes noch weiter ausgearbeitet werden. Festlegung der wichtigsten Design Prinzipien und Gesamtstruktur. Das Component Model erreicht das, durch Einschränkung auf kleinere Problembereiche, welche in unterschiedlichen Teams behandelt werden. Dabei wird Wiederverwendung gefördert. Jeder dieser Problembereiche kann folgende Schritte zugeordnet haben: Analyse und detailliertes Design Implementierung Logisches und physisches Datenbankmodell 40 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

41 Das AOD eines Home Shopping Systems als Beispiel. Users Delivery Channels Business Services Technical Services Registration and Profile Management Browse and Search Services E-commerce Services Download Services NITF Other Services Services (EBC:s) Corporate User (Online) Private User (Online) Internet Browser Store Services Jobs Services Press Services Integration Hub Customer Services Site Statistics Services Legacy Systems Content Management Head Office IRP Country IRP In-store IRP Intranet Browser Site Administration 41 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

42 Das Component Relationship Diagram zeigt die statischen Beziehungen zwischen den Komponenten. (Beispiel) <<component>> DialogueControl ( from DialogueControl) <<component>> CustomerProcessing ( from Business Process) <<component>> OrderProcessing ( from Business Process) <<component>> CustomerMgr ( from Business Components) <<component>> WarehouseMgr (from Business Components) <<component>> CreditAuthorisationMgr ( from Business Components) <<component>> OrderMgr (from Business Components) <<component>> ProductMgr (from Business Components) <<component>> MailMgr (from Business Independent Components) <<component>> WarehouseGateway (from Gateway) <<component>> CreditAgencyGateway ( from Gateway) <<component>> Gateway ( from Gateway) 42 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

43 Das Component Interaction (Sequence) Diagram zeigt die dynamischen Beziehungen zwischen den Komponenten. (Beispiel) System Boundary Presentation Integration Content Store List & Order Management reques t produc t page get product page change options add to list add item 43 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

44 5. Operational Model 44 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008

45 Das Operational Model wird erstellt, indem die operationalen Aspekte und Anforderungen der Architektur analysiert werden. Das OM beschreibt, wie die Komponenten (Component Model) auf die physikalische Struktur (geografisch) deployed werden Es beschreibt wie die Service Level Anforderungen (SLA) erfüllt werden können und wie das System verwaltet und betrieben wird. Üblicherweise wird es dokumentiert, indem Deployment Units (DU) auf Knoten deployed werden (statische Beziehung). Die Interaktionen der Deployment Units laufen über Verbindungen (dynamisches Verhalten). Komponenten werden entsprechend ihrer Eigenschaften in Deployment Units zerlegt. Diese Eigenschaften sind: Presentation Deployment Unit (Anzeigeelement HTML, Client, etc.) Data Deployment Unit (Konfig-Datei, Datenbank, DB-Tabelle, etc.) Execution Deployment Unit (ausführbarer Code, Programm, etc.) 45 TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur 5/15/2008