TU Chemnitz – Ringvorlesung Architekturplanung einer IT ... · • Definition der Strukturierung und der Strategie ther Verbindungen des System Elemente • Bereitstellen der Standards

© Copyright IBM Corporation 2008

TU Chemnitz – Ringvorlesung

Architekturplanung einer IT-Infrastruktur

Torsten Naumann, Advisory IT Architect

Diplom-Informatiker

[email protected]

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


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)


Einleitung und Ziel


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


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)!


Was ist IT Architektur?


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.


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.)


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


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.


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


Die Herausforderung


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


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


Methodisches Vorgehen


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


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 …


1. Nichtfunktionale Anforderungen


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


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


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


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


Fallbeispiel


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


Fallbeispiel


2. System Context


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


Nicht jedes Detail hat eine Funktion im ursprünglichen Sinne.

Sydney Harbour Bridge


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


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


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


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


3. Architectural Overview Diagram


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.


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


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“.


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.


Das AOD unseres zu entwerfenden Systems.

Fallbeispiel

Fire

wa

ll

Fire

wa

ll

Fire

wa

ll


4. Component Model


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.


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


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


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>>


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


5. Operational Model


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.)


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


Übersicht der Kommunikationsverbindungen Fallbeispiel

Aufgrund von vertraulichen Inhalten, wurde dieses Schaubild entfernt.


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


Mapping der Komponenten auf die physikalischen Knoten

Fallbeispiel

Aufgrund von vertraulichen Inhalten, wurde dieses Schaubild entfernt.


6. Architectural Decisions


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?


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


Zusammenfassung


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


Fachliche Karriere bei IBM


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)


Backup - Referenzen


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

Documents

TU Chemnitz – Ringvorlesung Architekturplanung einer IT ... · • Definition der Strukturierung und der Strategie ther Verbindungen des System Elemente • Bereitstellen der Standards