»Alle für einen, einer für alle«: 3 Schichten für 1 ...€¦ · ServiceNow Orchestration, BMC...

Juli 2015

»Alle für einen, einer für alle«: 3 Schichten für 1 Management!

Ganzheitliches Configuration Management mit Prozesswerkzeugen im 3-Schichten CMS

2 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!

Juli 2015

Einleitung ................................................................................................................................................................................. 2

1. Alte Besen, neue Besen: Doch welcher kehrt alle Flure? ......................................................................... 3 Besenmodell »Athos«: Der Klassiker für die Technik Besenmodell »Aramis«: Borstenaustausch fürs Service Management Besenmodell »Porthos«: Stilwechsel zum Configuration Management System (CMS)

2. Drei Schichten, ein Management: Einsatzdynamik im CMS .................................................................... 5 Flow – Arbeitsreihenfolge, jetzt auch vertauschungssicher! Fokus – Ich sehe, was ich brauche! Finish – Alle Wege führen ins CMS!

3. Für die Traumhochzeit im Rechenzentrum: Die 3-Schichten-Torte ..................................................... 9 Mit Stil serviert und dekoriert: ITSM Prozesse Edelste Zutaten und Rezeptur: Technische Prozesse Perfekt abgeschmeckt: Management Prozesse

4. Der große Abschlussball: Das 3-Schichten CMS im Einsatz ................................................................. 12 Für jeden der passende Tanzpartner: Reconciliation Für fliegende Partnerwechsel: Federation Ein prächtiges Feuerwerk: Mehrwert im Rechenzentrum

Unser Angebot ..................................................................................................................................................................... 14

Die Autoren ........................................................................................................................................................................... 15

Für Sie als IT Provider ist »Configuration Manage-

ment« wahrscheinlich kein entspanntes Thema für

die Kaffeeküche. Entweder haben Sie bislang keins

eingeführt, was sehr unwahrscheinlich ist. Oder Sie

haben damit scheinbar unbehebbare Probleme. Oder

Sie sind einfach froh, dass es leidlich funktioniert. Zu

welcher Gruppen Sie auch gehören: dieses Whitepa-

per eröffnet Ihnen frische Perspektiven.

Ein effektives und effizientes Configuration Management

ist der Schlüssel zur Wertschöpfung im Rechenzen-

trum, doch unterstützt es mit seinen Tools effektiv

und effizient oft nur die technischen oder nur die IT

Service Management Prozesse.


ist weder mit einem einzelnen Tool erreichbar

noch mit beliebig vielen Tools; entscheidend ist die

geeignete Anzahl an Schichten zur Unterstützung

der verschiedenen Perspektiven im Rechenzentrum.


überwindet alle Herausforderungen durch eine

Strukturierung in drei Schichten, die jeweils die ITSM

Prozesse, die technischen Prozesse und das techni-

sche Management abbilden.

Erfahren Sie in diesem Whitepaper alles Wissens-

werte zum 3-Schichten CMS, um den sogenannten

»Service Gap« im IT-Service Management zu

schließen und Mehrwert im Rechenzentrum zu

generieren!


Juli 2015

1. Alte Besen, neue Besen: Doch welcher kehrt alle Flure?

Ambitioniert, aber wenig realistisch waren die

Bemühungen fast aller IT-Abteilungen noch zur

Jahrtausendwende, im Rahmen eines Configuration

Management Projektes alle Datensammlungen der

IT-Techniker in eine Configuration Management

Datenbank (CMDB) zu überführen. Diese Vision

einer zentral verfügbaren, lückenlosen elektro-

nischen Blaupause der gesamten technischen

IT Infrastruktur führte jedoch meistens nicht zum

Erfolg, und das Configuration Management, das

hier an seine Grenzen stieß, wurde daher oft zum

»Nebendarsteller« in einer servicefixierten

Prozesslandschaft degradiert.

Dies wiederum bereitete den Boden für den soge-

nannten »Service Gap«, wenn Ursachen und Wir-

kungen von Störungen sich durch unterschiedliche

Sichten von Technik und Service Management auf

die IT Infrastruktur nicht zusammenführen lassen.

Eine vollgelaufene Directory Server Partition zum

Beispiel, von der Technik auslastungssbedingt nie-

driger als gewöhnlich priorisiert, wird nicht mit der

hoch priorisierten Störung im Service Management

in Verbindung gebracht, dass ein Kunde sich nicht

mehr am Portal einer Geschäftsapplikation anmel den

kann. Schwierigkeiten bei der Leistungsverrechnung

für erbrachte IT-Services oder die unklärbar erschei-

nende Frage nach tatsächlichen Kapazitätsreserven

für neue IT Services sind weitere Beispiele für die

vielen Symptome dieses Service Gaps.

All diese Barrieren ließen sich mit einem effektiven

und effizienten Configuration Management zuver-

lässig beseitigen. Doch effektiv und effizient kehrt

das Configuration Management mit seinen »Besen«

bzw. Tools oft nur den Flur auf einer Seite des

Service Gaps – entweder die technischen Prozesse

oder die IT Service Management Prozesse.

Besenmodell »Athos«: Der Klassiker für die Technik

Auf der technischen Seite findet sich häufig eine

»klassische« Configuration Management Datenbank

(CMDB) aus den Tagen, als solche Datenbanken

noch Datentöpfe waren, in die alle von den IT

Technikern gepflegten Hard- und Softwarelisten ein-

gerührt wurden.

Dementsprechend enthält eine solche CMDB

hauptsächlich technische Informationen, und die

Relationen zwischen Objekten stellen in der Regel

technische Verbindungen dar. Typischerweise anzu-

treffen sind dabei Daten wie Leistungsaufnahmen

von Servern, Datenbankparameter oder Verkabe-

lungen einschließlich dokumentierter Kabelwege.

Mit diesen Daten werden die Prozesse in den

Technikabteilungen gut unterstützt, für Service Ma-

nagement Prozesse sind diese Informationen jedoch

zumeist unerheblich. Sicherlich kann es auch in einer

technisch orientierten CMDB servicerelevante In-

formationen geben, doch reichen diese in der Regel

nicht aus, um den Service Gap zu überbrücken.


Juli 2015

Besenmodell »Aramis«: Borstenaustausch fürs Service Management

ITIL Version 3, die das »Configuration Manage-

ment« zum »Service Asset and Configuration

Management« (SACM) machte, läutete mit der

Ausrichtung des Configuration Managements

an den IT Services einen Paradigmenwechsel

für die CMDB ein. Von nun an musste sie Daten

und Relationen entlang der Anforderungen aus

den ITIL Service Lifecycle Phasen enthalten wie

Auswirkungs relationen, Soll & Ist Compliance-

Informationen, Betriebskosten und vieles mehr.

Hinzu kam die enge Verzahnung mit den Werk- zeugen zur Unterstützung der Service Management

Prozesse wie Change, Incident oder Problem

Management, wodurch die CMDB auch zum

Bestandteil einer ITSM Suite wurde.

Im Kontrast zur »klassischen« CMDB sind es nun

jedoch die technischen Prozesse, die von dieser

»Service Management« CMDB vernachlässigt

werden – von den CMDBs aller marktführenden

ITSM Suiten löst keine einzige Begeisterung in den

technischen Abteilungen der IT Provider aus. Hier

ist es die Sperrigkeit bei Dokumentation und beim

Abrufen technischer Informationen, die die Über-

windung des Service Gaps verhindern.

Besenmodell »Porthos«: Stilwechsel zum Configuration Management System (CMS)

Ab ITIL V3 wurde die einzelne CMDB abgelöst

durch das Configuration Management System

(CMS), ein mehrschichtiges Gebilde aus verschie-

denen Datentöpfen und Werkzeugen zur Integration,

Verarbeitung und Präsentation von Infrastruktur-

daten. Das Service Asset and Configuration

Management (SACM) nach ITIL 2011 stellt damit

theoretisch durchaus eine Lösung zur Überwindung

des Service Gaps dar, welche sich in der Praxis aber

oft nicht einstellen will.

Diesmal liegt die Hürde in der wenig konkreten

Beschreibung des CMS, was für Toolhersteller

eine technische und für IT Provider eine organisa-

torische Herausforderung darstellt. Der Ansatz,

zunächst SACM nach der Devise »Think Big, Start

Small« einzuführen für einen »Quick Win« in

den businessrelevanten Phasen des ITIL Service

Lifecycles, ist ja an sich richtig, doch wird er danach

meistens nicht mehr fortgeführt.

Bei der manuellen Datenpflege und Dokumenta tion

von Informationen wie Hard- und Softwareausstat-

tung, Leistungs-, Standort-, und Ver bindungsdaten

oder von organisatorischen Daten wie Server-

Administratoren und Kostenstellen wird das

technische Fachpersonal meist nur unzureichend

unterstützt. Der Aufwand übersteigt dann schnell

den Nutzen, den die Techniker aus dieser Arbeit

ziehen können, und wenn die Dokumentations-

qualität in Folge wenig überraschend sinkt, wirkt

sich dies auch negativ auf der Seite des Service

Managements aus. Automatische Discovery Tools

als scheinbare Alternative wiederum können längst

nicht alle benötigten Daten ermitteln – die oft

vollmundigen Versicherungen von Toolherstellern

in dieser Hinsicht malen lediglich ein begehrens-

wertes Luftschloss, das den ersten Kontakt mit der

Realität im Rechenzentrum nicht übersteht.


Juli 2015

2. Drei Schichten, ein Management: Einsatzdynamik im CMS

All dies mündet in der Frage, wie ein ideales CMS

aussehen muss, das den Service Gap tatsächlich

überwinden kann. Viele verschiedene Aspekte

spielen dabei eine Rolle und zur Einführung lohnt es

sich, das Zusammenspiel von Prozessen und Werk-

zeugen am vereinfachten Beispiel der Aufrüstung

eines Datenbankservers zu verdeutlichen.

Mit Hilfe von Servicemodellen aus der CMDB

werden die Verletzungen der Service Level Objec-

tives (SLO) ausgewertet; die Auswertung führt zu der

Erkenntnis, dass die Servicequalität am stärksten

vom Datenbankserver beeinträchtigt wird.

Zur Steigerung der Servicequalität beschließt der

Provider, einen zusätzlichen Datenbankserver zu

installieren.

Die für Server zuständige Technikabteilung wird

mit der Planung zur Installation eines weiteren

Datenbankservers beauftragt.

Mit Hilfe der graphischen Darstellung im Data-

center Management Modul der CMDB findet und

reserviert die technische Abteilung einen verfüg-

baren Rack-Platz und beauftragt die erforderliche

Verstärkung der Stromversorgung.


Juli 2015

Nach entsprechender Vorbereitung wird die

Aufrüstung des Datenbankservers durch einen

Change an einem Termin durchgeführt, an dem die

wenigsten Businessaktivitäten bei den betroffenen

Kunden zu erwarten sind.

Im Change Management Tool ermittelt der Change

Verantwortliche mit Hilfe von Servicemodellen aus

der CMDB die Auswirkungen der Downtime des

Datenbankservers auf verschiedene Services und

die davon betroffenen Kunden.

Mit Hilfe des Rack-Ansicht Moduls der CMDB

versetzt die Technikabteilung den neu installierten

Server in der CMBD vom Planungsstatus in den

Zustand »installiert« und dokumentiert graphisch

die Netzwerkverkabelung des neuen Gerätes.

Die CMDB ist auf dem neuesten Stand.

Zum einen demonstriert das Beispiel, wie Service

Management Prozesse und technische Prozesse

zusammenwirken müssen, um den Service Gap zu

schließen und damit Qualität und Verfügbarkeit

von IT Services nachhaltig sicherzustellen. Zum

anderen demonstriert es die spezifischen Anfor-

derungen an das CMS bezüglich Dateninhalt und

Datenpräsentation, die ein derart reibungsloses

Zusammenwirken erst ermöglichen. Beiden Welten

stehen geeignete Zugänge zu den Daten im CMS

zur Verfügung, beide werden durch das jeweilige

Werkzeugmodul optimal unterstützt.

Ist die Technikabteilung dagegen im letzten Schritt

mangels Rack-Ansicht gezwungen, den neuen

Server über sperrige Formulare einzupflegen, wie

sie für eine CMDB als Teil einer ITSM Suite typisch

sind, wird dieser Vorgang oft aufgeschoben und

sogar vergessen. Die Daten im CMS entsprechen

nicht mehr der Realität und die nächste Analyse der

Servicequalität führt zu falschen Schlüssen.

Flow – Arbeitsreihenfolge, jetzt auch vertauschungssicher!

Sogar noch zuverlässiger bleiben Realität und CMS

synchron, wenn die Daten arbeitsbegleitend in die

Dokumentation einfließen. Für die Reihenfolge gibt

es dabei zwei Optionen.

Der technische Konfigurationsvorgang kann zum

einen mit der Dokumentation beginnen, die dann

automatisch die Durchführung bewirkt – das CMS

wird hier zum Exekutivwerkzeug. Bewerkstelligen


Juli 2015

lässt sich dies entweder über direkte Schnittstellen

zu technischen Management Systemen oder über

die Anbindung einer Automationssoftware wie

ServiceNow Orchestration, BMC Bladelogic oder

HP Server Automation. Die Möglichkeiten bei der

Reihenfolge »Dokumentation-Durchführung«

reichen dabei von der automatischen Generierung

eines Eintrages im DNS-Dienst durch Dokumen-

tation von IP Adresse und Hostnamen für einen

Server bis zur kompletten Provisionierung (virtu-

eller) Server durch die Neuanlage entsprechender

CIs im CMS.

Alternativ kann die Ausführung einer technischen

Konfiguration automatisch die Dokumentation

der Änderung im CMS bewirken. Bewerkstelligen

lässt sich dies durch die Implementierung von

Schnittstellen zwischen technischen Management

Systemen und dem CMS. So können bei der Reihen-

folge »Durchführung-Dokumentation« beispiels-

weise wichtige Parameter der Konfiguration eines

Netzwerkgerätes aus Cisco Configuration Professional in das CMS übertragen werden.

Fokus – Ich sehe, was ich brauche!

Aus Anwendersicht ist ein CMS dann ideal, wenn

es das WYSIWYN-Kriterium erfüllt: »What You

See Is What You Need«. Ein einzelnes Tool kann

dieses Kriterium nicht erfüllen, da technische

Mitarbeiter andere Prozesse und andere Infor-

mationen benötigen als Serviceverantwortliche

und umgekehrt. Viele einzelne Tools dagegen –

zum Beispiel eins für Netzwerktechniker, eins für

Serverspezialisten, ein drittes für die Abbildung der

Servicebäume – können das WYSIWYN-Kriterium

zwar erfüllen, katapultieren das Configuration

Management aber 20 Jahre in die Vergangenheit,

wenn sie dabei nicht lediglich verschiedene

Sichtweisen auf ein und denselben Datenbestand

darstellen.

Grundvoraussetzung und gleichzeitig Heraus-

forderung für den Einsatz mehrerer Tools ist es, die

jeweiligen Datenbestände synchron zu halten und

die CIs in den verschiedenen Werkzeugen zuein-

ander in Beziehung zu setzen. Dabei unterscheiden

sich nur die an den jeweiligen Prozesshintergrund

angepassten Perspektiven, während ein Server

im Netzwerktool dasselbe Objekt bleibt wie der

Server im Servicebaum des IT Service Management

Tools.

Dies wiederum erhöht jedoch den Synchroni-

sationsaufwand und die Anzahl komplexer

Schnittstellen, was neue Fehlerquellen schafft.

Zahlreiche Tools nach dem Motto »viel-hilft-viel«

zur Verfügung zu stellen ist daher ebenso unprak-

tikabel wie die Beschränkung auf ein einzelnes

Tool. Die Antwort auf die Frage nach der Anzahl der

Anwenderwerkzeuge in einem CMS wird also von

gegenläufigen Interessen geleitet: Optimale

Bedarfsanpassung mit vielen Tools gegen

beherrschbare Komplexität mit wenigen Tools.

Finish – Alle Wege führen ins CMS!

Ein weiterer maßgeblicher Aspekt für das CMS-

Design besteht darin, dass im CMS Informationen

aus verschiedenen technischen Datenquellen

zusammenlaufen sollen. Damit werden zwei

Ziele verfolgt: Zum einen lassen sich technische

Detailinformationen auf diese Weise automatisch

in das CMS einpflegen, zum anderen wird durch

das Einbetten dieser Daten im CMS mit Hilfe der

folgenden Mechanismen aus den vielen Zutaten

erst ein Gericht:

• Reconciliation:

Synchronisierung von Objekten

• Normalisierung:

Vereinheitlichung von Informationen

• Verdichtung:

Gewichtung und Entfernung redundanter

Informationen

• Kategorisierung:

Einheitliche Sortierung von unterschiedlichen

Objekten

• Relationalisierung:

Herstellen von Beziehungen zwischen

Objekten

• Anreicherung:

(Manuelle) Ergänzung von Informationen


Juli 2015

Daten aus den technischen Datenquellen, die auf

diese Weise aufgewertet und »veredelt« wurden,

bieten einen dreifachen Nutzen. Zum einen

profitieren alle Mitarbeiter davon. Zum zweiten

lassen sich damit automatische Mechanismen zur

Steuerung technischer Systeme aus einem

Gesamtzusammenhang heraus implementieren.

Und schließlich, als besonders wichtiger Aspekt,

stellen sie die einzige sinnvolle Datenbasis für

IT Service Management Prozesse dar.

Erst die normierte, ganzheitliche Abbildung der

Infrastruktur im CMS ermöglicht es, fachüber-

greifend – Server, Datenbank, Applikation etc.

– Entscheidungen im Sinne optimaler Service-

leistungen zu treffen. Solange Einzelinformationen

aus den Spezialsystemen verschiedener techni-

scher Fachabteilungen abgerufen und zusammen-

gefügt werden müssen, kann bereits ein einfacher

Change an einem produktiven Serversystem nicht

mehr mit vertretbarem Aufwand geplant und

bewertet werden.

IT Prozesse

• Abnehmer von Informationen

• Anforderungsgeber

CMS Datendrehscheibe

• Reconciliation

• Normalisierung

• Verdichtung

• Kategorisierung

• Relationalisierung

• Anreicherung

Externe Datenquellen

• Datenlieferanten

• Technische Rahmenbedingung


Juli 2015

3. Für die Traumhochzeit im Rechenzentrum: Die 3-Schichten-Torte

Unsere Lösung für die Überwindung des Service

Gaps und zur Überführung der beschriebenen

Herausforderungen in den angestrebten Ideal-

zustand ist die Strukturierung des CMS in drei

Schichten für ITSM Prozesse, technische Prozesse

und technisches Management.

Datenlieferant

Datenlieferant

Applikation/UI

Applikation/UI

TechnischeCMDB

Technische Management

Systeme

Applikation/UI

Technische Prozesse

Technische Prozesse

ITSM Prozesse

CMDBFederation

Reconciliation

Federation

Reconciliation

Steuerung

ITSM Prozesse

Technische Prozesse

Technische Prozesse


Juli 2015

Mit Stil serviert und dekoriert: ITSM Prozesse

Diese Schicht unterstützt die eher serviceorien-

tierten Prozesse der IT, die im Wesentlichen von

den Abhängigkeitsrelationen zwischen den ver-

schiedenen CIs für die Bereitstellung von Services

profitieren.

Wichtige Tätigkeiten mit Rückgriff auf die ITSM

Prozess CMDB sind beispielsweise die Durchfüh-

rung von Impact Analysen im Change Management

(»Welcher Service ist von der Downtime eines

Servers betroffen?«) oder Root Cause Analysen im

Incident Management (»Wo liegt die Ursache der

Störung eines Services?«). Dokumentiert werden in

der ITSM Prozess CMDB auch die Verknüpfungen

zwischen Prozesstickets und CIs, um beispielsweise

nachzuvollziehen, bei welchen CIs eine Downtime

aufgrund von durchzuführenden Changes zu

erwarten ist oder welche Art von Servern häufig

aufgrund von Störungen ausfallen.

Des weiteren können auch ein serviceorientiertes

Event Management und Service Level Management

von den in der ITSM Prozess CMDB dokumentier-

ten Abhängigkeitsrelationen profitieren: ersteres

im Rahmen sogenannter Servicebäume für die Er-

mittlung und Darstellung der Auswirkungen techni-

scher Alarme auf Services in Echtzeit, letzteres für

die Optimierung vereinbarter IT Services und die

Einhaltung von Richtlinien.

Die in ITSM Suiten enthaltenen CMDBen wie bei-

spielsweise BMC Atrium, ServiceNow Configuration Management, IBM CCMDB oder HP UCMDB erfüllen

diese Aufgaben mit Bravour durch die enge Inte-

gration in die entsprechenden Service Management

Prozessmodule.

Edelste Zutaten und Rezeptur: Technische Prozesse

Diese Schicht unterstützt die technischen Abtei-

lungen bei Tätigkeiten mit Prozesscharakter. Dazu

gehören die Installation und Konfiguration eines

Servers im Rechenzentrum, die Einrichtung einer

Datenbank in einer Clusterumgebung oder die

Konfiguration und Dokumentation von Netzwerk-

geräten – Tätigkeiten, die gerichtet verlaufen und

verschiedene, miteinander zu koordinierende

Aktivitäten umfassen.

Aus der technischen CMDB werden, im Gegensatz

zu ITSM Prozessen, erheblich mehr technische

Detailinformationen benötigt. Für die Installation

und Konnektivität eines Servers beispielsweise

müssen Informationen zur Verfügung stehen, die

von Stromverbrauch und Bauhöhe über Netzwerk

und Netzwerkverbindungen bis zu Konfigurations-

daten für Firewalls und einzubindende Dateisysteme

reichen. Für technische Managementaktivitäten

wie Rechenzentrumsmanagement (DCIM) und

technische Problemanalyse ist die technische

CMDB ebenso die Datenquelle der Wahl. Hierzu

gehören zum Beispiel die Überprüfung verfügbarer

Kapazitäten im Rechenzentrum oder die Untersu-

chung von Kommunikationsproblemen durch Ver-

bindungs- und Netzweganalysen zwischen Geräten,

idealerweise direkt in der Oberfläche eines techni-

schen Configuration Management Tools.

Ein entscheidendes Merkmal technischer Configu-

ration Management Werkzeuge ist die Fähigkeit,

mit Fremdsystemen über Schnittstellen zu kom-

munizieren. Mit deren Hilfe lassen sich technische

Management Systeme für die Datenübernahme an

die technische CMDB anbinden und auch Steue-

rungsmechanismen für die Automatisierung imple-

mentieren. Idealerweise enthält ein solches Tool

bereits eine Anzahl praxiserprobter Schnittstellen

zu gängigen Management Systemen, bietet aber

gleichzeitig die Möglichkeit, weitere Schnittstellen

flexibel zu implementieren.

Für die genannten Aufgaben gibt es spezialisierte

Werkzeuge wie beispielsweise AixpertSoft AixBOMS

oder FNT Command, die eine CMDB mit technisch

orientierten Datenmodellen ebenso zur Verfügung

stellen wie optimierte Benutzerinterfaces für die

Verwaltung und Aufbereitung technischer Detailin-

formationen.

Perfekt abgeschmeckt: Management Prozesse

Die dritte Schicht für das technische Management

hält zwei Arten von Werkzeugen bereit. Zum

einen sind dies technische Management Systeme

zur Steuerung und Konfiguration von Hard- und

Softwaresystemen. Zum anderen sind dies automatische Discovery Systeme, die dem CMS ergänzende

Informationen zuführen.


Juli 2015

Technische Management Systeme können in zwei

Richtungen an das CMS angebunden werden:

1. Konfigurationsänderungen in der CMDB können

zur automatischen Durchführung an die techni-

schen Management Tools übermittelt werden.

So kann bei der Dokumentation eines neu instal-

lierten Servers in der technischen CMDB dort

mit einem IP Adressmanagement Modul eine im

Servicekontext sinnvolle IP Adresse vergeben

werden. Diese wird per Schnittstelle an das

Management Tool zur Steuerung der DHCP und

DNS Server übergeben, das die Konfiguration

automatisch durchführt.

2. Nach komplexen technischen Änderungen

innerhalb der darauf spezialisierten Manage-

ment Systeme können Konfigurationsände-

rungen automatisch in die technische CMDB

übernommen werden. Nach Erzeugung einer

Datenbank werden beispielsweise Namen und

Anzahl der Tablespaces sowie Größe der Daten-

bankfiles automatisch an die technische CMDB

geliefert und können dort zur Leistungsverrech-

nung für einen Service verwendet werden.

IT Provider verfügen in der Regel über mehrere

technische Management Systeme, die verschiedene

Technologiebereiche meist herstellerspezifisch

abdecken, wie beispielsweise Cisco Prime und

Infosim StableNet für den Bereich Netzwerk, Oracle Enterprise Manager oder MS SQL Server Management Studio für Datenbanken, BMC Bladelogic oder

HP Server Automation für Server Automatisierung,

NetIQ IDM für Zugriffssteuerung und Identity

Management.

Aus Automatischen Discovery Systemen sollten für

das 3-Schichten CMS nur solche Informationen

übernommen werden, die nicht durch Prozesse

gepflegt werden können; dies betrifft überwiegend

technische Detailinformationen, aber auch automa-

tisch ermittelbare Relationen. Für diese Strategie

gibt es zwei Gründe:

1. Discovery Tools sind nicht zuverlässig genug

für Service Management Prozesse. Das hängt

weniger mit der Qualität der Tools zusammen,

als mit unüberwindlichen Hürden: fehlende

Credentials, geschlossene Firewallports oder

grundsätzlich nicht erfassbare Daten wie

Standorte oder organisatorische Zuordnungen.

Anderslautende Versicherungen von Herstellern

sind marketinggetrieben und vom Versuch

motiviert, Schwächen einer integrierten Prozess

CMDB bei der Dokumentation technischer

Details zu kompensieren.

2. Bei einer vollautomatisierten Datenübernahme

verliert das Configuration Management seinen

wichtigsten Kontrollmechanismus: den Soll-

Ist-Vergleich. Hierbei werden Daten aus dem

Discovery Tool (Ist-Zustand) mit den durch

Pflegeprozesse in der technischen CMDB

erzeugten Informationen (Soll-Zustand) ver-

glichen, ein wichtiger Indikator für die Qualität

von Change und Configuration Management.

Dies funktioniert aber natürlich nur, wenn

Prozessdaten in der CMDB nicht automatisch

mit Daten aus Discovery Systemen überschrie-

ben werden.


Juli 2015

4. Der große Abschlussball: Das 3-Schichten CMS im Einsatz

Zu einem idealen CMS zusammengefügt werden

die beschriebenen drei Schichten mit ihren jewei-

ligen Werkzeugen durch zwei Mechanismen, die

beide zur Standardausstattung gängiger Configura-

tion Management Tools gehören: »Reconciliation«

und »Federation«. Sie sorgen für einen abgegliche-

nen Datenbestand und die Möglichkeit, nahtlos

zwischen den einzelnen Schichten zu wechseln.

Jedem der passende Tanzpartner: Reconciliation

Mittels »Reconciliation« werden die Datentöpfe

der einzelnen Werkzeuge aus allen drei Schichten

des CMS miteinander abgeglichen. Reconciliation

bedeutet nicht, in jeder einzelnen Datenbank alle

verfügbaren Daten zu sammeln; das könnten die

auf ihre jeweilige Schicht spezialisierten Tools gar

nicht leisten und es ist auch nicht ihre Aufgabe.

Vielmehr geht es darum, eine Identifizierung der

Datensätze in den jeweiligen Systemen auf Objekt-

ebene vorzunehmen und jedem Werkzeug genau

die Daten zuzuführen, die für die dort unterstütz-

ten Prozesse benötigt werden.

An einem einfachen Beispiel lässt sich das demons-

trieren:

• Das Netzwerk Management Tool enthält für

die Konfiguration jedes einzelnen Ports eines

bestimmten Switches detaillierte Informationen,

darunter Port-Geschwindigkeit, Duplexmodus

und Storm Control.

• In der technischen CMDB ist derselbe Switch mit

einzelnen Ports und Verbindungen zu anderen

Geräten für eine Verbindungsanalyse doku-

mentiert; die im Netzwerk Management Tool

enthaltenen Informationen zu detaillierten Port-

konfigurationen werden hierfür nicht benötigt.

• In der ITSM Prozess CMDB sind für denselben

Switch die Verbindungen zu anderen Geräten

dokumentiert, jedoch lediglich als »Impact«

Relationen, damit die Auswirkungen eines

Ausfalls ermittelt werden können; portgenaue

Informationen werden dabei nicht gebraucht.

Der Datenfluss bei der »Reconciliation« läuft

typischerweise »bottom-up« von der technischen

Schicht nach oben bis zur ITSM Prozess Schicht.

Dabei werden die Beziehungsstrukturen zwischen

den Objekten komplexer, während der technische

Detaillierungsgrad der Informationen gleichzeitig

geringer wird. Auf diese Weise ergibt sich in jeder

Schicht eine einheitliche, aber auf die jeweiligen

Bedürfnisse zugeschnittene Sicht auf die IT Infra-

struktur.

Für fliegende Partnerwechsel: Federation

»Federation« macht darüber hinaus den Wechsel

zwischen diesen Schichten möglich. Die verschie-

denen Prozesse sollen ja Hand in Hand arbeiten,

und es entsteht im Arbeitsalltag der IT Mitarbeiter

durchaus das Bedürfnis nach unterschiedlichen

Perspektiven. In solchen Fällen ist es von großem

Vorteil, per Knopfdruck die Schichtebene zu

wechseln und das zuvor betrachtete CI direkt im

dortigen Werkzeug zur Verfügung zu haben. Genau

das leistet Federation, indem für jedes Objekt

in der jeweiligen CMDB ein Zugangspunkt in

einem Werkzeug der darunter befindlichen Ebene

vermerkt wird.

Auch dies lässt sich an einfachen Beispielen

demonstrieren:

• Nach durchgeführter Verbindungsanalyse in

der technischen CMDB möchte der Netzwerk-

techniker nun doch die Konfigurationsdetails

eines bestimmten Switchports im technischen

Management Tool einsehen.

• Nach der Durchführung eines Change in der

ITSM Prozess Schicht möchte der Durchfüh-

rende die technischen Änderungen an dem mit

dem Change Request verknüpften CI direkt in

der technischen CMDB dokumentieren.

Auch diese Disziplin beherrschen mittlerweile

alle gängigen Configuration Management

Werkzeuge, und ebenso können die technischen

Management Tools per direktem Zugangspunkt

gezielt die Informationen eines bestimmten


Juli 2015

Objektes bereitstellen. Dies ermöglicht es, per

Knopfdruck ein und dasselbe Objekt in unter-

schiedlichen Werkzeugen zu bearbeiten.

Ein prächtiges Feuerwerk: Mehrwert im Rechenzentrum

Das 3-Schichten CMS ist praxiserprobt, robust

und vergleichsweise simpel. Im Gegensatz zum

vermeintlich »einfacheren« Szenario, bei dem ein

einzelnes Werkzeug – meist mehr schlecht als recht

– durch massives Customizing zum eierlegenden

Wollmilchtool umfunktioniert wurde, bleibt das

Gesamtsystem hervorragend releasestabil, da jedes

Tool ausschließlich im Rahmen seiner spezifischen

Stärken eingesetzt wird. Die ITSM Prozess CMDB

unterstützt die ITSM Prozesse, die technische

CMDB unterstützt die technischen Prozesse.

Zudem gilt, dass die meisten Tools ohnehin bereits

vorhanden sind, wenn auch nicht immer miteinan-

der verbunden.

Spätestens nach der Anpassung des Architektur-

modells an die konkreten Anforderungen stellt das

3-Schichten CMS den einfachsten gemeinsamen

Nenner zur Schließung des Service Gaps im

IT Service Management dar. Und das Schließen

des Service Gaps durch den Zusammenschluss der

Systeme kann beträchtlichen Mehrwert im Rechen-

zentrum generieren.

Eine Herausforderung ist und bleibt dabei natürlich

der konkrete Zuschnitt der Architektur des

3-Schichten-CMS auf die jeweiligen Anforderungen

des IT Providers, die etwa durch die technische

Fertigungstiefe vorgegeben sind – eine Tätigkeit,

auf die unsere Configuration Consultants durch

ihr hohes Maß an Erfahrung und den Einsatz

bewährter Methoden bestens vorbereitet sind.


Juli 2015

Unser Angebot

Gerne unterstützen wir Sie bei der IST-Aufnahme,

der Analyse und der Empfehlung von Handlungsal-

ternativen vor dem Hintergrund Ihres individuellen

Umfeldes.

Für jede unserer Leistungen bieten wir Ihnen das

gesamte Servicespektrum moderner IT-Projekte:

• Analyse, Zieldefinition, Konzeption,

Produktauswahl

• Customizing, Individualisierung,

Implemen tierung

• Prozessmigration, Inbetriebnahme,

Dokumentation

• Projektmanagement, Projektmarketing,

Reviews

• Produktschulung, Pflege, 24/7 Hotline, Support

Viele unserer Senior Berater und Beraterinnen

sind bereits mehr als zehn Jahre mit an Bord:

Geringe Mitarbeiterfluktuation, die Nutzung des

guten Ausbildungs- und Arbeitsmarktniveaus

am Wissenschaftsstandort Aachen sowie eigene

Ausbildungsinitiativen und interne Schulungen ga-

rantieren Ihnen Projektierungsteams auf höchstem

fachlichen Niveau.

Ist Ihr Interesse geweckt? Sprechen Sie uns an!

Wir freuen uns auf ein persönliches Gespräch.


Juli 2015

Die Autoren

Ralf Altmeyer

Dr. rer. nat. Ralf Altmeyer ist seit über 13 Jahren als

Projektleiter, Strategieberater und Architekt mit

dem Schwerpunkt Configuration Management für

die ComConsult Kommunikationstechnik tätig.

Neben dem hohen fachlichen und produktseitigen

Know-how schätzen Kunden seine beispielhaften

konzeptionellen und kommunikativen Fähigkeiten.

Martin Woyke

Dipl. Kfm. Martin Woyke ist einer der beiden

Geschäftsführer der ComConsult

Kommunikationstechnik GmbH.

Seit der Gründung des Unternehmens 1986

wird er als anerkannter Strategieberater auf

Geschäftsleitungsebene geschätzt.

© Copyright by:

ComConsult Kommunikationstechnik GmbH

Pascalstr. 25

52076 Aachen

Germany

Tel. +49 (0) 2408 149 01

ComConsult Kommunikationstechnik AG

Stapfenstraße 5

3098 Köniz

Switzerland

Tel. +41 (0) 3139 801 41

[email protected]

www.comconsult.de

Date post:	04-Jun-2018
Category:	Documents
Upload:	lydung
View:	219 times
Download:	1 times

»Alle für einen, einer für alle«: 3 Schichten für 1 ...€¦ · ServiceNow Orchestration, BMC...

Documents