Die Informatik ist dabei, im Umfeld des SCCM jene Fehler zu wiederholen, die sie bereits bei der Anwendungsentwicklung gemacht hat: Sie stellt Datensilo neben Datensilo und schafft sich damit ein Integrationsproblem.

Die Begeisterung für EAI ist vorbei, und auch um ihren Nachfolger SOA ist es stiller geworden. EAI wird als Marketingvorläufer von SOA in die Geschichte eingehen. (Zur Erinnerung: EAI  – Enterprise Application Integration und SOA – Service-Oriented Architecture.)

EAI und SOA sind Antworten auf ein Problem, das die IT sich selbst eingebrockt hat, und das sie im Kontext des SCCM zu wiederholen sich anschickt: fehlende Integration, Funktions- und Datenredundanzen, inkompatible Anwendungen, Datensilos, Anwendungs- anstatt Prozessorientierung.

Geplant integrieren – nicht hinterherhinken

Wir sollten es nicht so weit kommen lassen wie bei den Anwendungen: Anstatt hinterher zu integrieren, müssen wir jetzt die Weichen so stellen, dass wir möglichst viele der Integrationsprobleme zum Vornherein verhindern können.

Jeder für sich

In der Unternehmens-IT wurde Anwendung neben Anwendung gestellt, Datensilo neben Datensilo, jede Anwendung schaute für sich, strukturierte und füllte ihre Datenbanken nach ihren Bedürfnissen, stellte ihre eigenen Regeln für die Schnittstellen auf und kümmerte sich möglichst wenig um die Verbindung zu anderen Anwendungen.

Mühsame Integration

Als das Internet-Geschäft kam, änderten die Abläufe, die Integrationsprobleme begannen. Nur mit Ächzen und Würgen brachten die Entwickler  funktionierende Systeme zustande.

Je weiter die Automatisierung der Anwendungen durch die Informatik  fortschritt, desto stärker zeigten sich die Mängel der Anwendungstopographie: Wo früher Sachbearbeiter die Holprigkeiten in den Schnittstellen und Abläufen mit Handarbeit glätteten, Lücken füllten und geduldig redundante Daten abglichen, waren nun plötzlich präzise Schnittstellen  und klar geregelte Zuständigkeiten für die Datenhoheit erforderlich.

Die erste Antwort war der Flicken EAI, der die gröbste Not behob aber neue Probleme schuf. Die zweite Antwort ist die im Nachhinein aufgepfropfte SOA, die jetzt abgelöst wird durch eine SOA, die auf einer Planung der Anwendungslandschaft aufbaut.

SCCM: Teil des Application Lifecyle Managements – ALM

Zurück zum SCCM. Was einmal mit der Versionskontrolle begann, hat sich immer weiter ausgedehnt: Configuration Management, Release Management, Work Area Management, Build Management und Change Management sind im Laufe der Zeit dazugekommen und machen heute das SCCM aus. (Siehe dazu unser SCCM-Referenzmodell.)

In unmittelbarer Nachbarschaft des SCCM entstehen seit einiger Zeit laufend zusätzliche Anwendungen, die in enger Beziehung zum SCCM stehen und dessen Daten verwenden (sollten!): Enterprise Architecture Management, Project Portfolio Management, Configuration Management, Versionsverwaltung, Requirements Management, Change Management, ITIL, CMDB – usw. usf.  Diese enthalten genau so redundante Daten und Funktionen und benötigen Integration wie die Anwendungen, über die sie  Metadaten speichern.

Auch SCCM ist keine Insel, sondern Teil eines grösseren Ganzen, des Application Lifecycle Managements – ALM. Auf gut Deutsch: Anwendungsbewirtschaftung.

Wir müssen über den Tellerrand des SCCM hinausblicken, um nicht noch einmal die gleichen Probleme wie bei der Anwendungsintegration zu verursachen. Wir müssen aus den EAI- und SOA-Erfahrungen mit den Anwendungen unsere Lehren ziehen.

Was ist zu tun? Davon handelt diese Serie.

Weitere Beiträge in dieser Reihe

(2) Anwender- und prozessorientiert zum Erfolg
(3) Manuelle Arbeit — und wie man sie besser los wird
(4) Am Anfang steht die Anforderungsanalyse
(5) ITIL und ALM
(6) Ohne Istaufnahme geht es nicht
(7) Verzicht, Vereinfachung und Automatisierung
(8) Ein Projekt
(9) Prozessautomation
(10) Zukunftsaufgabe Metadaten-Integration

Tags: ALM-Integration

Trackback URI | Kommentare als RSS