(Ab) Auf Wolke Sieben

7 Tipps zur Auslagerung von On-Premise-Apps
Kommentare

Klingt es nicht verführerisch, in der Wartung ungeliebte, aber für das Tagesgeschäft unerlässliche Standardapplikationen einfach aus der eigenen Anwendungslandschaft auszulagern und dabei trotzdem die administrative Kontrolle zu behalten? Wie so oft kommt aber auch hier ein fingerhebendes Aber. Im folgenden Beitrag sollen daher Einblicke in einige Gedankengänge zur Ablösung von lokal betriebenen Microsoft-Standardapplikationen anhand eines fiktiven Unternehmens aus dem Dienstleistungssektor gewährt werden.

Der anfängliche Fokus liegt auf der lokal betriebenen Anwendungslandschaft eines fiktiven Dienstleistungsunternehmens. Hier sind typische Komponenten wiederzufinden: Der Exchange Server als E-Mail-System, SharePoint zur Realisierung eines Intranets inklusive Diskussionsboard und Bildersammlung, Lync als Instant Messenger sowie ein Dynamics-CRM-System zur Kunden- und Auftragsverwaltung. Da verschiedene Komponenten einen SQL Server für ihren Betrieb benötigen, ist ein zentrales Datenbankcluster im Unternehmen vorhanden. Es stellt Instanzen für Exchange, SharePoint und CRM bereit. Gleichzeitig ist es Anlaufpunkt für die Realisierung der Back-up-Strategie des Unternehmens. Das Active Directory ist standardmäßig aufgebaut, beherbergt also Benutzer-, Computer- und Gruppenobjekte.

Abb. 1: Sieben Tipps zur Auslagerung

Abb. 1: Sieben Tipps zur Auslagerung

Welche Anwendungen?

Theoretisch wäre es kein Problem, die gesamte Software des Unternehmens als Cloud-Variante zu verwenden. Dieser Ansatz ist aber aus verschiedenen Gründen unwahrscheinlich. Sowohl organisatorische, personelle, finanzielle und/oder rechtliche als auch unter Umständen branchenspezifische Aspekte müssen hier beachtet werden. Die Aspekte müssen für jede Anwendung beleuchtet und hinterfragt werden: Welche Anwendung qualifiziert oder disqualifiziert sich durch Erfüllung welcher Kriterien für eine Migrationsprüfung? Die Gründe können vielfältig sein. Es seien hier einige Beispiele genannt:

Qualifikation

  • Stark schwankende Parameter sorgen für ständig erforderliche Anpassungen in der physikalischen Leistungsfähigkeit eines Systems.
  • Ein System wird von fachlich in anderen Richtungen spezialisierten Mitarbeitern „nebenbei“ betrieben. Probleme erfordern eine spezielle Einarbeitung sowie den Einkauf von externem Know-how und verursachen häufig (ähnliche) Beeinträchtigungen im operativen Tagesgeschäft.
  • Die Präsenzzeiten in den Büros des Unternehmens sind unterdurchschnittlich. Darüber hinaus ist nicht sichergestellt, dass sich stets ein systembetreuender Mitarbeiter im Haus befindet.
  • Die Mitarbeiter sind im Außendienst tätig, benötigen aber auch unterwegs die bestmögliche Anbindung an die Infrastruktur des Unternehmens.

Disqualifikation

  • Ein System beherbergt Daten, deren Auslagerung (durch Speicherung an einem anderen Ort und theoretischen Zugriff durch Dritte) gegen geltendes Recht verstoßen und/oder das Vertrauen der Kunden missbrauchen würde.

In unserem Beispielunternehmen liegt der Migrationsfokus auf der Kommunikation und der ortsunabhängigen Arbeit. Dies hat verschiedene Gründe. Wesentlich ist, dass die Exchange- und Lync-Infrastruktur administrative und physikalische Kapazitäten binden (nicht nur bei sich selbst, sondern auch z. B. bei Back-up-System und Firewall). Daher versprechen sich die Verantwortlichen von der Auslagerung eine Reduktion der

  • Wartungsaufwände
  • Ausfallzeiten
  • Betriebskosten für physikalische Infrastruktur (Betrieb, Back-up, Firewall für Veröffentlichung nach außen)
  • Problematiken bezüglich einer sich rasch verändernden Anzahl von Mitarbeitern

sowie mehr Sicherheit durch einen weiteren physikalischen Speicherort für die Kommunikations-Back-ups.

Zwischenergebnis: Das Unternehmen möchte Office 365, Skype for Business (als Ersatz für Lync) und Exchange Online nutzen.

Welche Daten?

Für ihren Betrieb benötigen die genannten Systeme bestimmte Daten, vornehmlich aus dem lokalen Active Directory. Doch viel interessanter in diesem Zusammenhang ist die Frage, welche Daten nicht benötigt werden bzw. nicht verwendet werden dürfen. Zwei Beispiele sollen den Hintergrund dieses Aspekts verdeutlichen:

  • Für Notfälle ist die private Telefonnummer einzelner Mitarbeiter im Active Directory hinterlegt, z. B., um sie bei technischen Problemen außerhalb der Geschäftszeiten erreichen zu können.
  • Private Adressen stehen ebenfalls im Active Directory. Sie sind Grundlage für eine Auflistung im Intranet, auf welche nur die Personalverantwortlichen Zugriff haben.

Exchange und Skype for Business erfordern neben einigen Systemattributen aus dem Active Directory Benutzername, Vor- und Nachname sowie zur komfortableren Nutzung dienstliche Kontaktdaten wie Telefon, E-Mail und Geschäftsadresse.

Zwischenergebnis: Die für den Betrieb notwendigen, in die Cloud zu migrierenden Daten(mengen) sind benannt. Ebenfalls ist festgelegt, welche Daten keinesfalls in die Cloud gelangen sollen.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Welcher Umfang?

Machen betriebliche Gründe eine Beibehaltung der bisherigen Infrastruktur oder Teile davon erforderlich, muss hinterfragt werden, ob die prognostizierten Vorteile der Cloud-Anwendungen noch genauso hoch bewertet werden können.

Bezogen auf unser Beispielunternehmen wäre SharePoint ein solcher Fall: Die Speicherung und Anzeige streng vertraulicher Mitarbeiterdaten soll weiterhin im lokal betriebenen SharePoint geschehen. Exchange und Lync sind hingegen von diesem Aspekt nicht betroffen.

Zwischenergebnis: Nach der erfolgten Migration können verschiedene lokale Server (Lync, Exchange) abgeschaltet werden. Die prognostizierten Vorteile können voll ausgeschöpft werden.

Welcher Aufwand?

Zwar wird es immer einfacher, im Unternehmensumfeld Anwendungen aus der Cloud einzusetzen, dennoch muss der zu erwartende Aufwand eindeutig beziffert werden. Oft ist dabei nicht nur die Inbetriebnahme der eigentlichen Anwendung von Bedeutung, sondern die Erfüllung von Rahmenbedingungen, die Aufwände verursacht. Dies spielt vor allem dann eine Rolle, wenn ein Unternehmen in der Vergangenheit von herstellerseitig vorgegebenen Standards abgewichen ist. Dies gilt es im Vorfeld zu untersuchen.

In unserem Beispiel muss außerdem dafür gesorgt werden, dass die Benutzerkonten des Unternehmens auch auf der Seite von Office 365 verwendet werden können. Dies impliziert eine angepasste (auf die notwendigen Daten beschränkte) Synchronisierung und damit ein neues Teilprojekt als Voraussetzung für die eigentliche Migration.

Zwischenergebnis: Die Voraussetzungen sind erörtert, der momentane Erfüllungsgrad geprüft. Die noch ausstehenden Aufwände zur Erfüllung sind bekannt.

Welche Administration?

Auch in der Cloud läuft nichts ohne kompetente Administratoren. Typische Szenarien sind die Einbindung neuer Mitarbeiter, Anpassungen am Lizenzmodell sowie Bereinigungen und Reaktionen auf äußere Umgebungsänderungen. In Frage kommen hier nicht nur selbstständige Vorbereitungen in Form von Literaturstudien, Testumgebungen und Testfällen, sondern z. B. auch Schulungen.

Zwischenergebnis: Die Administratoren kennen die anstehenden Änderungen und sind imstande, mit der neuen Umgebung zu arbeiten.

Welche Migrationsart?

Die eigentliche Migration sollte schnell sein, den Tagesbetrieb nicht beeinträchtigen, keine Mitarbeiter binden und keine Fehler erzeugen. Dieses Wunschdenken kann zumindest annähernd wahr werden, wenn die Vorgänge im Vorfeld sorgfältig geplant und in Teilschritte überführt werden. In den seltensten Fällen muss (und kann) alles auf einen Schlag passieren. Oft bieten die zu verwendenden Technologien in diesem Zusammenhang interessante Möglichkeiten.

Im Beispielunternehmen werden folgende Teilprojekte von teils unterschiedlichen Personen durchgeführt:

  • Buchung eines Office-365-Abonnements und Auswahl eines zum Unternehmen passenden Lizenzmodells.
  • Einrichtung einer Synchronisierung zwischen dem lokalen und dem Azure Active Directory. Dies beinhaltet auch die Begrenzung auf die relevante Datenmenge.
  • Konzeption von Vorgehensweisen und ggf. Richtlinien (welche Dokumente dürfen Mitarbeiter beispielsweise in der Cloud speichern und welche nicht).
  • Es kann nicht schaden, die Mitarbeiter bei dieser Gelegenheit zum Aufräumen ihrer Postfächer zu animieren.
  • Inbetriebnahme einer hybriden Exchange-Umgebung: Die Postfächer der Anwender können separat migriert werden. Für die Zeitspanne der Migration bleibt der lokale Exchange Server in Betrieb. Hauptbeweggrund für dieses Vorgehen ist die große zu übertragende Datenmenge sowie eine lückenlose Verfügbarkeit des Diensts.

Zwischenergebnis: Das genaue Vorgehen bei der eigentlichen Migration ist definiert. Teilaufgaben und Zuständigkeiten sind eindeutig geklärt.

Fazit

Die Inbetriebnahme von Cloud-Anwendungen kann erfrischend unkompliziert sein. Unabdingbar ist stets, sich mit den Voraussetzungen, relevanten Daten und Anwendungen sowie mit einer sinnvollen und realistischen Vorgehensplanung zu beschäftigen. Außerdem sollte sich jeder darüber im Klaren sein, dass dem Ausschöpfen von prognostizierten Einsparpotenzialen nicht unerhebliche Aufwände und Umstrukturierungen gegenüberstehen. Inwiefern diese den Nutzen der aus der Cloud bezogenen Dienste beeinträchtigen, muss sorgfältig abgewogen werden.

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist der Windows Developer ferner im Abonnement oder als Einzelheft erhältlich.

Aufmacherbild: Men and women go up heaven to access the cloud  via Shutterstock.com / Urheberrecht: Jesus Sanz

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -