HOPEX und ServiceNow verbinden:
So gelingt der Connector

In vielen Unternehmen existieren zwei Wahrheiten über die IT-Landschaft: Die Enterprise-Architekten pflegen ihr Applikationsportfolio in HOPEX von MEGA – mit Capabilities, Technologie-Roadmaps und Lifecycle-Planung. Parallel dazu pflegt der IT-Betrieb seine Business Applications in der ServiceNow-CMDB – als Aufhänger für Incidents, Changes und Service-Zuordnungen. Beide Listen meinen dasselbe, stimmen aber selten überein. Genau dieses Problem löst die Integration der beiden Plattformen.

Warum sich die Integration lohnt

HOPEX und ServiceNow betrachten die gleiche IT-Landschaft aus unterschiedlichen Blickwinkeln. HOPEX beantwortet strategische Fragen: Welche Applikationen unterstützen welche Geschäftsfähigkeiten? Wo droht Technologie-Obsoleszenz? Was steht auf der Ablösungs-Roadmap? ServiceNow beantwortet operative Fragen: Welche Applikation ist von diesem Incident betroffen? Welche Services hängen an diesem Change?

Ohne Integration entstehen zwei Pflegeaufwände, zwei Versionsstände und endlose Abstimmungsrunden, welche Liste denn nun stimmt. Mit Integration fließen Architektur-Informationen in den Betrieb und Betriebsdaten zurück in die Architekturplanung – etwa reale Incident-Zahlen als Input für Rationalisierungsentscheidungen.

Was typischerweise synchronisiert wird

• Business Applications: das Herzstück – das Applikationsportfolio aus HOPEX wird mit cmdb_ci_business_app in ServiceNow abgeglichen
• Lifecycle-Informationen: Status wie „geplant", „produktiv", „in Ablösung", „abgeschaltet" – inklusive geplanter Termine
• Verantwortlichkeiten: Application Owner, Architektur-Verantwortliche, Fachbereichszuordnung
• Technologie-Komponenten: eingesetzte Software-Produkte und -Versionen für Obsoleszenz-Analysen
• Beziehungen: Zuordnungen zwischen Applikationen, Capabilities und – je nach Modellierungstiefe – Application Services

Wichtig: Synchronisieren Sie nicht alles, was technisch möglich ist, sondern nur Attribute, die im Zielsystem einen echten Abnehmer haben. Jedes synchronisierte Feld ist ein Feld, dessen Qualität Sie ab sofort in zwei Systemen verantworten.

Die wichtigste Entscheidung: Wer führt welche Daten?

Bevor irgendetwas konfiguriert wird, braucht es eine klare Antwort auf die Frage nach dem führenden System – und zwar pro Attribut, nicht pauschal pro Objekt. Ein bewährtes Muster aus unseren Projekten: HOPEX führt das Portfolio (welche Applikationen existieren, Lifecycle-Strategie, Architektur-Bewertungen), ServiceNow führt den Betrieb (Support-Gruppen, operative Status, Service-Beziehungen).

„Eine Integration ohne geklärte Datenhoheit erzeugt keinen Single Point of Truth – sondern zwei Systeme, die sich gegenseitig überschreiben."

Halten Sie diese Entscheidung schriftlich fest, bevor das Mapping entsteht. Sie bestimmt die Synchronisationsrichtung jedes einzelnen Feldes und erspart Ihnen später die klassischen Ping-Pong-Updates, bei denen zwei Scheduled Jobs abwechselnd denselben Wert hin- und herschreiben.

Voraussetzungen

• Eine HOPEX-Version mit aktiviertem API-Zugang (REST bzw. GraphQL) oder dem von MEGA bereitgestellten ServiceNow-Connector – die Details unterscheiden sich je nach HOPEX-Release, klären Sie den Stand mit Ihrem MEGA-Ansprechpartner
• Ein dedizierter Integrationsuser in ServiceNow mit minimalen Rechten (Import- und Schreibrechte nur auf die benötigten CMDB-Tabellen – kein Admin-Account)
• OAuth 2.0 als Authentifizierungsverfahren auf beiden Seiten – Basic Auth nur, wenn es wirklich nicht anders geht
• Ein bereinigtes Applikationsportfolio in HOPEX: Duplikate und Karteileichen wandern sonst ungefiltert in die CMDB
• Eindeutige, stabile Identifier auf beiden Seiten – dazu gleich mehr

Einrichtung in fünf Schritten

1. Verbindung herstellen: Registrieren Sie in ServiceNow einen OAuth-Endpoint für den HOPEX-Zugriff und hinterlegen Sie die Instanz-URL samt Credentials in der HOPEX-Integrationskonfiguration. Testen Sie die Verbindung zunächst gegen eine Sub-Production-Instanz – niemals direkt gegen Produktion.
2. Mapping definieren: Ordnen Sie die HOPEX-Objekte den ServiceNow-Tabellen zu – allen voran die Applikation zu cmdb_ci_business_app. Mappen Sie Attribut für Attribut und definieren Sie für jedes Feld die Richtung. Besondere Sorgfalt verdienen Wertelisten: Lifecycle-Status heißen in beiden Systemen anders und brauchen eine explizite Übersetzungstabelle.
3. Korrelation festlegen: Verlassen Sie sich niemals auf Applikationsnamen als Abgleichschlüssel – Namen ändern sich. Schreiben Sie stattdessen die eindeutige HOPEX-ID in das Feld correlation_id des ServiceNow-CIs. Auf ServiceNow-Seite sorgt die Identification and Reconciliation Engine (IRE) dafür, dass Datensätze sauber erkannt statt dupliziert werden.
4. Initialload durchführen: Der erste Abgleich ist ein eigenes Projekt im Kleinen. Matchen Sie zunächst bestehende Einträge (automatisch über exakte Treffer, den Rest manuell), bevor der Connector neue CIs anlegen darf. Planen Sie hier bewusst Zeit für die Bereinigung ein – jedes Duplikat, das jetzt durchrutscht, verfolgt Sie jahrelang.
5. Scheduling und Monitoring aufsetzen: Für die meisten Portfolios reicht ein täglicher Delta-Abgleich völlig aus – Applikationsdaten ändern sich nicht im Minutentakt. Richten Sie ein Monitoring ein, das fehlgeschlagene Synchronisationsläufe aktiv meldet, statt still zu scheitern: Ein Connector, der drei Wochen unbemerkt steht, ist schlimmer als gar keiner.

Typische Stolpersteine

• Business Application vs. Application Service: HOPEX kennt die Applikation als Portfolio-Objekt, ServiceNow unterscheidet nach CSDM zwischen Business Application (Portfolio-Sicht) und Application Service (betriebene Instanz). Wer das vermischt, bekommt ein Datenmodell, das weder Architekten noch Betrieb versteht.
• Granularitäts-Mismatch: Was in HOPEX eine Applikation ist, sind in ServiceNow manchmal drei – oder umgekehrt. Diese Fälle lassen sich nicht wegkonfigurieren, sie brauchen eine Modellierungsentscheidung.
• Status-Übersetzung: Ein „Phase-out" in HOPEX ist nicht automatisch ein „Retired" in ServiceNow. Unsaubere Status-Mappings führen zu CIs, die im Betrieb fehlen oder fälschlich als aktiv gelten.
• Personenbezogene Daten: Owner-Informationen sind personenbezogen – klären Sie mit dem Datenschutz, welche Felder synchronisiert werden und wie Verantwortliche in ServiceNow als Referenz auf sys_user aufgelöst werden.
• Release-Wechsel: Sowohl HOPEX- als auch ServiceNow-Upgrades können APIs und Connector-Verhalten ändern. Nehmen Sie die Integration in Ihre Upgrade-Checkliste auf und testen Sie sie nach jedem Release-Wechsel.

Best Practices für den Betrieb

• Einen fachlichen Owner für die Integration benennen – nicht nur einen technischen
• Synchronisationsläufe protokollieren und Abweichungen wöchentlich reviewen
• Ein gemeinsames Gremium aus EA- und CMDB-Team etablieren, das Modellierungsfragen entscheidet
• Den Attribut-Umfang bewusst klein starten und nur bei echtem Bedarf erweitern
• Die Mapping-Dokumentation als lebendes Dokument pflegen – sie ist nach einem Jahr das einzige, was erklärt, warum die Daten so fließen, wie sie fließen

Richtig aufgesetzt, verschwindet mit dem Connector eine der zähesten Dauerbaustellen zwischen Architektur und Betrieb: die Frage, welche Applikationsliste eigentlich stimmt. Die Antwort lautet dann: beide – weil es nur noch eine ist.