staging.inyokaproject.org

Hallo Leute,

ich sitze gerade an einem Praxisbericht für die Uni über zentrale Softwareverteilung, habe dazu aber eine Frage, auf ITIL bezogen (siehe Überschrift):

Wo ist der Unterschied zwischen DML (Definitive Media Library) und CMDB (Configuration Management Database)?

Beide werden vom CMS (Configuration Management System) verwaltet und gepflegt, beide enthalten CIs (Configuration Items). Jetzt frage ich mich, wo der Unterschied ist, wenn beide vermeintlich gleich behandelt werden? Ist der Unterschied nur der, dass eine DML ein "echter" Standort (Tresor, Raum, etc) ist und dann logisch betrachtet wird, wohingegen die CMDB rein "virtuell" existiert?

Vielleicht findet sich hier ein Experte. Wäre schön.

Gruß

ubu-bembem schrieb:

Wo ist der Unterschied zwischen DML (Definitive Media Library) und CMDB (Configuration Management Database)?

Das sind zwei unterschiedliche Dinge. Kurz und knapp kann man das so erklären:

Die CMDB enthält sämtliche Assets (CI), also HW (Server, Clients, Network-Devices, usw.), SW-Assets, Lizenzen, usw.. Also eine Art komplettes Inventar aller IT-relvanten Komponenten, inkl. deren relevanten Konfigurationsdaten.

Die DML dagegen enthält SW die für den praktischen Einsatz freigegeben worden ist, also das Change und das Release Management erfolgreich durchlaufen haben und somit "als für den Produktivbetrieb tauglich" befunden wurden. Nur SW die in der DML landet, darf produktiv eingesetzt werden (zumindest theoretisch 😉 ).

Die DML ist also so eine Art SW-Bibliothek, in der alle freigegebenen SW's enthalten sind. Sobald eine SW (die in der DML ist, z.B. OpenOffice 3.3) auf z.B. einem Client installiert worden ist, stellt sie dann auch ein CI in der CMBD dar (vereinfacht gesagt "Auf Client xy ist OpenOffice 3.3 installiert). Je nach Aufbau der CMDB (welche meist nicht eine DB darstellt, sondern einen Verbund von mehreren DB's) können aber auch die mit der SW verbundenen CI's (z.B. Lizenzinformationen) direkt in der DML geführt werden. Somit stellt dann die DML einen Teil der CMDB dar.

Alle Klarheiteiten beseitigt? 😉

Gruss, balu

Erstmal vielen Dank für deine Antwort! ☺

Mir ist jedoch etwas noch unklar:

Balu62 schrieb: Je nach Aufbau der CMDB (welche meist nicht eine DB darstellt, sondern einen Verbund von mehreren DB's) [...]

... heißt das, dass es nach ITIL nur eine CMDB geben kann? Diese besteht dann - wie du beschrieben hast - aus mindestens einer DB? Ist es denn nicht möglich, dass das CMS neben DML und CMDB noch mehr CMDBs enthalten kann? Wenn ja, was wäre dann ein Beispiel dafür? Vielleicht: Eine CMDB für bwsp. Bereich X und eine andere für Bereich Y eines Unternhemens? Also rein organisatorisch, siehe OUs einer Domäne?

Ich hoffe du hast noch einmal Zeit für mich (:

Gruß

Es ist wie bei Highlander - es kann nur einen geben! 😎

Im Ernst: Sinn und Zweck der CMDB ist es ja, alle Informationen zu den CI's zu korrelieren. Wie ich bereits geschrieben habe, existieren meistens mehreren DB's. Beispielsweise eine Asset-DB in der die eigentlichen HW-Config-Daten stehen. Weiter gibt es z.B. ein System für das Problem-Mgmt, das Change-Mgmt, das Financial-Mgmt, Service Level-Mgmt., usw.. Das Ziel der CMDB ist es nun, alle diese Informationen - die ja letztendlich wieder mit einem CI zusammenhängen - an einem Ort zu konsolidieren. Das ist dann eben die CMDB. Wenn Du jetzt für mehrere Abteilung eigene solche DB's führst (was nebenbei bemerkt meist relativ sinnfrei sein dürfte) und die zu je einer "CMDB" zusammenführst, kommst Du schlussendlich nicht drum rum, diese Quasi-CMBD's wieder irgendwo zusammenzuführen - also landest Du wieder bei einer einzigen CMDB.

Du darfst Dir die CMDB auch nicht als klassische DB vorstellen, in der sämtliche Daten physisch vereint werden, sondern eher als Konzept welches die Vernetzung der Daten sicherstellt. Somit ist die CMDB - bzw. das Configuration Mgmt - eben auch eine sehr wichtige, absolut zentrale Grundlage um überhaupt ITSM nach ITIL aufbauen zu können. Wenn Du das Config Mgmt - und als dessen zentrales Element die CMDB - nicht im Griff hast, nützen Dir die ganzen übrigen schönen ITIL-Prozesse herzlich wenig.

Ein kleiner Tipp noch aus eigener Erfahrung: ITIL verstehen heisst vor allem auch die Zusammenhänge und die Interaktion der verschiedenen Prozesse und Elemente zu verstehen - und da lernen selbst zertifizierte Leute, die sich schon seit Jahren intensiv mit dem Thema beschäftigen, laufend wieder dazu 😉

Gruss, balu

Vielen Dank für deine sehr gute und ausführliche Antwort! Damit hast du mir vorerst ( 😛 ) alle Fragen beantwortet! Du scheinst ja ein wahrer ITIL-Profi zu sein ☺ Ich melde mich, sobald ich neue Fragen habe(n sollte)!

Gruß und nochmal: Danke!

Balu62 schrieb:

Die DML ist also so eine Art SW-Bibliothek, in der alle freigegebenen SW's enthalten sind. Sobald eine SW (die in der DML ist, z.B. OpenOffice 3.3) auf z.B. einem Client installiert worden ist, stellt sie dann auch ein CI in der CMBD dar (vereinfacht gesagt "Auf Client xy ist OpenOffice 3.3 installiert).

Eine kleine Frage dann doch noch: Du schreibst, eine SW-Installation würde in einem CI dargestellt: "Auf Client xy ist OpenOffice 3.3 installiert". Dieses steht in der CMDB. Lizeninformationen können auch in Form von CIs dargestellt werden ....

Ist die Information "OpenOffice 3.3 ist zugelassen" (welche in der DML enthalten ist) auch ein CI?

Balu62 schrieb:

Die DML ist also so eine Art SW-Bibliothek, [...]

... SW-Bibliothek, wobei jeder SW-Eintrag dann auch ein CI verkörpert, richtig?

Gruß

ubu-bembem schrieb:

Ist die Information "OpenOffice 3.3 ist zugelassen" (welche in der DML enthalten ist) auch ein CI?

Meiner Meinung nach nicht. Die SW selbst ist natürlich ein CI. Die Information "freigegeben" wäre eher ein Attribut des CI's, welches aber eigentlich sinnlos ist, da nur freigegebene SW in der DML landen darf. Das impliziert dann auch, dass eine SW in der DML eine freigegebene SW sein muss. Praktisch müsste jedoch eine Verknüpfung zum Release- und Change Management existieren, wo dann die Freigabe (bzw. der gesamte Freigabeprozess) dieser bestimmten SW ersichtlich ist.

... SW-Bibliothek, wobei jeder SW-Eintrag dann auch ein CI verkörpert, richtig?

Das wäre jetzt die Definitionsfrage von SW-Eintrag... Lass es mich so ausdrücken: Jede SW ist genauso ein CI wie auch jede Lizenz dazu.

Gruss, balu

ubu-bembem schrieb:

Vielen Dank für deine sehr gute und ausführliche Antwort! Damit hast du mir vorerst ( 😛 ) alle Fragen beantwortet!

Gerne! ☺

Du scheinst ja ein wahrer ITIL-Profi zu sein ☺

Nun ich hatte das Glück, dass ich eine grosse IT-Service-Organisation über drei Jahre hinweg an eine ISO 20000-Zertifizierung (der formelle Standard für ITSM nach ITIL) heran- und schlussendlich auch durch die Zertifizierung führen durfte. ITIL an sich ist eigentlich eine eher trockene Geschichte, ITIL jedoch in der Praxis zu implementieren.ein höchst spannende! 😎

Gruss, balu

Okay, alles klaro, vielen Dank nochmal. Kannst Du mir vielleicht erklären, inwieweit das SKMS mit der DML zu tun hat? Die DML ist ja praktisch Bestandteil der CMDB, welche wiederum vom CMS "gemanaged" wird. Die Rahmenbedingungen unter der die Verwaltung seitens des CMS stattfindet gibt doch das SKMS vor, oder? Ferner könnte man dann sagen, die Vorgaben des SKMS beeinflussen die Eigenschaften der DML? Hmm...

Gruß

ubu-bembem schrieb:

Okay, alles klaro, vielen Dank nochmal. Kannst Du mir vielleicht erklären, inwieweit das SKMS mit der DML zu tun hat? Die DML ist ja praktisch Bestandteil der CMDB, welche wiederum vom CMS "gemanaged" wird.

Die DML kann Bestandteil der CMDB sein, ist jedoch auf jeden Fall Bestandteil des CMS. Mit dem SKMS hat die DML nur indirekt zu tun, nämlich einfach dadurch, dass sie zum CMS gehört.

Die Rahmenbedingungen unter der die Verwaltung seitens des CMS stattfindet gibt doch das SKMS vor, oder?

Ich würde das SKMS eher als Erweiterung zum CMS sehen.

Ferner könnte man dann sagen, die Vorgaben des SKMS beeinflussen die Eigenschaften der DML? Hmm...

Das würde ich jetzt als schon sehr gesucht ansehen 😉 Das SKMS macht ja eigentlich nicht die Vorgaben des CMS, sondern ist eben eine Erweiterung - siehe oben. Wie bereits früher geschrieben ist die DML ja lediglich die Bibliothek der freigegeben SW, die ev. auch noch Lizenz-Informationen enthalten kann. Die DML ist also eigentlich nur ein kleines Rädchen innerhalb des CMS. Die Ausprägung / der Aufbau des SKMS kann natürlich in der Praxis Auswirkungen auf die Architektur des CMS haben - muss es aber nicht. In der Praxis (zumindest in den Communities in denen ich mich bewege) ist SKMS (noch) kein grosses Thema. SKMS ist erst mit ITIL V3 dazu gekommen. Die meisten Unternehmen die ITSM nach ITIL einführen streben auch eine ISO 20000-Zertifizierung an. Diese wiedrum wurde in den meisten Fällen noch auf Basis von ITIL V2 - na ja, sagen wir ITIL V2,5 😉 (oder "V2 enhanced") erlangt. Der Nutzen von V3 ist vielen Unternehmen auch noch nicht wirklich transparent und somit führen gewisse V3-Komponenten in der Praxis auch noch ein etwas stiefmütterliches Dasein 😉

Gruss, balu

Mal wieder: Vielen Dank für Deine Mühen!

Ich denke ich habe schlicht und ergreifend das SKMS noch nicht richtig verstanden. Das SKMS verwaltet doch Informationen, die ein IT-Dienstleister für seine "Produkte"/ Erzeugnisse benötigt, richtig? Waären dann hierfür die Information "Anzahl Mitarbeiter" ein geeignetes Beispiel? Hast Du vielleicht ein gutes Beispiel?

Ansonsten habe ich nur noch 2 Fragen zu CIs ... Ich glaube dann kann man dieses Thread als Dokumentation verwenden ☺ Natürlich möchte ich nicht nerven etc. 😈

Ich habe zu Configuration Items ein gutes Video gesehen: http://www.youtube.com/watch?v=BCPpjCvUf7Y Dort ist bei ca. 3:20 die Rede von Physical und Logical CIs. Physical CIs werden quasi als Bestandteile von Logical CIs angesehen. Meine Frage: ist ein CI nicht immer beides? Ein Monitor mag Bestandteil einer Workstation sein, aber gleichzeitig ist eine LED auch ein Bestandteil eines Monitors (okay Beispiel vllt nicht so gut). Oder kommt es dabei einfach nur auf den Grad der Betrachtung an? Wenn man beispielsweise eine Workstation betrachtet?

Und meine zweite Frage zu CIs (und dann gibt es nicht mehr, mit dem ich Dich und das Forum belästigen werde *promise*): Wie genau kann ich mir ein Configuration Record vorstellen? Informationen zu einzelnen CIs werden in einem Configuration Record gespeichert. Also besteht ein CI quasi bildhaft/ schematisch aus Configuration Records? Quasi: Jede Information eines CIs ist ein Record? Ist der Begriff "Record" hierbei mit dem des "Arrays" zu vergleichen?

Ich hoffe, du hilfst mir noch ein mal (:

Gruß

ubu-bembem schrieb:

Mal wieder: Vielen Dank für Deine Mühen!

Ich denke ich habe schlicht und ergreifend das SKMS noch nicht richtig verstanden. Das SKMS verwaltet doch Informationen, die ein IT-Dienstleister für seine "Produkte"/ Erzeugnisse benötigt, richtig? Waären dann hierfür die Information "Anzahl Mitarbeiter" ein geeignetes Beispiel? Hast Du vielleicht ein gutes Beispiel?

Nehmen wir mal an, wir möchten eine neue SW-Lösung einsetzen. Da muss ich auch wissen, welche Skills meine IT-Mitarbeiter (Skills der IT-Staff) haben. Ev. können die das nicht selbst umsetzen, sondern wir benötige Partner dazu. Was kann ich überhaupt meinen Users (Skills der User) zumuten und wie ist der Schulungsbedarf? Wie kann ich die User schulen (Trainingsmöglichkeiten, z.B. WBT oder Präsenz-Trainings)? Alle diese Informationen (welche Skill-Level bei Staff und Users, welche Partner, usw.) das sind alles Informationen, die ich zur Einführung benötige, die ich aber nirgendwo aus meiner CMDB bzw. dem CMS herauslesen kann - es sind ja keine CI's. Genau für solche Informationen ist das SKMS da.

Ansonsten habe ich nur noch 2 Fragen zu CIs ... Ich glaube dann kann man dieses Thread als Dokumentation verwenden ☺

How to explain ITIL in three easy lessons 😀

Physical CIs werden quasi als Bestandteile von Logical CIs angesehen. Meine Frage: ist ein CI nicht immer beides? Ein Monitor mag Bestandteil einer Workstation sein, aber gleichzeitig ist eine LED auch ein Bestandteil eines Monitors (okay Beispiel vllt nicht so gut). Oder kommt es dabei einfach nur auf den Grad der Betrachtung an? Wenn man beispielsweise eine Workstation > betrachtet?

Nimm das Beispiel SAN: Du hast z.B. Harddisks, Shelfs, SAN-Switches. Das sind alles CI's. Diese sind aber Bestandteil des logischen CI "SAN". Oder ein Workplace: Compi, Monitor, Maus, Tastatur, usw. sind alles CI's, bilden aber zusammen das logische CI "Workplace".

Und meine zweite Frage zu CIs (und dann gibt es nicht mehr, mit dem ich Dich und das Forum belästigen werde *promise*): Wie genau kann ich mir ein >Configuration Record vorstellen? Informationen zu einzelnen CIs werden in einem Configuration Record gespeichert. Also besteht ein CI quasi bildhaft/ >schematisch aus Configuration Records? Quasi: Jede Information eines CIs ist ein Record? Ist der Begriff "Record" hierbei mit dem des "Arrays" zu vergleichen?

Du hast einen Monitor auf deinem Tisch stehen. Das ist ein CI. Der Eintrag zu Deinem Monitor (Marke, Typ, technische Daten, Beschaffungsdatum, usw.) in der CMDB ist ein Configuration Record. Ganz simpel;-) Den Begriff Array ist mir in dem Zusammenhang nicht geläufig, ich würde ihn aber als der "logische Configuration Record" interpretieren, also eine Zusammenfassung mehrere C-Records zu einer Array - siehe oben das Beispiel mit dem SAN.

Gruss, balu