Was versteht man unter “Enterprise Architecture” und wie grenzt sich dieser Begriff von
den Begriffen “Business Architecture” und “IT Enterprise Architecture” ab?
Enterprise Architecture bezeichnet das Zusammenspiel von Elementen der IT (IT Enterprise Architecture) mit der geschäftlichen Tätigkeit im Unternehmen (Busi- ness Architecture). Business Architecture beschreibt dabei alle Elemente, die zur Implementierung und Ausführung der Business Strategie benötigt werden. Die IT Enterprise Architecture umfasst unter Anderem die Application Infrastructure, die Data & Information Architecture, und die Infrastructure Arcitecture.
Für das zielgerichtete Management der Enterprise Architecture ist es notwendig, eine
Geschäftsstrategie (“business strategy”) zu haben. Nennen und beschreiben Sie die drei
generischen Geschäftsstrategien nach Porter und nennen Sie für jede Strategie beispielhaft
ein bekanntes Unternehmen, das diese Strategie verfolgt.
Cost Leadership Den Markt durch niedrige Produktionskosten und somit niedrigem
Verkaufspreis den Markt erobern. Die führt meist zu standardisierten Produkten, einem schmalen Produktionsprogramm, und hohen Stückzahlen um Skalen- effekte auszunutzen. Beispiele für ein solches Geschäftsmodell sind Amazon, Zara, und McDonalds.
Differentiation Differenzierung durch das Abheben von der Konkurrenz durch einzi-
gartige Features/bessere Qualität. Bringt einen höheren Preis und höhere En- twicklungskosten mit sich. Um zu verhindern, dass die Konkurrenz die Features imitiert und mit dem Markt “davonläuft” sind gutes Marketing und schnelle interne Prozesse notwendig. Beispiele wären Apple, Bose, und Tesla.
Focus Strategy Diese Strategie basiert auf der starken Fokussierung auf eine Mark-
tnische und Kernkompetenzen in einer bestimmten Region/Kundensegment. Innerhalb der Gewählten Marktnische muss zusätzlich eine Cost Leadership oder Differentiation Strategie gefahren werden. Beispiele wären Rolex und Fer- rari.
Um aus der Geschäftsstrategie eine IT-Strategie ableiten zu können, muss die Unter-
nehmensleitung diverse Aspekte aus der Geschäftsstrategie für die IT spezifizieren. Nen-
nen und beschreiben Sie 3 Aspekte der Geschäftsstrategie, die für die Erarbeitung einer
IT-Strategie relevant sind, und erläutern Sie mögliche Auswirkungen dieser Aspekte auf
die IT.
Geographie Basierend darauf ob das Unternehmen nur lokal oder auch global agieren will muss die Infrastructure Architecture unterschiedlich aufgebaut sein.
Future Je nachdem wie weit das Management im Voraus plant kann auch die IT
vorausplanen. Es können frühzeitig Kapazitäten auf-/abgebaut werden die Architektur muss weniger flexibel bezüglich kurzfristiger Änderungen sein.
Existing IT Offensichtlich starker Einfluss auf die IT ob das Management entscheidet
keine Änderungen an der Bisherigen Arbeitsweise zu machen oder komplett neue Geschäftsprozesse einzuführen.
Eine IT-Strategie sollte 5 Kernbereiche bzw. Säulen umfassen. Nennen und beschreiben
Sie 3 dieser Säulen bzw. Kernbereiche einer IT-Strategie.
IT-Infrastructure Umfasst die verwendete Hardware, Software, und Betriebssysteme.
Service IT-Services, die mit verfügbarer IT-Infrastruktur internen und externen Nutzern bereit gestellt werden soll.
Application Portfolio Bewertung und Erweiterung des Applikationsportfolios über
einen vordefinierten Zeitraum.
Integration Grad der Integration zwischen Geschäftsprozessen und Unterstützungsap-
plikationen.
Sourcing Quelle aller Personen, die Arbeiten aufführen, um IT Strategie auszuführen.
Üblicherweise liefern die Geschäftsstrategie und die Geschäftsarchitektur den Input für
die Gestaltung der IT-Strategie und der IT Enterprise Architecture. Beschreiben Sie anhand
von 2 konkreten Beispielen, dass umgekehrt auch die IT maßgeblichen Einfluss auf die
Gestaltung der Geschäftsstrategie und die Geschäftsarchitektur haben kann.
Das Tempo mit dem die IT ein Projekt umsetzen kann
Die Kosten für IT Projekte
Was versteht man unter der “Business-IT-Gap”?
Die Business-IT-Gap bezeichnet den Grad zu welchem IT Initiativen von den Business Requirements abweichen. Diese Lücke sollte im Laufe der Zeit eliminiert werden. Wenn die Lücke eliminiert wurde ist Business-IT-Alignment erreicht.
Zur Reduzierung der “Business-IT-Gap” sollte ein sog. “Business-IT-Alignment” auf mehreren
Ebenen bzw. zu mehreren Aspekten stattfinden. Beschreiben Sie zwei dieser Ebenen bzw.
Aspekte des “Business-IT-Alignment”.
Cognitive Alignment Vereinheitlichung des Denkens/Verständnisses in Business
und IT durch gemeinsame Werte, Visionen, und Sprache.
Strategic Alignment Ausrichtung von Geschäfts- und IT-Strategie.
Architectural Alignment Ausrichtung von IT-Systemen auf Geschäftsprozesse und Strukturen im der Organisation.
Temporal Alignment Die Geschwindigkeit mit der die IT sich an Anforderungen des
Geschäfts anpassen kann.
In der Praxis haben sich unterschiedliche Ziele im Enterprise Architecture Management
(EAM) herauskristallisiert. Nennen und beschreiben Sie 3 Ziele des EAM.
Costs Beschreibt den Versuch die Kosten in der IT zu verringern. Kann durch Prior-
itäten in der Anwendungsentwicklung, Optimisierung der IT Infrastruktur, und die IT Enterprise Architecture allgemein erreicht werden.
Quality Die Qualität der Leistung. Wird anhand der Zufriedenheit der internen Nutzer der IT gemessen.
Compliance Die Einhaltung von Rechten, internen Regularien, und Verträgen mit
Dritten.
Ein wichtiges Werkzeug für das Business-IT-Alignment sind sog. Business Capabilities.
Was versteht man unter einer Business Capability? Was beschreibt eine Business Capabil-
ity nicht?
Beschreibt welche Arbeit in einem bestimmten Bereich ausgeführt wird (z.B. Mitar- beiter bezahlen). Eine Business Capability ist nicht der tatsächliche Prozess.
Business Capabilities eines Unternehmens werden typischerweise grafisch in einer Capa-
bility Map angeordnet. Für die Erstellung einer solchen Capability Map bzw. allgemein
für die Erstellung von Business Capabilities gibt es einige Richtlinien. Erläutern Sie, was
man unter der Richtlinie “MECE” versteht und nennen und beschreiben Sie 3 weitere
Richtlinien Ihrer Wahl.
MECE steht für “mutually exclusive and collectively exhaustive”. Das bedeutet, dass sich Capabilities nicht überschneiden dürfen und alle Business Funktionen des Un- ternehmens von Capabilities abgedeckt sein müssen.
Stability Business Capabilities sollten langfristig stabil sein.
Independence Capabilities sollten unabhängig von Strukturen, Prozessen, Personen,
und Technologien sein.
Hierarchy Capabilities sollten Hierarchisch strukturiert werden.
Was ist ein “Application Portfolio” und warum sollte man ein solches Portfolio erstellen?
Das Application Portfolio ist ein Inventar und Beschreibung der vom Unternehmen verwendeten Applikationen.
Inventory Das Wissen über im Unternehmen verwendete Applikationen Hilft bei der
Vermeidung von Redundanzen, versteckten Kosten, . . . .
Compliance Eine Organisation muss ihre IT Applikationen kennen und die damit
einhergehenden Risiken managen.
Alignment Business-IT-Alignment sicherstellen, indem das Application Portfolio an
die Business Strategie angepasst wird.
Jede betriebliche Anwendung in einem Application Portfolio kann auf mehreren Architek-
turebenen beschrieben werden. Nennen Sie diese 4 Architekturebenen und erläutern Sie
für jede Ebene kurz, welche Eigenschaften bzw. Aspekte einer betrieblichen Anwendung
hier dokumentiert werden sollten.
Business Architecture Spezifiziert die Business Funktionen, Prozesse, und Struk-
turen der Organisation die zur Einhaltung der Business Strategy erforderlich sind.
Application Architecture Beschreibt die IT-Applikationen, die Plattformen auf denen
sie aufbauen, und die Designprinzipien die bei der Entwicklung angewendet wurden.
Data Architecture Beschreibt die der logischen und physischen Daten einer Organi- sation.
Infrastructure Architecture Beschreibt die physischen un virtuellen Assets die zur
Ausführung der Applikation und zum Datenaustausch zwischen Applikationen benötigt wird.
Für die Auswertung des Anwendungsportfolios gibt es viele unterschiedliche Visual-
isierungen und KPIs. In der Praxis hat sich insb. eine Matrix-Darstellung etabliert, in der
die betrieblichen Anwendungen mit einer beliebigen anderen Dimension gekreuzt wer-
den. Beschreiben Sie ein Beispiel für eine Anwendungsmatrix und erläutern Sie, welche
Erkenntnisse man aus einer solchen Darstellung gewinnen kann.
Anwendungen können beispielsweise gegen die Business Capabilities aufgetragen werden. Dadurch lassen sich sehr einfach Redundanzen (Zwei Applikationen mit der selben Funktionalität) und white spots (Capabilities für die kein IT-Support bereit steht) ablesen.
In der Management-Ebene sind Portfolio-Diagramme beliebt, die sich an der sog. “Boston
Square Matrix” orientieren. Welche 4 Kategorien von Anwendungen werden in der Bosten
Square Matrix unterschieden und welche Eigenschaften haben die jeweiligen Anwen-
dungskategorien?
High Potential Applications R&D Applikationen und innovative Produkte. Fokus auf Prototypen.
Strategic Applications Applikationen für neue Produkte und Geschäftsprozesse. Fokus auf Geschwindigkeit und Features.
Support Applications Benötigte Applikationen ohne strategische Relevanz. Fokus auf Effizienz und potentielle Kandidaten für Outsourcing.
Key Operational Applications Applikationen, die wichtige Geschäftsprozesse unter-
stützen. Hohe Qualität und Zuverlässigkeit sicherstellen.
Im Rahmen des Application Portfolio Development werden sowohl ein To-Be-Application
Portfolio (“target application landscape”) als auch eine oder mehrere “intermediate appli-
cation landscapes” definiert. Was ist der Unterschied zwischen den beiden Begriffen und
warum benötigt man “intermediate application landscapes”?
Das To-Be-Application Portfolio beschreibt eine Ziel Anwendungslandschaft, die so viele Anforderungen wie möglich erfüllt. Es ist aber auf Grund von Abhängigkeiten zwischen aktuellen Anwendungen, dem ungestörten Weiterlaufen des Geschäfts- betriebes während der Migration, und einem Mangel an Ressourcen nicht möglich direkt vom As-Is- zum To-Be-Portfolio zu Wechseln. Daher werden eine Reihe von
Intermediate Application Portfolios definiert und Portfolio als ganzes Stück für Stück migriert.
Änderungen an der Anwendungslandschaft zur Realisierung der “target application land-
scape” werden typischerweise in mehreren Projekten umgesetzt. Diese Projekte laufen
oft parallel und sind stark voneinander abhängig. Daher müssen sie durch eine überge-
ordnete Instanz, das sog. “Program Management” koordiniert werden. Beschreiben Sie 3
Abhängigkeiten, die zwischen den IT-Projekten existieren können.
Scheduling Projekt 1 kann eine Applikation erst einführen, wenn Projekt 2 ein Inter-
face implementiert hat.
Risk Wenn Projekt 1 schief geht, muss auch Projekt 2 nicht fortgeführt werden.
Resources Ein Experte wird von mehreren Projekten gleichzeitig gebraucht.
Scope Wenn ein Projekt nicht alle Features implementieren kann muss ein anderes
das übernehmen.
Budget Budget nicht ausreichend um alle Projekte im selben Jahr durchzuführen.
Idealerweise leisten (IT-) Projekte immer einen Beitrag sowohl zur Erhöhung der “IT Effi-
ciency” als auch dem “Business Value”. Was versteht man unter diesen beiden Begriffen?
IT Efficiency Bei einer hohen IT Efficiency kann die IT mehr Business Requirements mit dem selben Aufwand implementieren.
Business Value Die IT unterstützt Business Requirements und hilft die Geschäft-
sergebnisse zu verbessern.
Untersuchungen haben ergeben, dass sich bei Projekten im Zeitablauf hinsichtlich der
beiden o.g. Aspekte ein Muster etabliert: Wie verhalten sich “IT efficiency” und “Business
Value” typischerweise über einen längeren Zeitraum und was sind die Gründe dafür?
Über einen langen Zeitraum sinkt üblicherweise die IT Efficiency und steigt der Busi- ness Value. Dies liegt an Gründen wie einem zunehmend starken Coupling zwischen Komponenten, auftretenden Redundanzen, temporären Lösungen, fehlender Doku- mentation, . . . .
Zur Aufrechterhaltung einer gesunden IT-Unternehmensarchitektur hat sich die so genan-
nte “Managed Evolution” als Managementprinzip etabliert. Welches Ziel verfolgt die
“Managed Evolution” und welche Einflussfaktoren müssen in der Managed Evolution
hinsichtlich IT Efficiency und Business Value beobachtet und gesteuert werden?
Im Rahmen einer Managed Evolution muss sichergestellt werden, dass die Summe aller Projekte sowohl den Business Value als auch die IT Efficiency steigert. Daher müssen den Business Requirements und der Strategy immer die EA Principles und Standards gegenüber gestellt werden. Hinsichtlich des Business Value müssen doe Einnahmen durch Verbesserung von Produkten/Services und die IT-Kosten gesteuert werden. Bei der IT Efficiency sind die Time to Market und Entwicklungskosten relevant.
Als Hilfsmittel für die kontrollierte Weiterentwicklung der Unternehmensarchitektur
haben sich Architekturprinzipien (“EA principles”) bewährt. Nennen und beschrieben Sie
3 Architekturprinzipien bzw. Richtlinien.
Cost averse vs. risk averse Die Frage danach, in wieweit die IT basierend auf niedri- gen Kosten oder einem niedrigen Risiko gemanaged werden soll.
Innovator role vs. service provider role Die Frage ob die IT die Business Strategie beeinflusst oder lediglich einen Service für die Organisation liefert.
Customization vs. Standardization Wird die Technik ans Business oder das Business and die Technik angepasst?
Flexibility vs. manageability Ist die Architektur flexibel oder einfach zu managen?
Nennen und beschreiben Sie drei mögliche Organisationsformen der IT innerhalb von
Unternehmen
IT als eigener Funktionsbereich Die IT ist gleichberechtigt mit anderen Abteilungen. Birgt Gefahr der Überbetonung der IT.
IT als Unterabteilung eines Funktionsbereiches IT ist einem anderen Funktionsbe- reich untergeordnet. Birgt Gefahr der Bevorzugung der Hauptabteilung.
IT als Stabstelle der Unternehmensführung IT unabhängig von anderen Bereichen
und diesen übergeordnet. Leichte Abteilungsübergreifende Planung der IT.
Was versteht man unter “Schatten IT”?
Bezeichnet IT-Systeme die “illegal” und unsichtbar in bestimmten Funktionsbere- ichen vorkommen.
Was bedeutet es, wenn man von IT als “Cost Center” spricht? Was ist der Unterschied von
der IT als “Cost Center” zur IT als “Profit Center”?
Wird die IT als Cost-Center gesehen besteht keine Motivation für wirtschaftliches Handeln. Wenn das Budget aufgebraucht ist dann “ist es eben so”. Es besteht kein Anreiz für gute Qualität, nur die Einhaltung des Budgets ist relevant. Um Unterschied dazu hat eine als Profit Center betrachtete IT Zugang zum Markt und muss ihre Leistungen an diesem anbieten. Der Markt kann dabei Unternehmensintern oder -extern sein. Die IT muss Gewinn machen bzw. zumindest ihre Ausgaben decken um Erfolgreich zu sein.
Warum ist es oft problematisch, die IT-Abteilung als “Cost Center” zu führen?
Es besteht kein Anreiz für gute Qualität, nur die Einhaltung des Budgets ist relevant. Weiter besteht keine Vergleichbarkeit zu Leistungen des externen Marktes aufgrund von intransparenter Leistungsverrechnung.
Was bedeutet es, wenn man in der IT-Abteilung von den “Kunden” spricht?
Kunden sind die internen und externen Nutzer der IT Systeme.
Jede IT-Abteilung kann unterschiedlich strukturiert sein und mehrere Unterabteilungen
bzw. Funktionsbereiche haben. Nennen und beschreiben Sie kurz 3 Unterabteilungen
bzw. Funktionsbereiche der IT.
Service Desk Anlaufstelle für IT-Probleme von Anwendern. Löst Hardware- und Anwendungsprobleme.
IT Sicherheit Schützt die IT und die verwalteten vertraulichen Informationen. Stellt Integrität sicher und gewährleistet die Verfügbarkeit von Systemen.
IT Innovation Beobachtet aktuelle Trends und analysiert und bewertet die Nutzung
neuer Technologien für das Unternehmen.
Was bedeutet “Utility” und “Warranty” im Zusammenhang mit IT Services?
Utility Frage nach der Nützlichkeit des Services für den Kunden. Service hat Utility wenn er die Anforderungen des Kunden erfüllt (“fit for purpose”).
Warranty Frage nach der Nutzbarkeit (Performanz, Zuverlässigkeit, . . . ) des Services.
Es besteht kein Wert für den Kunden, wenn der Service nicht nutzbar ist (“fit for use”).
Nennen Sie beispielhaft 3 IT Services und geben Sie für jeden Service ein Beispiel, bei
dem “Utility” und “Warranty” nicht erfüllt sind.
Z.B. hat ein Druckservice an der HTWG, bei dem Druckaufträge nur per USB-Kabel vom
Laptop der Studierenden an den Drucker übertragen werden können, nur geringe “Utility”
— der Service ist nicht “nützlich”, sondern viel zu umständlich zu benutzen. Wenn bei den
Druckern außerdem ständig die Toner leer sind, ist die Qualität des Druckservices und
somit die “Warranty” nicht gegeben.
• Ein Prüfungsverwaltungsportal auf dem man keine Prüfungen an-/abmelden
kann genügt nicht den Anforderungen. Somit ist keine Utility gegeben.
• Ein Notenverwaltungsportal auf dem man mehrere Minuten auf die Anzeige von
Noten warten muss ist nicht gut zu bedienen. Somit ist keine Warranty gegeben.
• Ein Videochat Programm das nicht auf allen Betriebssystemen läuft hat keine
Utility
Was versteht man unter ITIL und wofür kann man es einsetzen?
ITIL steht für die IT Infrastructure Library. Es ist ein Framework für IT Service Man- agement, welches best practices and good services definiert. Es umfasst Wissen und Erfahrungen von Personen, die erfolgreich im IT Service Management gearbeitet haben.
Was versteht man unter einem Type I, Type II und Type III Service Provider?
Type I Internal Service Provider (Stellt IT-Services ausschließlich für den eigenen Geschäftsbereich bereit)
Type II Shared Service Unit (Eine Abteilung in der Firma, die IT-Services für den Rest der Firma bereitstellt)
Type III External Service Provider (Eine externe Firma, die IT-Services bereitstellt)
Um die Verantwortlichkeiten bei IT Prozessen festzulegen, erstellt man häufig eine RACI-
Matrix. Was versteht man darunter und was bedeuten die einzelnen Buchstaben in
“RACI”?
Eine RACI-Matrix legt fest wer für welche Aktivität in einem Prozess verantwortlich ist. RACI steht für Responsible, Accountable, Consulted, and Informed.
Nennen Sie beispielhaft einige Aspekte, die ein IT-Service Provider im Rahmen der Ist-
Analyse im Strategy Management untersuchen sollte. (“Wo stehen wir heute?”)
Existing Services Was bieten wir an? Wie funktioniert es? Wo haben wir Probleme?
Profitability Wie sind unsere Servicekosten? Welche Services sind kosteneffizient
und welche nicht?
People Haben wir genügend Leute? Kennen alle ihre Aufgaben?
Daily business Wie effizient ist der Alltag unserer Services? Werden alle gut über-
wacht? Wie ist die Fehlerbehandlung?
Welche Fragen sollte sich ein IT-Service Provider bei der Ausarbeitung einer neuen Service-
Strategie stellen und beantworten? (“Wo wollen wir hin?”)
-Was ist die Vision für uns als IT-Abteilung?
• Was werden unsere Werte/Grundsätze nach denen wir handeln wollen?
• Welche Services wollen wir anbieten?
• Welche Kunden wollen wir bedienen?
• Was sind kritische Erfolgsfaktoren?
• Welche zukünftige Marktposition wollen wir haben?
In welche Kategorien ist das Service Portfolio unterteilt? Welche dieser Kategorien enthält
diejenigen Services, die Kunden bestellen können?
Das Service Portfolio ist unterteilt in den Service Katalog, aus dem Kunden bestellen können, den abgelaufenen Services, und der Service Pipeline.
Wie wird der ROI eines IT-Service berechnet? Beschreiben Sie die Berechnung anhand
eines Beispiels.
Was sind OPEX- und CAPEX-Kosten? Nennen Sie Beispiele für diese Kosten anhand eines
IT-Services Ihrer Wahl.
CAPEX-Kosten (Capital Expenditure) sind einmalige Investments. OPEX-Kosten (Op- erational Expenditure) sind beim Betrieb eines Services periodisch anfallende Kosten. Bei einem Druckservice fällt folglich das Anschaffen der Drucker unter die CAPEX- Kosten, die Patronen und das Papier unter die OPEX-Kosten.
Nennen und beschreiben Sie drei Möglichkeiten, wie ein IT-Service beim Kunden ab-
gerechnet werden kann.
Notional Charging (intern) Der Nutzer zahlt nicht für den Service, erhält jedoch eine Rechnung die die theoretischen Kosten beinhaltet.
Market Price (extern) Abrechnung zum auf dem Markt üblichen Preis. Fixed Price (extern) Abrechnung zu einem festen Preis.
Was ist Demand Management und warum ist es für den Service Provider so wichtig,
Demand Management zu betreiben?
Das Demand Management bildet die Basis für das Capability Management. Man Versucht die Charakteristika der Nutzung zu verstehen (z.B. Timing Patterns, also wann der Service wie viel genutzt wird). Der Service kann dann an den Demand angepasst werden.
Was versteht man unter dem IT Service Portfolio und in welche 3 Bereiche wird das
Portfolio unterteilt?
Listet alle Services gemeinsam mit ihrem aktuellen und historischen Status. Aufgeteilt in die Retired Services, den Service Catalogue, und die Service Pipeline.
Was ist der Unterschied zwischen Customer Facing Services und Supporting Services?
Customer Facing Services sind solche, auf die der Kunde direkt Zugriff hat. Sie werden im Business Service Catalogue gelistet. Supporting Service sind solche die im Hinter- grund stehen und für den Betrieb der Customer Facing Services benötigt werden. Sie sind im Technical Service Catalogue gelistet.
Um Utility und Warranty eines Service bereits während der Service-Design-Phase zu
garantieren, werden im Rahmen des Service Level Management einige wichtige Doku-
mente erstellt. Welche Dokumente verbergen sich hinter den folgenden Abkürzungen
und wozu werden die Dokumente jeweils erstellt?
• SLR
• SDP
• SLA
• OLA
• UC
SLR (Service Level Requirements) Liste von Wünschen/Anforderungen des Kunden um Geschäftsfähigkeit nachzugegen.
SDP (Service Design Packages) Wird für jeden IT-Service erstellt. Der Service Provi- der beschreibt darin die geplante technische Umsetzung.
SLA (Service Level Agreement) Vertrag zwischen Service Provider und Customer der alle Verpflichtungen und Einzelheiten zum Service regelt.
OLA (Operational Level Agreement) Abteilungsinterne Verträge zwischen Manage-
ment des Providers und Teams, die regeln welches Team für was zuständig ist.
UC (Underpinning Contract) Vertrag zwischen Service Provider und Zulieferer.
Nennen und beschreiben Sie exemplarisch 5 Aspekte, die in einem SLA-Dokument
definiert werden sollten.
Service name Der Name des Services.
Description of service Eine Beschreibung des Services.
Service times Die Zeiten zu denen der Service bereit gestellt wird.
Required support Der Level des Supports der bereitgestellt wird (z.B. on-site oder remote)
Availability targets Wie viel Prozent der zeit die Availability gewährleistet werden
soll.
Beim so genannten Capacity Management geht es darum, die zur Erfüllung der SLA
notwendigen Kapazitäten sowohl des Services selbst als auch der am Service beteiligten
einzelnen IT-Komponenten bereitzustellen. Betrachten Sie exemplarisch den Service
“Web Site Hosting” (d.h. das Bereitstellen einer Webseite im Internet) und die dazu
notwendigen Komponenten ( Web Server mit Prozessor(en), Arbeitsspeicher und Fest-
platte, Anbindung des Servers an das Internet, evtl. Software-Lizenzen, Load Balancer,
usw.): Worauf sollte bei diesem Service im Rahmen des Capacity Managements geachtet
werden?
• Stromverbrauch
• Platzverbrauch
• Hardware- und Lizenzkosten
• Anzahl der Nutzer/Transaktionen/Seitenaufrufe
• Genutzte Ressourcen
• Konfigurationen
• Business plan
Was versteht man unter Availability Management und wie können Availability Manage-
ment und Capacity Management zusammenhängen?
Im Rahmen des Availability Managements werden pro- und reaktiv Maßnahmen getroffen um die Availability des Services zu gewährleisten. Zu wenig Capacity re- duziert die Availability.
Im Availability Management hört man immer wieder die folgenden wichtigen Abkürzun-
gen: “MTTR”, “MTBF” und “MTBSI”. Wofür stehen jeweils die Abkürzungen und was ist
die Bedeutung der dahinter stehenden Kennzahlen?
MTTR (Mean time to repair) Die durchschnittliche Reparaturdauer nach einem Ser- viceausfall.
MTBF (Mean time between failures) Die durchschnittliche Zeit zwischen Service- ausfällen (“uptime”).
MTBSI (Mean time between service interruptions) Gibt die durchschnittliche Zeit
zwischen Incidents an. Kombination aus MTTR und MTBF.
In der IT-Praxis ist häufig von der so genannten “Table of Nines” die Rede. Was versteht
man darunter?
Gibt die Availability eines Services der 24/7 läuft über ein Jahr für 90%, 99%, 99.9%, 99.99%, . . . Uptime an.
Was versteht man unter Service Continuity Management und worin unterscheidet es sich
vom Availability Management?
Das Service Continuity beschäftigt sich damit nach einer Katastrophe möglichst schnell minimale Services wieder hochzufahren und für eine schnelle Recovery zu sorgen. Das Availability Management beschäftigt sich also mit der day-to-day Service Availability, das Server Continuity Management mit der Availability nach Katastro- phen.
Nennen und beschreiben Sie 3 Strategien, wie im Katastrophenfall ein IT-Service möglichst
schnell wiederhergestellt werden kann.
Reductive Measures Reduzieren den Impact von Incidents, z.B. durch regelmäßige Backups.
Corrective Measures Reparieren den Schaden durch einen Incident, z.B. durch das Einspielen von Backups.
Repressive Measures Unterdrücken security incidents, z.B. durch das Blockieren von
IP-Adressen.
Was versteht man unter einem “Emergency Change” und inwiefern weicht der Change
Management-Prozess für Emergency Changes vom Prozess für Normal Changes ab?
Geben Sie ein Beispiel für einen “Emergency Change”
Eine Änderung auf die schnell reagiert und die schnell implementiert werden muss. Es besteht meist keine Zeit für genaues Testen und Analyse der Änderung. Ein Beispiel wäre ein zero-day-exploit, der von Hackern ausgenutzt wird.
Was versteht man unter einem “Standard Change” und wie werden Standard Changes in
der Regel behandelt? Geben Sie ein Beispiel für einen “Standard Change”.
Ein Standard Change ist eine im Voraus genehmigte Änderung mit geringem Risiko. Sie folgt einem dokumentierten und geregelten Prozess.
Was versteht man im Change Management unter einem “RFC” und was ist ein “CAB”?
RFC (Request for Change) Eine formelle Anfrage für die Implementierung einer Än- derung. Muss für jede nicht standard Änderung erstellt werden.
CAB (Change Advisory Board) Prüfen und priorisieren die Änderungen aus den RFC.
Mitglieder stammen üblicherweise aus allen Abteilungen der IT Organisation.
Was ist die Hauptaufgabe des “Service Asset & Configuration Management” und was
versteht man in diesem Kontext unter einem “CI”? Nennen Sie einige Beispiele für CIs.
Katalogisiert die verwendeten IT Elemente und wie diese mit den Services im Zusam- menhang stehen. Für jedes Element wird als (Configuration Item) betrachtet, beispiel- sweise Server, Betriebssysteme, Mitarbeiter, Backup Services, . . . .
Was versteht man unter einer CMDB und wofür wird diese eingesetzt? Was ist eine DML,
wofür wird diese eingesetzt, und was ist der Unterschied zwischen einer DML und der
CMDB?
CMDB (Configuration Management Database) Ist Teil des Configuration Manage-
ment Systems. Beinhaltet Informationen über alle CIs, aber nicht die tatsäch- lichen CIs. Beinhaltet Grundkonfigurationen.
DML (Definitive Media Library) Beinhaltete autorisierte Versionen aller Medien-CIs
wie gekaufte und eigene Software. Beinhaltet weiterhin authorisierte Kopien der Dokumentation.
Welche Aufgabe hat das “Release & Deployment Management” und warum ist es sinnvoll,
Changes im Rahmen von Releases auszurollen?
Beschäftigt sich mit der Implementierung, dem Testen, und dem Deployment von genehmigten Änderungen. Releases sind sinnvoll, da die Downtime der Services minimiert werden kann.
Beschreiben Sie jeweils kurz, welche Aktivitäten in den folgenden Phasen des “Release & Deployment Management” ausgeführt werden:
• Release Planning
• Release Build & Test
• Release Deployment
• Early Life Support
• Release Closure
Release Planning Erstellen eines Release-and-Deployment Plans. Prüfen, ob der
geplante Release die Anforderungen on Kunden und aus Service Design Packages realisiert.
Release Build & Test Entwicklung und/oder Einkauf und Anpassung von Release
Components sowie Erstellen von Release Dokumentation. Build & Testen aller Komponenten in isolierten Umgebungen.
Release Deployment Erstellung eines detaillierten Rollout-Plans. Deployment aller
Release-Einheiten in die Produktions-Umgebung. Informationen und Doku- mentationen über den Release in Umlauf bringen. Verifizieren, dass alle Services online sind und gemäß ihrer Spezifikationen genutzt werden.
Early Life Support Intensiver Support für neue Services und Nutzer für einen vor- definierten Zeitraum.
Release Closure Durchführen eines post implementation reviews mit den Stakehold-
ern und potentielles Einleiten korrektiver Maßnahmen. Übergang der Support- Verantwortlichkeit an das Service-Operations Team. Formaler Abschluss des Releases.
Im Zusammenhang mit Service Transition ist oft von “Environments” die Rede. Was
ist darunter zu verstehen? Nennen Sie 3 Environments, die typischerweise im Service
Transition bzw. grundsätzlich bei Entwicklungsprojekten im IT-Bereich zu finden sind.
Environments sind voneinander unabhängige Umgebungen. Üblicherweise gibt es zumindest eine Entwicklungsumgebung, eine Testumgebung und eine Produktion- sumgebung, wobei Entwicklungs- und Testumgebung weitestgehend die Produktion- sumgebung widerspiegeln sollten.
Was versteht man unter einem Event im Kontext von ITIL?
Ein Ereignis, das signifikant für das Management der IT-Infrastruktur ist.
Nennen Sie drei Typen von Events und geben Sie für jeden Typ jeweils ein Beispiel-Event
an. Welche Aufgabe übernimmt in diesem Zusammenhang das “Event Filtering”?
Informationen Nutzer hat sich angemeldet. Warnungen Speicherauslastung hoch. Ausnahmen Max Auslastung überschritten. Event Filtering entscheidet, ob das Event weiterverfolgt oder ignoriert werden sollte.
Welche Beziehungen existieren zwischen dem Event Management und dem Change-,
Incident- und dem Problem Management?
Incident Management beschäftigt sich mit der schnellen Behebung von Problemen. Das Problem Management sucht nach der darunter liegenden Ursache. Beide erstellen RFCs und damit das Change Management um ihre Problemlösungen einzubringen.
Was versteht man unter einem Incident und was ist der Unterschied zwischen einem
Incident und einem Problem?
Ein Incident ist eine ungeplante Unterbrechung oder Reduktion in Qualität eines IT-Services. Ein Problem entsteht durch mehrere zusammenhängende Incidents.
Was bedeutet es, wenn man Incidents nach “Urgency” und “Impact” priorisiert? Warum
ist die Priorisierung nach Impact unter Umständen nicht ausreichend?
Impact bezeichnet üblicherweise die Anzahl der betroffenen Nutzer. Urgency die Frage danach wie schnell der Incident behoben werden muss. Ein Incident mit geringem Impact aber hoher Urgency könnte beispielsweise die Nutzerdaten einiger weniger Nutzer öffentlich machen. Muss offensichtlich trotz geringem Impact schnell behoben werden.
Was versteht man im Incident Management unter “Functional Escalation”? Welche Stufen
gibt es typischerweise in der “Functional Escalation” und welche Personen bzw. Organisa-
tionen übernehmen typischerweise die entsprechenden Stufen?
Eskalation nicht entlang der Hierarchie sondern horizontal zu spezialisierteren Perso- nen. In der IT üblicherweise vom 1st bis zum 3rd level support.
Last changed2 years ago
