=

IT-Architektur – vom IST zum SOLL =Visionen über neue IT-Architekturen entstehen oft auf der grünen Wiese und selten mit Bezug auf die bestehende, über lange Zeit gewachsene IT-Landschaft. Erschwe-rend kommt hinzu, dass existierende IT-Umgebungen oft eine Komplexität erreicht haben, die ohne Hilfsmittel nicht mehr überschaubar ist. Versuche, diese IT-Landschaften darzustellen, enden meist in einem unübersichtlichen Dickicht von Stri-chen und Symbolen, die eher an ein Strickmuster als an eine systematische Darstel-lung einer IT-Architektur erinnern. Nachfolgend stellen wir eine praxiserprobte Me-thode vor, um von einer IST- zu einer SOLL-IT-Architektur zu gelangen. Zentral da-bei ist die systematische und zielgerichtete Dokumentation. Markus Meier, Dr. Dimitrios Tombros Es ist unbestritten, dass eine aktuelle Dokumentation der IT-Landschaft unerlässlich ist für die Entwicklung einer neuen IT-Architektur. Operativ befindet man sich ohne aktuelle IT-Architekturdokumentation ohnehin im Blindflug und ist ausserstande, die Zusammenhän-ge zu verstehen, geschweige denn anderen zu erläutern. Doch wie soll man die Fülle an In-formationen sinnvoll darstellen? Wel-che Sicht ist gefragt? Oft entbrennt eine Prinzipiendiskussion um Tools, Produkte oder Lieferanten. Als Infor-matiker favorisiert man natürlich ein hochintegriertes, grafisches Werk-zeug, das alle Modellelemente in ei-ner zentralen Konfigurationsdaten-bank hält. Bestehende Systeme und ihre Abhängigkeiten müssten vom Tool automatisch erfasst, Attribute vollständig verwaltet und die ge-wünschten Sichten grafisch generiert werden können. Falls ein solches Tool auf interna-tionalen Standards basieren und offene Schnittstellen aufweisen würde, könnten Funkti-onen unterschiedlicher Hersteller kombiniert werden. Leider existiert ein solches Tool heute höchstens in Ansätzen. Um trotzdem erfolgreich IT-Architekturen zu entwickeln und darzustellen, verwendet AWK die folgenden Modelle und Methoden: ITAM (IT Architecture Model), ein von AWK entwickeltes Modellierungsschema TOGAF ADM (Architecture Development Method), auf dem TOGAF-Standard basie-

render Entwicklungsprozess für IT-Architekturen TOGAF TRM (Technical Reference Model), auf dem TOGAF-Standard basierender

generischer Katalog von Komponenten und Services einer IT-Architektur

Beispiel für die unübersichtliche Darstellung einer IT-Architektur

September 2007

Wozu eine IT-Architektur?

=mÉíÉê=d~ÄêáÉäI==m~êíåÉê=^th=dêçìé=

Würden Sie ein Haus bauen ohne einen Architekten? Würden Sie eine Erweite-rung vornehmen ohne detaillierte Bau-pläne des bestehenden Gebäudes? Beim Einfamilienhaus wohl noch machbar, beim Wolkenkratzer schlicht unmöglich! Komplexe IT-Infrastrukturen ähneln Wol-kenkratzern. Hohe Leistungsfähigkeit, Ver-fügbarkeit und Erweiterbarkeit sind nur möglich, wenn die Architektur gut durch-dacht ist und die Realisierung einzelner Teile abgestimmt auf das ganze Bauwerk erfolgt. Unentbehrlich sind aktuelle Bau-pläne in verschiedenen Detaillierungsstu-fen und Ansichten. So wie beim Gebäu-debau separate Standards und Pläne für Elektro, Sanitär und Heizung notwendig sind, so braucht es für eine IT-Infrastruktur Richtlinien und Dokumentationen zu To-pologie, Komponenten, Netzwerk, Da-tenarchitektur, Sicherheit usw. Fehlen eine übergreifende Architektur-sicht, Standards und Richtlinien sowie ak-tuelle Dokumentationen, so wird in jedem Projekt „das Rad wieder neu erfunden“. Bestehende Komponenten werden kaum wiederverwendet und die IT-Landschaft gleicht einem Flickenteppich – mit nega-tiven Konsequenzen auf Performance, Verfügbarkeit und Erweiterbarkeit! Herzlich Ihr

AWK FOKUS April 2007 2/2

ITAM – Darstellung der IT-Architektur mit verschiedenen Sichten ITAM (IT Architecture Model) ist pragmatisch, intuitiv verständlich und hat sich in vielen Projekten bewährt. Bei diesem Ansatz wird zuerst der IST-Zustand der IT-Architektur do-kumentiert (Baseline). Mit demselben Ansatz wird der SOLL-Zustand abgebildet. Aus der dadurch einfach ersichtlichen Differenz vom IST zum SOLL können die notwendigen Schritte für die Migration identifiziert und konkretisiert werden. ITAM ist stark von TOGAF inspiriert (siehe nebenstehende Spalte). Das zugrundeliegende zyklische Mo-dellierungsvorgehen lehnt sich an die Architecture Development Method ADM von TOGAF an. Grundlage von ITAM ist die Erkenntnis, dass IT-Architekturen in verschiede-nen Sichten dargestellt werden können, z.B. in der Sicht Systemtopologie, Datenarchi-tektur oder Sicherheit. Diese Sichten sind vergleichbar mit den unterschiedlichen Archi-tekturplänen beim Hausbau, z.B. für den Elektriker oder den Sanitärinstallateur. Die un-terschiedlichen Sichten sind für den jeweiligen Zweck optimierte Darstellungen. ITAM verwendet ein einfaches und erweiterbares Darstellungskonzept. Mittels ITAM las-sen sich folgende Sichten systematisch erarbeiten und darstellen: 1. Systemtopologie 2. Knoten und Komponenten 3. Verbindungen

4. Datenarchitektur 5. Sicherheit 6. System Management

Die statische Darstel-lung der Systemtopo-logie ist der Einstieg zu ITAM. Zuerst wählt man den darzustellen-den Teil einer IT-Landschaft aus – in un-serem Beispiel die CRM-Applikation. Für die Darstellung werden einfache Symbole ver-wendet, die intuitiv verständlich und leicht nachvollziehbar sind.

PC

FileServer

PrintServer

Laptop

IAM

TerminalServer

Internet

Local Users

Firewall

RAS/VPN

CRM Server CRM DB Server

VPN Remote User

Corporate LAN

póëíÉãíçéçäçÖáÉ=ÉáåÉê=`ojJ^ééäáâ~íáçå=

Der nächste Schritt ist die systematische Be-schreibung aller Knoten und Komponenten mit Knotennamen, Kurzbe-schreibung sowie de-ren wichtigsten funktio-nalen und nicht-funktio-nalen Anforderungen. =Auf die gleiche prag-matische Weise wer-den die anderen Sich-ten beschrieben, z.B. die Verbindungsmatrix (Interfaces) zwischen den Knoten oder die Datenarchitektur.

Knotenname CRM-Server

HW-Plattform Windows Server 2003

Kurzbeschreibung Stellt das Business-Modul Kundenbewirtschaftung zur Verfügung

Produkt AAOO CRM-Server

Interface Kein eigener Interface-Zugriff, nur durch den CRM-Client

Funktion Stellt das Business-Modul Kundenbewirtschaftung autorisierten Be-nutzern zur Verfügung.

Infrastruktur Läuft auf einem Standard Windows 2003 Server

Management Installation, Updates, Start, Stop, Restart, Monitoring

Performance und Kapazität

Performance: Typische Reaktionszeit bei einer Eingabe: < 0.5 s

Typische Antwortzeit für eine Abfrage: < 3 s

Maximale Antwortzeit für eine Abrage: < 10 s

Anzahl interaktive Benutzer parallel: 130

Verfügbarkeit 07:00-17:00 an Arbeitstagen

Sicherheit Steht in der Applikations-DMZ. Nur authentisierte Benutzer haben auf den Server und die Applikation Zugriff.

_ÉëÅÜêÉáÄìåÖ=ÇÉë=`ojJhåçíÉå=

TOGAF – The Open Group Architectural Framework TOGAF ist ein Framework, eine Methode sowie eine Sammlung von Werkzeugen, um eine IT-Architektur zu entwickeln. Open Group ist eine Gemeinschaft neut-raler Mitglieder, in der Hardwareherstel-ler, Softwarelieferanten und Kunden ver-treten sind. Das Ziel von Open Group ist die Entwicklung einer IT-Infrastruktur, die überall eingesetzt werden kann, sicher, zuverlässig und einfach zu benutzen ist. Die vorgeschlagenen IT-Architekturen und Lösungen sollen preiswert, effizient und flexibel einsetzbar sein. TOGAF besteht aus vier Teilen: Einleitung / Übersicht Architecture Development Method

ADM (siehe nachfolgende Grafik): Enterprise Continuum (unter anderem

mit dem Technischen Referenzmodell TRM)

Ressourcen (mit Organisation, Rollen, Aufgaben, Governance, Skills, Views)

Quelle: www.opengroup.org/architecture/togaf

AArchitektur-

Vision BGeschäfts-Architektur

CInformations-

system-Architektur

DTechnologie-Architektur

EChancen

und Lösungen

FMigrations-

planung

GImplementierung

Governance

HChange

Management

Anforderungen

InitialFramework

undPrinzipien

=

Im Bereich Sicherheit konzentriert man sich auf die formale Beschreibung der Autorisie-rung (Autorisierungsprozess, Rollen, Rechte), der Authentisierung (stark/schwach, einge-setzte Hilfsmittel), des Zugriffsschutzes (sowohl Daten- als auch Funktionszugriffsschutz) sowie auf die Gebiete Audit und sichere Kommunikation. Besonders aktuell ist die Be-schreibung von Ausfallszenarien für jede Art von denkbaren Katastrophen. Die formelle Beschreibung der System Management-Sicht ist ein weiterer bedeutender Punkt. Es ist z.B. wichtig zu wissen, wann genau welche Mengen von Daten gesichert werden müssen oder wie die Betriebsmannschaft beurteilen kann, ob die Anwendun-gen richtig laufen und wie diese richtig gestoppt bzw. wieder gestartet werden können.

Der letzte Schritt von ITAM ist der Über-gang von der Statik (System-Topologie) zur Dynamik. Ein oder mehrere Abläu-fe werden Use Case-ähnlich durchge-spielt, um die IT-Architektur zu verifi-zieren. Damit können erneut Schwachstel-len identifiziert und behoben werden.

PC

FileServer

PrintServer

Laptop

IAM

TerminalServer

Internet

Local Users

Firewall

RAS/VPN

CRM Server CRM DB Server

VPN Remote User

2,4

3,11

7

6

10

59

8

1

Corporate LAN

sÉêáÑáâ~íáçåW=aìêÅÜëéáÉäÉå=íóéáëÅÜÉê=^Ää®ìÑÉ= TRM – Technisches Referenzmodell TOGAF definiert im Teil Enterprise Continuum das Technische Referenzmodell (TRM), eine generische Auflistung und Beschreibung aller möglichen Komponenten und Servi-ces einer IT-Architektur. Mittels TRM und ITAM lassen sich die relevanten Komponenten und Services einfach identifizieren und beschreiben. In der nachfolgenden Abbildung ist links die TRM-Übersichtsebene dargestellt und rechts beispielhaft die Detailsicht auf die IT Security Services. Die transparente und systemati-sche Darstellung der Komponenten und Services fördert deren Wiederverwendbarkeit – ein wichtiger Vorteil von ITAM und TRM.

Infrastructure Services

Communication Infrastructure

Man

agem

ent S

ervi

ces

IT S

ecur

ity S

ervi

cesApplication Platform Interfaces

Communication Infrastructure Interfaces

Access Control Services

Authorization Services

System Entry Control Services

Authentication Services

Identification Services

Non-repudiationServices

Audit Services

Trusted Communication

Services

Encryption Services

IT Security ServicesApplications

iáåâë=ÇáÉ=qojJ§ÄÉêëáÅÜíëÉÄÉåÉI=êÉÅÜíë=ÄÉáëéáÉäÜ~Ñí=ÇáÉ=ÇÉí~áääáÉêíÉ=páÅÜí=~ìÑ=ÇáÉ=fq=pÉÅìêáíó=pÉêîáÅÉë==

ITAM-Anwendung bei AWK – ein Beispiel aus der Praxis AWK begegnet oft der Aufgabe, eine exis-tierende IT-Umgebung zu beurteilen. Auch in solchen Fällen kann ITAM von grossem Nut-zen sein, wie das folgende Projektbeispiel zeigt. Das Ziel war, die bestehende IT-Architektur transparent und verständlich darzustellen so-wie allfällige Schwachstellen zu identifizie-ren. Das folgende Systemtopologie-Diagramm (anonymisiert) wurde zusammen mit dem Kunden erstellt:

LAN

VPNUser VPN

DMZ

DB

Appl. User

Citrix Server

OracleUser

User MS

Exp

ort /

Impo

rt

Appl.Server

Citrix Client

Appl Client

Citrix Client

File Server ADS NT4 DC

DB Server Oracle

Die wichtigste Geschäftsanwendung auf dem Applikationsserver sollte von max. 400 Benutzern mittels Terminal Server bedient werden können. Das Thema Sicherheit sollte mit Bezug auf die Konsistenz der Benutzerverwaltung unter-sucht werden. Dazu wurden die Benutzer-verwaltungen blau markiert. Bereits anhand dieser einfachen Darstellung wurde klar, dass die Administration der Benutzer eine besondere Herausforderung darstellt (Verwal-tung der Benutzer in vier verschiedenen Sys-temen, Benutzer müssen sich mehrfach au-thentisieren). Dank ITAM wurde herausgefunden, dass formelle Anforderungen bezüglich Perfor-mance und Skalierbarkeit für die Unterstüt-zung der 400 Benutzer fehlten. ITAM half bei der Identifikation der betroffenen System-komponenten sowie bei deren Dimensionie-rung. Durch die systematische Darstellung aller Sys-temkomponenten mittels ITAM erhielt der Betreiber erstmals eine konsistente System-übersicht mit den gegenseitigen Abhängig-keiten.

AWK FOKUS April 2007 4/4

Vom IST zum SOLL Um von der IST-Architektur (Baseline) zur SOLL-Architektur zu kommen, braucht es eine systematische und zielgerichtete Vorgehensmethodik. AWK verwendet den von der Open Group in TOGAF vorgeschlagenen Architektur-Entwicklungszyklus ADM – ange-reichert mit eigenen Erfahrungen aus dem Praxisalltag. Bei Aufgabenstellungen im Be-reich IT-Architektur ist das Augenmerk vor allem auf folgende Erfolgsfaktoren zu legen: Vision: Ausgangspunkt und Motivation, um eine IT-Architektur neu zu gestalten, ist

meistens eine Vision. Die Vision ist wie der Verkaufsprospekt: Sie muss das Ziel der IT-Architektur glaubhaft vermitteln können.

Architektur Governance: Das A und O für ein IT-Architekturvorhaben ist die Unter-stützung der relevanten Entscheidungsträger. Dies geschieht nur, wenn sie das Vor-haben verstehen. ITAM hilft, das Vorhaben verständlich und transparent zu kommu-nizieren.

Dokumentation der IST-Situation: Ohne detaillierte Bestandesaufnahme der beste-henden IT-Landschaft wird die Überführung in eine SOLL-Architektur mit grosser Wahrscheinlichkeit misslingen.

Pragmatisches Vorgehen: Die eingesetzten Methoden und Tools müssen einfach anzuwenden und breit akzeptiert sein. ITAM als Modellierungsschema und TOGAF ADM als Prozess sind ausgezeichnete Hilfsmittel und Best Practices, um methodisch und systematisch die bestehende IT-Architektur zu dokumentieren und eine neue IT-Architektur zu entwickeln.

Anforderungsmanagement: Anforderungen müssen systematisch erhoben und ver-waltet werden. Ganz wichtig ist, dass jede Anforderung ein Lebenszyklus hat. An-forderungen werden erzeugt, modifiziert, erfüllt, abgelehnt, vertagt, aber nie ge-löscht!

Abstraktionsebenen: IT-Architekturvorhaben sollten in überschaubare Einheiten zer-legt werden. Ebenen unterschiedlicher Abstraktion können helfen, eine Gesamtarchi-tektur verständlicher zu machen. Eine serviceorientierte Sicht ist besonders gut ge-eignet, um die nötige Abstraktion von den konkreten Implementierungstechnologien und Plattformen zu erreichen.

Schlank und kurz: Komplexe Vorhaben müssen in kleinere Arbeitspakete mit kurzer Dauer (max. 3 - 4 Monate) unterteilt werden. Auf diese Weise werden die Ziele greifbar und liegen nicht in der fernen Zukunft.

Iteratives Vorgehen: TOGAF ADM sollte iterativ über den gesamten Prozess, aber auch innerhalb der Projekt-Phasen eingesetzt werden. So könnte als Beispiel das Aufgabenpaket Technologiearchitektur in folgende Schritte unterteilt werden: Grund-lagen schaffen, Sichten identifizieren und erstellen, SOLL-Modell erstellen, technische Services identifizieren, Business und Utility Services identifizieren, Kriterienkatalog für den Variantenentscheid erstellen, detaillierte Technologiearchitektur erarbeiten, Gap-Analyse durchführen usw.

Über die Autoren =

= j~êâìë=^åíçå=jÉáÉê= Markus Anton Meier hat an der ETH Zü-rich Elektrotechnik studiert. Nach Tätigkei-ten bei Landis & Gyr und bei Digital Equipment hat er viele Jahre bei der UBS in verschiedenen Positionen, zuletzt als Leiter Security Engineering, gewirkt. Seit 2005 ist er als Senior Consultant bei AWK tätig. Seine Kernkompetenzen sind IT-Sicherheit und IT-Architektur. markus.meier@awk.ch

aêK=aáãáíêáçë=qçãÄêçë=

Dr. Dimitrios Tombros ist promovierter Wirtschaftsinformatiker und hat einen Master in Computer Systems Engineering von der Universität Stanford. Er ist seit 1999 bei AWK und führt den Bereich In-formationsmanagement. dimitrios.tombros@awk.ch

===

=

AWK ist ein führendes, unabhängiges Schweizer Consulting- und Engineering-Unternehmen für Informations- und Kommunikationssysteme.

AWK Group AG, Leutschenbachstrasse 45, CH-8050 Zürich, Tel. +41 44 305 95 11, www.awk.ch