In einer Diskussion mit meinem Kollegen Craig Burton habe ich mich unlängst über die Frage unterhalten, was die Gründe dafür sind, dass in vielen Fällen Funktionen proprietär in einzelnen Softwarelösungen integriert werden, die doch eigentlich auch als Standardfunktion in vielen Unternehmen zu finden sind. Dafür gibt es gute und schlechte Gründe – so unser Ergebnis.

Anwendungen mit eigenem Benutzermanagement, Anwendungen mit eigenen Workflow-Systemen, Anwendungen mit fest codierten Businessregeln wie beispielsweise Limits für Genehmigungen und so weiter – das sind keine Ausnahmen, sondern die Regel. Was beim Blick auf die einzelne Anwendung unproblematisch ist, wird in der Gesamtsicht schnell zum Problem.

Wesentliche Teile des Identity und Access Managements beschäftigen sich damit, die Benutzerinformationen aus verschiedenen Systemen, die Kennwörter und andere Daten in den Griff zu bekommen. Ganze Entwicklungsabteilungen leben davon, fest codierte Businessregeln immer wieder mal zu ändern. Und ganze Segmente des IT-Marktes wie beispielsweise der EAI- oder ETL-Markt (Enterprise Application Integration, Extract – Transformation – Load) haben ihre Daseinsberechtigung zu einem Gutteil ebenfalls deshalb.

Natürlich gibt es hier viele Altlasten, die über Jahre und Jahrzehnte entstanden sind. Nur: Es entstehen auch ständig neue Lasten, und zwar überall. Ob es sich um Eigen- oder Auftragsentwicklungen, COTS-Software (Common of the shelf) oder Cloud-Dienste handelt – überall finden sich wohl mehr Beispiele für mangelnde als gelungene Wiederverwendung.

Natürlich macht das in manchen Fällen Sinn. Eine standardmäßige Datenbank hat den Vorteil, dass sich Systeme oft leichter und schneller installieren lassen. Wenn man aber optional auch das nutzen kann, was im Unternehmen Standard ist und im Storage Management mit viel Aufwand optimiert wurde, ist es noch besser. Spezielle Workflows können deutlich einfacher in der Nutzung sein und optimierte Funktionen bieten, die sich bei Standard-Workflow- oder –BPM-Systemen nicht finden.

Anders sieht es im Bereich des Identity und Access Managements aus. Dort gibt es praktisch keine Gründe mehr dafür, auf eine gezielte Externalisierung von Administration, Authentifizierung, Autorisierung und Auditing zu verzichten, weil der Nutzen, das in den Anwendungen zu machen, fehlt – aber der resultierende Schaden umso größer ist, gerade mit Blick auf die wachsenden Compliance-Anforderungen.

Wenn man dann aber beispielsweise bei einer Access Governance-Lösung und einem Identity Provisioning-System zwei verschiedene Workflow-Systeme hat, die sich (nur) teilweise in der Funktionalität überdecken, wird auch deutlich, dass man schnell an die Grenzen stößt. Wenn der Lifecycle für Rollen und Business-Regeln im Access Governance-Werkzeug umgesetzt werden muss, der für Benutzer aber im Provisioning-System, dann bedeutet das entweder auch getrennte Benutzerschnittstellen oder eine aufwändige Integration, von der Herausforderung für den Aufbau von Know-How und die Pflege der Anwendungen oder die zentrale Dokumentation dieser Prozesse in einem Werkzeug wie ARIS ganz zu schweigen.

Was führt nun dazu, dass immer noch viel zu wenig Software zumindest die Option bietet, vorhandene Infrastrukturdienste zu nutzen? Zum Teil sind das fehlende oder nicht ausreichend etablierte Standards. XACML für die Externalisierung der Autorisierung ist beispielsweise noch recht neu. Zum Teil ist es die simple Tatsache, dass über dieses Thema offensichtlich nie nachgedacht wurde.

Zum Teil ist es auch die fehlende Bereitschaft, offene Lösungen umzusetzen, sei es, weil es komplexer ist oder sei es, weil die Entwickler glauben, sie könnten es selbst besser (ein leider immer wieder anzutreffendes Phänomen). Das Ergebnis ist, dass das Rad mit schöner Regelmäßigkeit neu erfunden wird. Nur läuft es eben oft nicht rund, schon gar nicht in einer IT-Infrastruktur, in der es eben nicht nur diese eine Anwendung gibt, sondern viele.

Das Thema kann man durch Vorgaben für die Eigen- und Auftragsentwicklung adressieren, durch Regeln für den Einkauf von Software und durch geeignete Auswahlkriterien für Cloud-Dienste. Allerdings wird man häufig an der Herausforderung scheitern, dass die Argumente „das Business braucht aber genau diese Lösung“ oder „die Entwicklung mit solchen Schnittstelle braucht zu lange“ ins Feld geführt werden.

Wer eine entsprechende Infrastruktur hat, wer in der Eigenentwicklung klare Vorgaben für die zu verwendenden Schnittstellen und einfache Komponenten für deren Nutzung hat und wer seine IT so gestaltet hat, dass sie durch eine konsequente Service-Orientierung flexibel und schnell auf Business-Anforderungen reagieren kann, hat aber auch gute Gegenargumente.

Das wichtigste Gegenargument ist, dass sich die vermeintlichen Vorteile, die hinter den beiden genannten Argumenten stehen, in der Praxis schnell als Nachteile erweisen – spätestens dann, wenn das Business noch ein bisschen mehr möchte und man darauf eben nicht mehr so schnell reagieren kann.