in Blog, iDNA, Noch mehr, Produkte, Trainings

Lesezeit: 11 Minuten

So halten Sie Ihr Projekt von Anfang bis Ende kosteneffizient

Weg #3 von 7 neue Wege zur Überwindung Ihrer Herausforderungen bei der Domino Anwendungsmigration

Starten Sie mit dem wahren Umfang Ihres Projekts

In den früheren Teilen dieser Serie haben wir darüber gesprochen, wie Sie den Projektumfang auf das Wichtigste reduzieren können und wie Sie mithilfe eines umfassenden Überblicks über Ihre Codebasis effizienter sein, und bessere Entscheidungen für Ihr Projekt treffen können.

In Teil 3 wollen wir eine der großen Hürden nehmen, die die meisten von uns aus persönlicher und arbeitsbezogener Erfahrung sehr gut kennen: „Einen guten Ausgangspunkt zu finden“.

Es spielt keine Rolle, ob Ihr Notes/Domino-Projekt Ihre Infrastruktur modernisiert, in die Cloud migriert oder die Plattform vollständig verlässt. Die Konsolidierung Ihrer bestehenden Infrastruktur ist ein entscheidender erster Schritt für ein erfolgreiches Projekt. Das Finden und Entfernen der Altlasten in Ihrer Umgebung wird den gesamten Projektaufwand erheblich reduzieren und Ihnen dadurch Kosten sparen.

Die Kernfragen ihres Projekts

Die richtigen Fragen zu stellen, war bereits ein Schlüsselfaktor für die Reduzierung des Projektumfangs im ersten Teil dieser Serie. Werfen wir noch einmal einen Blick auf einige dieser Fragen und konzentrieren uns diesmal darauf, wie wir die Antworten nutzen können, um Konsolidierungspotenziale zu identifizieren.

1. Wie ist die Struktur und Größe Ihrer IT-Landschaft?

Sie müssen ein echtes Verständnis für das Ausmaß des Unternehmens haben. Dafür benötigen Sie KPIs, um Konsolidierungspotenziale zu bewerten und den Erfolg zu messen:

Benutzer

  • Wie viele Benutzer sind registriert und wie viele aktiv?
  • Wann waren die Benutzer zuletzt aktiv?
  • Mit wie vielen Anwendungen arbeiten Ihre Benutzer wirklich?

Server

  • Wie viele Server sind aktiv?
  • Wie viele sind Anwendungsserver?
  • Wie viele Datenbanken werden auf einem Server verwendet?
  • Wie viele Benutzer sind auf einem Server aktiv?

Anwendungen

  • Wie viele Anwendungen gibt es und wie viele werden im Vergleich dazu verwendet?
  • Wie viele DBs können von Ihrem Projekt ausgeschlossen werden?
  • Wie viele Datenbanken basieren auf einer Standardvorlage?
  • Wie viele Replikate jeder Datenbank sind vorhanden?
  • Wie viele Benutzer sind pro Datenbank aktiv?

2. Wie viele Datenbanken werden überhaupt nicht verwendet?

Dies ist eine der am häufigsten gestellten Fragen, die wir hören. Es ist ein offensichtlicher Ausgangspunkt für die Konsolidierung.

Der erste Instinkt besteht oft darin, einfach alle nicht verwendeten Datenbankinstanzen zu entfernen und einen schnellen Sieg zu feiern. Das kann in manchen Situationen sinnvoll sein, wenn man nur die Anzahl der Server reduzieren will, zum Beispiel. Es ist allerdings sehr unzuverlässig, um zu beurteilen, welche Anwendungen tatsächlich nicht mehr in Betrieb sind.

Interessanter ist es herauszufinden, für wie viele Anwendungen keine Datenbankinstanz verwendet wird. Diese Gruppe von Datenbankinstanzen, die dieselbe Replika-ID verwenden, nennen wir „Replikatgruppe“. Nur wenn die gesamte Replikatgruppe nicht verwendet wird, und Aktivität auf keinem Server auftritt, kann eine Anwendung wirklich als nicht verwendet betrachtet werden.

Der Zeitraum, in dem die Aktivitäten beobachtet werden, spielt eine wichtige Rolle bei der Demissionierung. Nicht jede Datenbank wird täglich verwendet. Möglicherweise verfügen Sie über Datenbanken mit saisonaler Nutzung, die nur einmal im Jahr, Quartal oder Monat verwendet werden. Um diese Variation zu erfassen, empfiehlt panagenda einen Mindestbeobachtungszeitraum von drei Monaten. Natürlich gilt: je länger der Beobachtungszeitraum, desto besser werden Sie in der Lage sein, eine akkurate Aussage zu treffen.

Nachdem wir die Altlasten identifiziert haben, machen wir den ersten Schritt zur Reinigung ihrer Umgebung und suchen nach weiteren Möglichkeiten in etwas anspruchsvolleren Bereichen.

3. Wo können Kosten gesenkt werden?

Eine Konsolidierung ist eine Gelegenheit, die Kosten für nicht verwendete Lizenzen zu ermitteln und zu eliminieren. Die meisten Unternehmen führen inaktive Benutzer und nicht ausgelastete Server in ihren Büchern. Mit diesen Informationen können Sie mit sehr wenig Aufwand viel Geld sparen.

Das Auffinden und Entfernen inaktiver DBs aus Ihrer Umgebung führt zu einer geringeren Serverauslastung. Die Konsolidierung mehrerer nicht ausgelasteter Server reduziert Lizenz-, Betriebs- und Verwaltungskosten.

Die Konsolidierung ist auch eine Gelegenheit, das Design Ihres Domino-Netzwerks zu überprüfen. Beispielsweise sollten Umgebungen, die vor 15 Jahren unter Berücksichtigung von Bandbreitenüberlegungen entworfen wurden, neu bewertet werden. Die moderne Infrastruktur hat möglicherweise bereits wichtige Redundanzen oder Teile des Serverdezentralisierungskonzepts obsolet gemacht.

Viele Unternehmen entscheiden sich für die Erstellung von Hybridumgebungen. Selbst wenn Domino eine strategische Anwendungsplattform bleibt, können bestimmte generische Dienste (z. B. E-Mail, Teamräume oder Dateibibliotheken) im Laufe der Zeit von ihr entkoppelt werden. In einem solchen Migrationsszenario ist auch die Benutzeraktivität betroffen. Zusätzliche Lizenzeinsparungspotenziale können durch das Verständnis des Datenbankentwurfs vorhergesagt werden.

Auch wenn Sie derzeit nicht an einem bestimmten Projekt beteiligt sind, schafft das schnelle Tempo des Wandels in dynamischen Arbeitsumgebungen ständig Möglichkeiten, die gesamten IT-Ausgaben durch kontinuierliche Aktivitätsüberprüfungen zu reduzieren.

Finden Sie die Quick-Wins in Ihren Standardvorlagenbasierten Anwendungen

Das Konzept der Designvererbung wird ein wichtiges Thema während Ihrer Projektreise sein.  Der zweite Teil dieser Serie  stellte uns das allgemeine Thema und seine Auswirkungen auf das Wachstum von Notes/Domino-Umgebungen vor. Design im Allgemeinen ist bei Migrations- und Modernisierungsprojekten von großer Bedeutung. Seine Bedeutung kann bereits in der Konsolidierungsphase beginnen.

Das Identifizieren von Datenbanken, die den Entwurf von Standardvorlagen erben, ist aus verschiedenen Gründen wichtig. Aus organisatorischer Sicht ist es vergleichsweise einfach, den Zweck zu verstehen, dem sie dienen, auch ohne den Geschäftsprozess zu kennen, an dem sie beteiligt sind. Beispielsweise wird eine Dokumentbibliothek für den Austausch von Dateien, die Archivierung von Dokumenten oder ähnlichem verwendet. Egal, ob sie in den Abteilungen Beschaffung, Controlling oder Fertigung eingesetzt werden. Dieses Maß an Einblick in benutzerdefinierte Anwendungen zu erhalten, kann eine ziemliche Herausforderung darstellen, wenn sich diese Anwendungen im Laufe der Jahre weiterentwickelt haben. Dies gilt insbesondere dann, wenn Sie nicht nur ein oder zwei, sondern auf hunderte oder tausende Anwendungen überblicken müssen.

Aus technischer Sicht ist es immens wertvoll zu wissen, welche technischen Funktionen solche Standarddatenbanken bieten. Es gibt Ihnen eine Perspektive, ob es möglich ist, sie über das Web zu verwenden oder sie auf mobilen Geräten verfügbar zu machen. Zumal HCL viel in die Modernisierung klassischer Vorlagen investiert, könnte das ein großer Gewinn in ein Modernisierungsprojekt sein. Dies ist auch bei einer Migration wichtig, da es für Standardvorlagen meist auch Standardmigrationspfade von Drittanbietern zu anderen Plattformen gibt. Sie können fast aus dem Umfang der manuellen Migrationsarbeit ausgeschlossen werden, was wiederum verschiedene KPIs wie „Benutzer aktiv“ oder „DBs auf dem Server verwendet“ beeinflusst. Unabhängig vom Pfad ist die Arbeit mit standardvorlagenbasierten Anwendungen viel kostengünstiger als die Transformation von benutzerdefinierten Anwendungen.

So setzen Sie die Quick-Wins ein

Kombinieren wir diese Themen und wenden sie auf Ihr Konsolidierungsprojekt an, um zusammenzufassen, wie Sie am besten von den Ergebnissen profitieren können. Wir haben sogar eine kleine Checkliste erstellt, die Sie Schritt für Schritt durch die wichtigsten Punkte führt:

Aufgabe: Identifizieren nicht verwendeter Anwendungen

  • Auswirkung: Reduzierung der Serverauslastung vorbereiten
  • Auswirkung: Reduzierung des Projektumfangs

Aufgabe: Identifizieren von Anwendungen basierend auf Standardvorlagen

  • Auswirkungen: Minimierung des Migrations-/Modernisierungsaufwands
  • Auswirkung: Entdecken Sie das Potenzial zur Reduzierung der Nutzungslizenzkosten

Aufgabe: Identifizieren inaktiver Benutzer

  • Auswirkung: Entdecken Sie Einsparungspotential bei Benutzerlizenzen
  • Auswirkung: Reduzierung der Serverauslastung vorbereiten

Aufgabe: Identifizieren nicht ausgelasteter Server

  • Auswirkung: Entdecken Sie Einsparungspotential bei Serverlizenzkosten

Aufgabe: Überprüfen des Domino-Netzwerkentwurfs

  • Auswirkung: Entdecken Sie das Potenzial zur Reduzierung der Serverlizenzkosten

Als nächstes in unserer Serie

Nach dieser ersten Konsolidierungsphase, wenn alles vorbereitet und gekürzt ist, die Quick Wins erfasst und das Lizenzkosteneinsparungspotenzial klar ist, gehen wir über zu den Aufgaben, die Zeit- und Ressourcenintensiver sind. Hier wird sich der Unterschied zwischen Modernisierungs- und Migrationsprojekten noch verstärken. Es wird dann auch Zeit, die Berechnungen hinter Ihrem Business Case zu überprüfen. Wenn Sie mehr wissen möchten, wird dieses Thema im letzten Blogbeitrag und Webinar dieser Serie behandelt.

Unabhängig davon, was Ihr Projekt ist, gibt es ein paar strategische Informationen, die Sie immer benötigen. Wir werden zwei der wichtigsten Themen in unseren kommenden Blog-Beiträgen und Webinaren behandeln:

Seeking application owners? Find its stakeholder first!

Die Fähigkeit, Stakeholder zu identifizieren, ist von entscheidender Bedeutung, wenn es darum geht, über die Zukunft einer Anwendung zu entscheiden. Sie benötigen die Abteilungen oder Personen, die die Anwendung benutzen, um ihre Rolle im Geschäftsprozess zu verstehen. Sie müssen diese jedoch erst finden, um zu wissen auf welche Abteilungen oder Standorte es die Kosten für Ihre Modernisierungs- oder Migrationsbemühungen zu verteilen gilt.

Seeking application owners? Find its stakehoders first!

Schlaglöcher im Quellcode

Die meisten Anwendungen haben Abhängigkeiten zu dem einem oder einem Teil Ihrer Umgebung. Viele davon sind im Code selbst verwurzelt: hartcodierte Server oder Benutzernamen, IP-Adressen, externe Bibliotheken, Faxsysteme usw. Sie müssen wissen, wo diese Abhängigkeiten sind, welche Auswirkungen sie haben und wie sie auf die effizienteste Weise behoben werden können, ohne Hunderte oder Tausende von Schablonen umgestalten zu müssen.

Don't end up in a ditch because you weren't aware of roadblocks in your source code

Von nun an wird es eine kontinuierliche Erweiterung des Anwendungskreises sein, an dem wir arbeiten. Jeder Schritt wird kostenintensiver, und eine umsichtige Planung wird immer größere Vorteile bringen.

Click to access series overview!

Über diese Serie:

Unzählige Unternehmen weltweit setzen seit Jahrzehnten auf Notes/Domino*. Diese mächtige Applikations- und Kollaborationsplattform hat sich in vielen Unternehmen Zug um Zug als Fundament von Arbeitsweisen und etlichen Prozessen etabliert. Trotz alledem beginnen IT-Entscheidungsträger, sich eine Zukunft vorzustellen, in der Notes/Domino möglicherweise eine geringere oder gar keine Rolle mehr spielen könnte.

*früher IBM Notes/Domino


Kommentar hinterlassen

Start typing and press Enter to search

engage 2020Seeking application owners? Find its stakeholders first!