BA-Thesis: Weitere Vorgehensmodelle für ILM-Modelle gesucht

[Darth Sidious]

Hallo liebe Community,

bin mir etwas unsicher ob die Frage hier richtig aufgehoben ist, aber ich Suche etwas Hilfe bei der Themenfindung bzw. bei der Erweiterung des Umfangs für meine Bachelor-Thesis.

Hintergrund:

Ich studiere derzeit IT-Management und habe viel Spaß dabei IT-Landschaften zu gestalten in Projekten/Prozessen und den operativen Betrieb. Nun bin ich am Ende des Studiums und muss nun noch die Bachelor-Thesis bearbeiten. Meine Schwerpunkt möchte ich auf die Analyse von Vorgehensmodellen beschränken mit einer Handlungsempfehlung für mein Unternehmen. Im Fokus stehen dabei das Thema Infrastructure Lifecycle Management bzw. Application Lifecycle Management in komplexen Mulitproviderorganisationen (Plump gesagt "Wie halte ich meine gesamte IT up to date"). Ich möchte mich dem Thema widmen, da ich bisher wenig Literatur und Dokumente dazu gefunden habe. Als auch, dass ich sehe dass in Unternehmen viel veraltete Hardware/Software rumsteht die veraltet ist (Sicherheitsrisiko/Ausfallrisiken). Desktop PC's/Client Hardware/Software steht dabei nicht direkt im Fokus, da ich mich eher auf Server- & Applikationslandschaften fokussieren möchte. Mit dem Thema erhoffe ich mir damit eine Anspruchsvolle Thesis. Interessanterweise begegnen die Probleme eines schlechten ILM's/ALM's mich immer wieder, z.B. wenn alle wieder hektisch aufschreiben alá wir müssen jetzt die Oracle Version von 11* auf 12* wechseln weil Oracle den Support beendet. Und bei einem Unternehmen mit mehreren tausend Oracle-Instanzen macht dies durchaus sehr viel Aufwand an Zeit/Kosten & Ressourcen, wenn dies schlecht ge-managed wird.

Das Problem:

Ich möchte bei der Analyse gerne drei Methoden/Vorgehensmodelle Analysieren und Bewerten. Hier fehlt mir leider derzeit ein weiters Vorgehensmodell. Derzeit sehe ich die folgende zwei Vorgehensmodelle:

• Traditionelle IT mit eigenem Rechenzentrum im Unternehmen und eigene IT (die mehrere Sub-IT-Provider hat):
  In diesem Fall muss sich die IT selber um regelmäßige Updates/Wartungen und Refresh-Aktivitäten kümmern, ggf. mit Unterstützung von zentralen Abteilungen die den Prozess steuern.
• Evergreen / Software as a Service Ansatz: Ein Application Lifecycle/Infrastructure Lifecycle Mgmt. wäre auch hier von Nöten, da vieles was als SaaS läuft ja regelmäßig mit Updates versorgt werden und auch Schnittstellen zu anderen Providern oder interne IT besteht (z.B. ERP-Schnittstellen/HR Schnittstellen / zu anderen externen Applikation etc..). Hier ist ja die Herausforderung von regelmäßigen Anpassungen die sich auch, je nach Umfang, auf Funktionsvielfalt der Applikation als auch Schnittstellen und ggf. Spezialanpassungen auf das Unternehmen auswirken. Regelmäßiges lesen und Bewerten der Releasenotes wäre von nöten inkl. ggf. Maßnahmen ergreifen um dann die Schnittstellen und Anpassungen am laufen zu halten.(mit Office 365 kommen nun ja auch regelmäßige Änderungen in die Applikation)

Hier würde ich nun gerne noch ein drittes Modell mit aufführen, allerdings fällt mir nicht mehr wirklich ein weiteres ein, da es entweder zu dem ersteren Ansatz zuordnen bar ist oder zu dem letzteren. Ich könnte mir höchstens noch vorstellen den Evergreen Ansatz zu unterteilen noch auf PaaS oder IaaS, wobei das dann wiederum nur eine Vermischung der beiden Modelle wäre bzw. eine Differenzierung auf verschiedenen Service-Layern. Überlegt hatte ich auch schon eventuell in Richtung Prozess-Leitfäden zu gehen wie ITIL, allerdings habe ich zu diesem speziellen Thema zu wenig Literatur gefunden, als das ich es sinnvoll für eine Thesis verwenden könnte. (ITIL bietet hier recht wenig wenn es um konkrete Vorgehensmodelle geht wie komplexe Multiprovideroganisationen mit Server-Austausch und Releasewechsel, so zumindes meine Einschätzung nach etwas Recherche)

Ich wäre natürlich auch gerne mal daran interessiert, wie es bei anderen Unternehmen so gehandhabt wird, damit die gesamte Hard- & Softwarelandschaft aktuell bleibt.

Dann hoffe ich mal auf eine Anregende Diskussion
Danke vorab und viele Grüße
Darth Sidious

[cortez]

Ich würde behaupten du kannst es nicht mehr klar trennen, denn auch Saas verändert sich.

Die Trennung zieht sich in erster Linie beim Administrationsaufwand. 100% bei selbst aufgesetzt und gehosteten Systemen und nahe zu 0% wenn die Software in der Cloud liegt, wo nur verwaltet wird.

 

[Darth Sidious]

Die zugrundeliegenden Prozesse sehen Grundlegend anders aus. Wenn ich als Unternehmen alles selber mache/betreibe, so muss ich vielleicht ein mal im Jahr ein komplexen Releasewechsel betreiben und alle z.B. alle 5 Jahre die Hardwareplattformen wechseln um aktuell zu bleiben. Dafür ist dies dann jedes mal umfangreicher mit großen Testabläufen, neue Infrastruktur ordern, aufbauen, konfigurieren, Jobs übernehmen / Daten übernehmen und einen Switch-Over organisieren von alt auf neu mit entsprechenden längeren Laufzeiten und Vorbereitungsphasen.

Wenn ich eine Software aber aus der Cloud oder als SaaS beziehe, so kann es sein, dass monatlich Updates und neue Features ausgerollt werden. Dann muss man sich zwar nicht mehr um große Hardware-Wechsel kümmern, aber dennoch muss die Integration der Applikation in die Unternehmensstrukturen gewährleistet werden. Dies würde sich dann hier äußern indem regelmäßig die Releasenotes intensiv geprüft werden müssten auf Änderungen. Und wenn Änderungen stattfinden müssen eventuelle Spezialanpassungen und Schnittstellen vorab geprüft werden und ggf. Vorkehrungen dafür getroffen werden. In dem Fall müssen die Prozesse wesentlich schneller und agiler sein und ggf. auch stärker zentralisiert/dezentralisiert werden um hier Schritt halten zu können.

Beides wird dann entsprechend Komplexer, wenn mehrere Dienstleister mitspielen in Multiproviderorganisationen die z.B. verschiedene Dienstleister für Telefonie-/Netzwerk oder Rechenzentren haben.