»alle für einen, einer für alle«: 3 schichten für 1 ...€¦ · servicenow orchestration, bmc...
TRANSCRIPT
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.
Ein effektives und effizientes Configuration Management
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.
Ein effektives und effizientes Configuration Management
ü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!
3 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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.
4 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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.
5 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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.
6 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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
7 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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
8 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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
9 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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
10 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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.
11 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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.
12 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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
13 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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.
14 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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.
15 |»Alle für einen, einer für alle«: 3 Schichten für 1 Management!
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
www.comconsult.de