tu chemnitz – ringvorlesung architekturplanung einer it ... · • definition der strukturierung...
Post on 12-Aug-2019
215 Views
Preview:
TRANSCRIPT
© Copyright IBM Corporation 2008
TU Chemnitz – Ringvorlesung
Architekturplanung einer IT-Infrastruktur
Torsten Naumann, Advisory IT Architect
Diplom-Informatiker
tnaumann@de.ibm.com
2 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Agenda
1. Einleitung und Ziel
2. Was ist IT Architektur?
3. Die Herausforderung
4. Methodisches Vorgehen
5. Zusammenfassung
6. Karriere bei IBM
3 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Curriculum Vitae - Torsten NaumannAdvisory IT Architect, Diplom-Informatiker
Beruflicher Werdegang
2003 - heute Advisory IT Architect , ApplicationInfrastructure, IBM ITS
2000 – 2003 IT Specialist, Application Infrastructure, IBM ITS
1998 – 2000 IT Spezialist für Netzwerke und Systeme, debis Systemhaus GEI mbh
1997 Freier Mitarbeiter, Netzwerkplanung, Online-Projekt, Rheinpfalz Verlag und Druckerei
1996 – 1997 Freier Mitarbeiter, Netzwerkplannug, Freie Presse Online, www.freiepresse.de
1994 – 1996 Softwareentwickler im Fraunhofer Institut –IWU - Chemnitz
1994 – 1997 Mitgründer des Chemnitzer StudentenNetzes
1991 – 1997 Studium der Informatik, TU Chemnitz
1988 – 1991 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 ixMultiuser 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, 2004-2007)
� Planung und Durchführung von Plattformmigrationen u.a. von Borland JBuilder und Tomcat zu WebSphere (2002 -2004)
� Technische Koordination bei der Implementierung einer B2T (Business to Trade) Plattform für einen grossenMobilfunkgeräte Anbieter (IT Spezialist, Auslandseinsatz, 2000)
� Implementierung und Betrieb von WebSphere Infrastruktur Lösungen in verschieden Branchen vorrangig Finanz (IT Spezialist, 2000 – 2001)
4 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Einleitung und Ziel
5 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
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
6 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
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)!
7 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Was ist IT Architektur?
8 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
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.
9 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
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 acomputer or computer-based system from the point of view of its use or design; a particular realization of this.
1962 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.)
10 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Veröffentlichungen und Standardisierungen
� The Open Group– The Open Group Architecture Framework,
http://www.opengroup.org/architecture/togaf/
� IBM– IBM Systems Journal *, Vol. 38, No. 1, 1999, http://www.research.ibm.com/journal/sj38-1.html
� 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, http://www.ibm.com/developerworks/rational/library/08/0108_cooks-cripps-spaas/index.html
* Selbt Microsoft referenziert diese Veröffentlichung: http://msdn.microsoft.com/en-us/library/bb421528.aspx
11 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Enterprise Architecture“Der Bebauungsplan derStadt"
Solution Architecture�Funktionall Aspekte�Operationalle Aspekte
“Die Infrastruktur und das Design eines einzelnesGebäudes"
ProjektFokus
Unternehmens-weiterFokus
Design und
Implementierung
Planung
Strategie
Business Opportunity
Business Operating Environment and IT Infrastructure
Business Strategy
Information Technology
Strategy
Technology Availability
Enterprise Architecture
Business Architecture
- Processes- Information- People- Locations
- Applications- Data- Technology
IT Architecture
IT Solutions
Transition Plan
Die erfolgreiche Umsetzung der Geschäftsstrategie in eine effiziente IT Lösungerfordert Architecural Thinking auf verschiedenen Ebenen und in unterschiedlichen Architekturtypen.
12 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
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
13 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Die Herausforderung
14 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
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
15 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Die nichtfunktionalen Anforderungen im Bereich der Sicherheit (Auszug) werden die Infrastruktur Architektur maßgeblich beeinflussen.
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
SEC_NF_05
Über die TAM Komponenten soll ein Single Sign-On mit WebSphere AS und SAP Portal möglich sein.SEC_NF_04
Kein dirketer Zugriff auf Security Komponenten aus der DMZ und dem Intranet.SEC_NF_03
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. SEC_NF_02
Der Zugriff auf Anwendungen aus dem Internet darf nicht mit internen Benutzerkennungen möglich sein.
SEC_NF_01
Anforderungen an die SicherheitNr.
Fallbeispiel
16 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Methodisches Vorgehen
17 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Architektur Work Products geben eine konsistente Sicht inklusive dergeschäftlichen, Anwendungs- und Infrastruktur-Ebene über die gesamteArchitektur und deren Aufbau.
Reference Architecture
Fit/Gap Analysis Architecture
Overview Diagram
Architectural Decisions
Technical Transaction
Map
Parametric Costs
Non-functional Requirements
IT Services Strategy
Deployment Units
Viability Assessment
Technical PrototypeTechnical Prototype
Service Level Char.
AnalysisCurrent IT Environment
Standards
Software Distribution
Plan
Change Cases
Performance Model
Operational Model
Operational
KEY
Shared
ArchitecturalTemplate
ArchitecturalTemplate
Use Case Model
Use Case Model Component
ModelComponent
Model
ClassDiagram
ClassDiagram
SystemContext SystemContext UI
ConceptualModel
UIConceptual
Model
UIDesign
Guidelines
UIDesign
Guidelines
Input WPs to the
ArchitectureDomain
Input WPs to the
ArchitectureDomain
Functional
18 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Wie funktionert der Ablauf?System Context Diagram
Business Roles and Locations
User Groups
AnalyseVerifikationKomplettierungPriorisierung
BusinessCase
Current IT Environment
Reference Architecture
Process Definition
Use Case Model NFRs
…
OperationalModel
ComponentModel
ArchitecuralDecisions
…
Architectural Thinking
SystemContext
AOD …
19 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
1. Nichtfunktionale Anforderungen
20 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
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
21 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Was sind die Zusammenhänge bzgl. der Anforderungen?
Enterprise Architecture
Project Context
Business Case Requirements Gathering and Analysis
Functional Requirements
Nonfunctional Requirements
FutureRequirements
RuntimeNon-runtime
Qualities
BusinessTechnology
Constraints
22 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Nichtfunktionale Anforderungen müssen prezise dokumentiert werden. Sie sind ausschlaggebend für Architekturentscheidungen.
Failover1 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?
Throughput5 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 werden7 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?
Performance13 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?
Sonstige Daten/Anmerkungen/Fragen30 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?
Architectural Decisions
Führen zu
Beziehen sich auf
23 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Die Sicherheitsanforderungen (nichtfunktionale) des Kunden an die Architektur der Plattform.
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
SEC_NF_05
Über die Access Manager Komponenten soll ein Single Sign-On mit WebSphere Application Server und SAP Portal möglich sein.SEC_NF_04
Kein dirketer Zugriff auf Security Komponenten aus der DMZ und dem Intranet.SEC_NF_03
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. SEC_NF_02
Der Zugriff auf Anwendungen aus dem Internet darf nicht mit internen Benutzerkennungen möglich sein.
SEC_NF_01
Anforderungen an die SicherheitNr.
Fallbeispiel
24 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Die Anforderungen (nichtfunktionale) an die Managebarkeit des Kunden an die Architektur der Plattform.
Dezentrale Pflege von Berechtigungen durch FachbereichMAN_NF_05
Die Anwendungslogs müssen zentral bereitgestellt werden. Entwickler müssen diese Logs herunterladen und einsehen können.
MAN_NF_04
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.
MAN_NF_03
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.
MAN_NF_02
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.
MAN_NF_01
Anforderungen an die SicherheitNr.
Fallbeispiel
25 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
2. System Context
26 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Warum spielt der System Context eine Rolle?
The Tacoma Narrows Bridge Disaster,
near the city of Tacoma, Washington, USA
November 7, 1940
http://www.youtube.com/watch?v=3mclp9QmCGs
QuickTime Movie
27 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Nicht jedes Detail hat eine Funktion im ursprünglichen Sinne.
Sydney Harbour Bridge
28 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Der System Context definiert das System als eine Entität und identifiziert die Schnittstellen zwischen dem System und externen Entitäten.
� 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
Zusammenfassung:
Der System Context dient der Definition des kompletten Umfangs des Systems.
System Context
SystemBroker
Regulator
ConsumerSupplier
Supplier
Internet
Intranet
VPN
Payroll System
Print run
29 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
System Context Diagram
Internet User
Intranet User
Administrator
Integrated
WAS 61 TAM 6.0
Plattform
01:Browse Content
Use Applications
02: Browse Content
Use Applications
03: Administer System
Internet
WebServicesActive
DirectoryX.500
WAS 5.1
Plattform
Internal
DB Servers
Internal
MQ Servers
Internal SAP
Systems
04: Send / Receive
Messages
05: CRUD Data
06: CRUD Data
Start / Stop processes
10: Call Internet
Web Services
09: Authentication08: Update User, Group
Records
07: Authentication /
Authorization
FB Administrator
11: Administer User
Access Rights
Fallbeispiel
30 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Jede externe Entität wird typisiert und beschrieben.
KundeIm MAN Intranet existierende SAP Backend SystemeExternalSystem
Internal SAP Systems
KundeIm MAN Intranet existierende Datenbank Server, welche Anwendungsdaten enthalten.ExternalSystem
Internal DB Servers
KundeIm MAN Intranet existierende MQ Server, welche Anwendungsdaten bereitstellen und verarbeiten.
ExternalSystem
Internal MQ Servers
KundeAlte WAS 5.1 Plattform, welche nach einer Migration die Security Komponenten (TAM, TDS) der neuen Plattform (Infrastruktur) mit benutzen soll.
ExternalSystem
WAS 5.1 Plattform
KundeUser Registry aus der die Updates (Neue User, Änderungen, Löschungen, etc.) in das System importiert werden.
ExternalSystem
X.500
KundeActive Directory für die SSO-Integration mit der Windows AnmeldungExternalSystem
Active Directory
ExternIm Internet angebotene Web Services, die aktive vom System angefragt werden.ExternalSystem
Internet Web Services
KundeAdministratoren aus den Fachbereichen zur Vergabe von Rechten für die Fachbereichsanwendungen (dezentrale Administration) (siehe MAN_NF_05)
ActorFB Administrator
KundeAdministrator, der aus dem Intranet administrative Tätigkeiten auf allen Systemen ausführen kann. Dies geschieht über gesicherte Kanäle (SSH, etc.)
ActorAdministrator
KundeNutzer der aus dem Intranet mit Hilfe eines handelsüblichen Browsers per HTTP(S) auf das System zugreift.
ActorIntranet User
ExternNutzer der aus dem Internet mit Hilfe eines handelsüblichen Browsers per HTTP(S) auf das System zugreift.
ActorInternet User
Gehört zu
BeschreibungTypName
Fallbeispiel
31 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Alle Daten- und Kontrollflüssen zwischen dem System und der Außenwelt werden qualifiziert beschrieben. (Auszug)
asynchronInput:Send MQ MessagesPublish, Subscribe TopicsOutput:Receive MQ Messages
04: Send / ReceiveMessages
6 – 19synchronInput:Interactive (synchron) session using SSH, SCP, XWinOutput:Synchron session
03: Administer System
6 – 19hsynchronInput:HTTP(s) RequestOutput:HTML Pages, Cookies, etc.
02: Browse Content / UseApplications
7 x 24synchronInput:HTTP(s) Request (Statischer und Dynamischer Inhalt), SelbstregistrierungOutput:HTML Pages, Cookies, etc.
01: Browse Content / UseApplications
Zugriffzeit
Eigenschaften, Volumen
Input/OutputFlow
Fallbeispiel
32 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
3. Architectural Overview Diagram
33 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
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.
34 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Welche Informationen fließen in das AOD ein und welchen WorkProducts dient es als Input.
Use Cases NFRs System
ContextExisting
ITand so on...
Architecture Overview Diagram
Component Model
Operational Model
Anforderungen
IT Lösung
35 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Ein Beispiel eines AOD.
Client LegacyPresentation &Formatting
Integration & ApplicnServer
BrowserHTMLPage
JVMJava
Applet
DeliveryHTMLPage
FormatterHTMLPage
JVMJava
Servlet
Web Server
TransactionManagemt
BrowserHTMLPage
LegacySystem
1
IntegrationMgmt
StateManagemt
LegacySystem
2
Static HTML pagesSHTML pagesJava AppletsJava Servlets
etc
ApplicnServer
transaction stateapplication statemetadata for backend workflow
Dieses AOD ist aus der Reference Architecture “Thin Client Transactional“.
36 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Noch ein Beispiel eines AOD.The Retail Customer
EnterpriseServerInfrastructure
NetworkInfrastructure
AgentBrokersConsultantAccount Executive
Expert
MailKiosk FAXE-MailCSR IVR PC/Internet
*
* = Phone/ Screen Phone
EFT PrivateBranding/White Labeling
Administrator
"Middleware"Data AccessCall ManagementWorkflow and Queue MgmtReporting, etc.
Data BasesIndividualGroupMortgageCust.Info.Contact, etc.
Sales Office
Common Business
Transactions
Host System
Data Bases
Einzelhändler Zugriffspunkte —Der Einzelhändler kann aus vielen Zugriffwegen auswählen, wie er mit demUnternehmen kommunizieren möchte. Die Infrastruktur sollte so generisch wie möglich sein.
37 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Das AOD unseres zu entwerfenden Systems.
Fallbeispiel
Fire
wa
ll
Fire
wa
ll
Fire
wa
ll
38 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
4. Component Model
39 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
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.
40 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
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
41 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Das AOD eines Home Shopping Systems als Beispiel.
Users Delivery Channels Business Services TechnicalServices
Corporate User (Online)Private User (Online)
Internet Browser
Intranet Browser
Press Services
Jobs Services
E-commerce Services
Store Services
Download Services
Browse and Search Services
Customer Services
Site Statistics Services
Content Management
Site Administration
Registration and ProfileManagement
Head Office IRPCountry IRPIn-store IRP
IntegrationHub
NITFServices(EBC:s)
Other Services
LegacySystems
42 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Das Component Relationship Diagram zeigt die statischen Beziehungen zwischen den Komponenten. (Beispiel)
DialogueControl( from DialogueControl)
<<component>>
CustomerProcessing( from Bus iness Process )
<<component>>
CustomerMgr( from Bus iness Components)
<<component>>
OrderProcessing( from Bus iness Process )
<<component>>
OrderMgr(from Business Components)
<<component>>ProductMgr
(from Business Components)
<<component>>WarehouseMgr
(from Business Components)
<<component>>CreditAuthorisationMgr( from Business Components)
<<component>>MailMgr
(from Business Independent Components)
<<component>>
WarehouseGateway(from Gateway)
<<component>>
CreditAgencyGateway( from Gateway)
<<component>>
EmailGateway( from Gateway)
<<component>>
43 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Das Component Interaction (Sequence) Diagram zeigt die dynamischenBeziehungen 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 lis tadd item
44 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
5. Operational Model
45 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
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 deployedwerden (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.)
46 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Das Operational Model wird in verschieden Sichten erstellt, um die entsprechenden Aspekte klar zu dokumentieren.
� Logische Darstellung von (Kandidaten)-Knoteninkl. Ihrer Verbindungen
� Knoten Beschreibungen
� Knoten Kommunikations-Matrix
� Knoten Deployment Mapping
� Verschiedene Sichten der Architektur, inkl.:
� Netzwerk Topologie
� Skalierbarkeit
� Sicherheit
� Systems Management
� Entwicklungs- und Testumgebungen
� Walk-Through zur Demonstration der Interaktionen zw. Knoten und Komponenten
Web ServerNode
Public &
Private N
etworks
Edge S
erver Node
Reverse ProxyNode
TranscoderNode
ExternalGateway Node
ExternalEnvironment
DMZ Internal NetworkCorporateDomain
Web ServicesGateway Node
Protocol F
irewall N
ode
Dom
ain Firew
all Node
Directory &Security Node
Web PortalNode
PersonalizationNode
LocalDatabase
Server Node
Integration HubNode
WebApplication
Server Node
ContentManagement
Node
NetworkIntrusionDetection
Node
SystemsManagement
Node
ExternalServicesDirectory
ClientNode
ExternalSystems Node
EnterpriseDatabase
Server Node
EnterpriseSystems Node
Enterprise F
irewall N
ode
Key:Real-time connection
Store and forwardconnection
3 - SP (P3-II) 375 MHz X 4 way,8 MB L2 Cache, 2 GB RAM
Router
Transcoding Proxy and
Wireless Device Gateway
Server Cluster
JNDI and SNMPTrafficOnly
JDBC andMQ
I
WirelessDevice
Web BrowserIE
Netscape
Web BrowserIE
Netscape
VPN
Internet
RouterCISCO
Firewall
Firewall
Red Zone
RouterCISCO
Load Balancing
Server Cluster
Network
Intrusion
Detection
Firewall
Firewall
RS/6000 44 P Model 270(P3II) 375 MHZ X 1,
4MB L2 Cache, 512 RAM
RS/6000 44 P Model 270(P3II) 375 MHZ X 1,
4MB L2 Cache, 512 RAM
pSeries 640 (P3II) 375 X 1,4 MB L2 Cache, 512MB RAM,
3 - SP (P3-II) 375 MHz X 4 way,
8 MB L2 Cache, 2 GB RAM
2 - pSeries 640 (P3II)375 X 14 MB L2 Cache,
512 MB RAM
pSeries 620 F1450 MHZ X 2 way,
4MB L2 Cache,4 GB RAM
InternalNetwor
kSegment
InternalNetwor
kSegment
EnterpriseServers
andData
Web ServerCluster
ApplicationServer
IntegrationServe
r
InternalNetwor
kSegment
InternalNetwor
kSegment
EnterpriseFirewall
HTTP&HTTPS
HTTPor
MQI
SharedData
1 - SP (P3-II) 375 MHz X 4way, 8MB L2 Cache,
2 GB RAM
pSeries 620 F1450 MHZ X 2 way,
4MB L2 Cache,4 GB RAM
pSeries 640 (P3II) 375 X 1,4 MB L2 Cache,
512MB RAM,
System MgmtServer
Directoryand
Security
SP (P3-II)375 MHz X 4 way,
1 GB RAM
2 -Netfinity 4500R733 MHZ X 2 way,
1MB L2 Cache512 K RAM
Web ServicesGatewayServer
47 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Übersicht der Kommunikationsverbindungen Fallbeispiel
Aufgrund von vertraulichen Inhalten, wurde dieses Schaubild entfernt.
48 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Hochverfügbarkeitsarchitektur des zu entwerfenden Systems
WLM
WLM
WebSEAL 6
(Internet)
Loadbalancer
active / standby
active / active
SAP Portal
active / active
WAS Knoten
Auth Server
WAS DMgr
virtualisiert
Policy Proxy +
Author. Server
virtualisiert
Loadbalancer
active / standby
WLM
WLM
WLM
LDAP Proxy
Internet
active / active
LDAP Proxy
Intranet
active / active
Loadbalancer
active / standby
Cluster IP
Cluster IP
Cluster IP
LDAP Server
Internet
active / active
LDAP Server
Intranet
active / active
WLM
WLM
WLM
active / active
WebSEAL 6
(Intranet)
Loadbalancer
active / standby
WLM
Cluster IP
WLM
WLM
Policy Serveractive / active
active / standby
Intranet
User
Internet
User
Logging Server
virtualisiert
Cluster IP
Cluster IP
Fallbeispiel
49 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Mapping der Komponenten auf die physikalischen Knoten
Fallbeispiel
Aufgrund von vertraulichen Inhalten, wurde dieses Schaubild entfernt.
50 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
6. Architectural Decisions
51 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Die Dokumentation von Architektur Entscheidungen (Architectural Decisions) ist entscheidend für den Prozess der Weiterentwicklung einer Architektur.
� Architektur Entscheidungen müssen strukturiert und nachvollziehbar sein.
� Beschreibung: Warum ist diese Entscheidung notwendig?
� Varianten: Welche Alternativen stehen zur Auswahl?
� Kriterium: Kriterium für die Entscheidung inklusive einer Gewichtung
� Evaluierung: Tabelle zur Gegenüberstellung der gewichteten Alternativen
� Entscheidung: Beschreibung der Entscheidung inkl. Begründung
� Konsequenzen: Implikationen dieser Entscheidungen
� Gründe für einer
Neubewertung: Wann und warum sollte eine neue Bewertung und ggf. Entscheidung in Betracht gezogen werden?
52 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Beschreibung einer Architektur Entscheidung
AD_03
WAS DMgr Verfügbarkeit
In Verbindung stehende Entscheidungen
Abgeleitete Anforderungen
Implikationen
Ein Virtualisierungslösung ist bereits im Einsatz. Damit beschränkt sich diese Lösung auf Standard Technologien. Variante 1 bedingt mindestens eine Lizenz für HP Service Guard. Dieses Level an automatischem Failover ist für dem WAS DMgr nicht notwendig. Die Variante 2 bedingt die Wartung und Pflege der Skripte, die die manuelle Übernahme durchführen. Diese Variante wurde auf Grund des anstehen den Aufwandes für die Pflege der Skripte nicht gewählt.
Begründung
Variante 3 kommt zum Einsatz.Entscheidung
1.Hardware Cluster Lösung (Cold Standby) mit HP ServiceGuarda.mit IP-Adress-Übernahme, Autor. DB auf SAN Storage und Cold StandbyHW
2.Manuelle Übernahme mittels Skripten auf 2. HW-Knotena.Sieh dazu Referenz [18]
3.WAS DMgr läuft auf Virtueller Hardware, das Config Repository liegt im SANa.Bei Ausfall wird manuell eine 2 Maschine gestartetb.Diese Übernimmt die IP-Adresse und mountet das SAN mit den ConfigDatenc.WAS DMgr wird gestartet
Alternativen
Verfügbarkeit des WAS Deployment Manager für administrative ZweckeMotivation
Die Verfügbarkeit soll mit möglichst einfachen und praktikablen Mitteln wieder hergestellt werden können (Komplexität gering halten).
Annahmen
Der WAS Deployment Manager muss für administrative Zwecke, Replikationenverfügbar sein. Für die Laufzeit eines WAS 6.1 Infrastruktur stellt er keinen SPOF dar.Ein Hochverfügbarkeit ist somit nicht zwingend erforderlich.
Sachverhalt bzw. Problem
AD_03AD IDDer WAS Deployment Manager läuft auf virtualisierter Hardware. Nach einem Fehler wird die VM über Restore Mechanismen wiederhergestellt und gestartet.
Architektur-Entscheidung
VerfügbarkeitThemaWAS Deployment ManagerFachgebiet
Fallbeispiel
53 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Zusammenfassung
54 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Zusammenfassung
� IT Architektur– Strukturierung von Soft- und Hardware Komponenten eines IT Systems
– Beziehungen und Schnittstellen zwischen Komponenten des Systems und der Aussenwelt
– Anforderungen des Kunden verstehen und klassifizieren
� IT Architektur Typen– Enterprise Architecture
– Solution Architecture
� Die wichtigsten Artefakte (Work Products)– Nichtfunktionale Anforderungen, System Context, Architectural Overview Diagramm, Architectural
Decisions, Component Model, Operational Model
� Methodisches Vorgehen– Iterativ, erfahrungsbasierend
– Aufeinander aufbauende Work Products
– Bewusste und begründete Auswahl von Alternativen und Dokumentation
55 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Fachliche Karriere bei IBM
56 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
IT Architect Laufbahn
� Ziel wird mit Manager vereinbart
� Manager unterstützt, Auswahl der Projekteinsätze zum Skillaufbau
� Mentor unterstützt fachlich und “öffnet Türen”
� Senior IT Architect (IBM) = Certified IT Architect (The Open Group - worldwide)
57 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Backup - Referenzen
58 © Copyright IBM Corporation 2008TU Chemnitz - Ringvorlesung - Architekturplanung einer IT-Infrastruktur | 5/15/2008
Einige Referenzen von IBM
NYSE – New York Stock Exchangehttp://www.ibm.com/developerworks/websphere/zones/hipods/
http://www.cnn.com/TECH/computing/9902/05/vicweb.idg/
http://www-935.ibm.com/services/us/gbs/bus/html/bcs_retail.htmlhttp://whitepapers.silicon.com/0,39024759,60038465p,00.htm
http://www.theserverside.com/news/thread.tss?thread_id=8906http://findarticles.com/p/articles/mi_m0EIN/is_2001_Sept_6/ai_77860993
top related