Der typische Technikfreak begegnet jeder Herausforderung mit einer einfachen Frage: „Kann ich die Lösung selbst bauen?“ Und oft ist die Frage so berechtigt, dass sie ernsthaft in Betracht gezogen wird. Sollen wir also bauen oder kaufen? Bewertung eines Lösung zum Vorfallmanagement scheint diese Frage nun auch aufzuwerfen. Aber woher wissen Sie, wann Sie Ihre Vorfallmanagementplattform erstellen oder kaufen sollten?

Warum bauen?

Manchmal liegt der Wunsch, eine eigene Lösung zu entwickeln, einfach darin begründet, dass die Beschaffung einer kommerziellen Lösung nicht in Ihren Händen liegt. Beispielsweise hat die Unternehmens-IT das Budget für das Tool, aber die DevOps-Team braucht es. Es mag einfacher erscheinen, eine Lösung aus Open-Source-Projekten zu entwickeln, als sich auf die langwierigen Verhandlungen einzulassen, die nötig sind, um eine Lösung zu kaufen. Aber das ist ein organisatorisches und kein technisches Problem. Und oft ist die maßgeschneiderte Lösung nur von kurzer Dauer.

Es gibt jedoch noch weitere Gründe, warum Sie möglicherweise eine eigene Lösung erstellen möchten:

• Tatsächliche oder vermeintlich einzigartige Anforderungen
• Sicherheits- und Datenschutzbedenken
• Kosten

Dies sind triftige Gründe dafür, den Aufbau einer eigenen Vorfallmanagementlösung in Betracht zu ziehen. Sie müssen jedoch alle genau geprüft werden.

Sind Ihre Anforderungen wirklich einzigartig? Um herauszufinden, ob dies der Fall ist, sollten Sie sich Ihre Konkurrenten und deren Einsatzmöglichkeiten ansehen und Ihre Anforderungen mit denen ähnlicher Unternehmen vergleichen. Und gleichzeitig sollten Sie sich, selbst wenn Sie einzigartige Anforderungen haben, fragen, warum diese so einzigartig sind. Muss das so sein?

Was die Sicherheit betrifft , was ist mit Ihrem Sicherheit und Datenschutzbedenken, die sie für das kommerzielle Vorfallmanagement zu einem No-Go machen? Liegt es an der Möglichkeit offengelegter Daten? In den meisten Fällen müssen Anwendungsdaten nicht in Warnmeldungen einbezogen werden, aber wenn doch, ist dies zu berücksichtigen. Wenn die Bedenken die Sicherheit im Allgemeinen betreffen, denken Sie daran, dass Anbieter daran arbeiten, sicherzustellen, dass sie über Sicherheitsbedrohungen auf dem Laufenden sind. Oft sind sie in der Lage, die Sicherheit viel besser im Griff zu haben als interne Betriebsteams.

Und dann sind da noch die Kosten. Die Kosten sind ein heikles Thema, da die teuersten Aspekte beim Erstellen einer eigenen Lösung nicht einfach zu berechnen sind. Es ist einfach, die monatliche Gebühr für einen Vorfallmanagementdienst mit den Kosten für eine einmalige Entwicklung durch einen Vollzeitentwickler zu vergleichen. Laufende Wartung, Funktionsänderungen und das Wichtigste – Opportunitätskosten – lassen sich jedoch nur schwer vorhersagen. Woran würden die Entwickler arbeiten, wenn sie diese Lösung nicht erstellen würden? Und was kostet es, Projekte oder Rückstände während der Entwicklung beiseite zu legen? Ein weiteres Problem entsteht, wenn die Person, die die Lösung erstellt hat, das Unternehmen verlässt und das Verständnis der Codebasis mitnimmt. Sie möchten nicht, dass Stammeswissen das Unternehmen verlässt, wenn es mit einem unternehmenskritischen Teil Ihrer Infrastruktur zusammenhängt.

Integrieren Sie?

Der Aufbau einer Incident-Management-Lösung hat eine besondere Schwachstelle: Integrationen. Erfolgreiche Incident-Management-Plattformen haben eine riesige Bibliothek an Integrationen in Quellen (wie Ihre Anwendung und Infrastruktur) und Verteilung (wie Ihre Collaboration-Tools). Der Aufbau dieser Integrationen nimmt ziemlich viel Zeit in Anspruch und erfordert oft, dass Entwickler neue lernen und darauf aufbauen APIs . Organisationen, die ihre eigene Vorfallmanagement-Plattform aufbauen, müssen möglicherweise nur mit Integrationen arbeiten, die für sie wichtig sind, da sie nicht unterstützt viele Anwendungsfälle . Aber wenn sich die APIs für diese Systeme ändern, kann es Sie überrumpeln – Sie verpassen neue Funktionen oder die Plattform funktioniert nicht mehr. Open-Source-Projekte reagieren nicht so schnell auf Änderungen bei Integrationen oder erstellen keine neuen, und wenn etwas nicht funktioniert, muss Ihr Entwickler, der bereits mit etwas anderem beschäftigt ist, alles stehen und liegen lassen und sich darum kümmern. Und natürlich kann sich auch die Auswahl der Tools ändern, die Ihr Incident-Management-System integrieren muss, wenn die Das Team wächst und seine Bedürfnisse ändern sich .

Wann bauen?

Es gibt ein Szenario, in dem eine maßgeschneiderte Vorfallmanagementplattform auf Basis von Open-Source-Projekten nützlich ist, und zwar dann, wenn sie für zweckgebundene, sehr nischenspezifische Szenarien benötigt wird. Im Allgemeinen verfügen Organisationen, die eine solche Lösung benötigen, über ein kommerzielles Vorfallmanagement für die globale Umgebung und rollen es für das Nischenszenario auf oder integrieren es sogar in die API der Vorfallmanagementplattform.

Der andere Zweck könnte darin bestehen, Warnungen zu senden, die in einem anderen Kontext als für die Anwendungs- oder Infrastrukturunterstützung verwendet werden. Vielleicht werden die Warnungen für die Zusammenarbeit oder das Produktmanagement verwendet. In solchen Fällen kann es sinnvoll sein, den Anwendungsfall vom kommerziellen und unternehmenskritischen Vorfallmanagementsystem durch ein eher selbst entwickeltes und weniger haftungsintensives System für die anderen Anwendungsfälle zu trennen. Dies kann für Teams zutreffen, die bereits viele Anpassungen vorgenommen haben, wenn es darum geht, aus ihrer Anwendungsnutzung zu lernen. Wenn beispielsweise eine neue Funktion eingeführt wird, können Sie festlegen, dass Sie Warnungen erhalten, wenn diese Funktion verwendet wird, oder wenn eine neue Infrastruktur eingeführt wird, können Sie festlegen, dass Sie benachrichtigt werden, wenn Sie einen bestimmten Leistungs-KPI erreichen, um die Auswirkungen der Änderungen zu verstehen.

Der andere Grund sind Bedenken hinsichtlich interner und externer Datenlecks. Beispielsweise können Warnungen, bei denen durch die Behebung personenbezogene Daten dem internen Tier-1-Support offengelegt werden, dieser jedoch nicht die Befugnis hat, diese einzusehen, ein Problem darstellen. Dies kann insbesondere in regulierten Branchen ein Problem darstellen. In neun von zehn Fällen können Sie Ändern Sie Ihre Rollen in der Plattform und was freigelegt ist, also ist das nie ein Problem. Im Allgemeinen sollten Sie das immer versuchen. Aber es gibt seltene Fälle, in denen es unvermeidlich ist.

Deine Zeit zu glänzen

Ein erfahrener Techniker weiß, wann der richtige Zeitpunkt zum Bauen oder Kaufen gekommen ist, und zwar unabhängig davon, ob er selbst daran herumbasteln oder Probleme lösen möchte. Bei der anfänglichen Erstellung der Lösung bleiben Sie nicht stecken. Es ist der langfristige Support und das mit benutzerdefinierten Lösungen verbundene Risiko. Und es geht nicht nur um die Erstellung der Lösung – Sie müssen sie auch ausführen. Installieren Sie ein Vorfallmanagementsystem für Ihr Vorfallmanagementsystem? Sich um die Betriebszeit von etwas anderem sorgen zu müssen, ist stressig, und wenn das Vorfallmanagement ausfällt, fliegen Sie blind.

Benutzerdefinierte Nischenintegrationen in Ihre Codebasis und Infrastruktur rechtfertigen manchmal den Aufbau einer eigenen Vorfallmanagementlösung. Oder wenn Sie nicht unternehmenskritische Anwendungsfälle haben, die nur am Rande mit Ihrem kommerziellen Vorfallmanagement zu tun haben, kann es sich lohnen, eine eigene Lösung zu entwickeln. Im Allgemeinen hat eine kommerzielle Lösung jedoch geringere Gesamtbetriebskosten, wird Ihren Anforderungen bei der Skalierung gerecht, stellt sicher, dass Tools und Prozesse nicht zusammenbrechen, wenn bestimmte Experten das Unternehmen verlassen, und bietet eine bessere Abdeckung und Lösungen für Ihre Sicherheits- und Datenschutzbedenken.

Bei der Entscheidung, ob Sie bauen oder kaufen, empfehle ich, sich stark auf die Opportunitätskosten zu konzentrieren. Dies ist die größte Unbekannte und Ausgabe, und normalerweise wird die Antwort ziemlich schnell klar.