Wer schützt die Anwender vor den Folgen von Firmen-Übernahmen? Diese Frage stellt sich immer wieder, wenn Anbieter akquiriert werden – auch im Bereich Identity- und Access-Management. Die Antwort ist einfach und doch komplex: Man muss sich selbst schützen, indem man das Risiko von Anfang an in der Architektur berücksichtigt.

Ob es um die Übernahme von Sun durch Oracle, den Verkauf von Novell an Attachmate und die nun erfolgte Zuweisung von Teilbereichen an NetIQ, die Weitergabe von BMC Control-SA an Sailpoint oder andere Akquisitionen geht: Die Verunsicherung bei den Kunden ist oft groß. Dazu gehört auch, dass nicht alle Hersteller in dieser Phase durch eine gute Kommunikation glänzen.

Natürlich gibt es einen gewissen Zeitraum, in dem Aussagen aus finanzrechtlichen Gründen nicht möglich sind. Danach aber wären klar definierte Roadmaps, Migrationsstrategien und lange Wartungszeiträume das, was man aufzeigen muss. Manchmal klappt das ganz gut, wie im Fall von Oracle/Sun, in anderen Fällen sieht es dagegen eher düster aus.

Damit wächst die Verunsicherung der Kunden, die dann natürlich besonders groß ist, wenn ein Produkt früher oder später ausläuft. Wer beispielsweise im Provisioning-Bereich eine zentrale Lösung hat und dort oft viel Geld und Zeit in die spezifische Anpassung gesteckt hat, der möchte ungern wieder von vorne beginnen.

Wenn ein Produkt eingestellt wird, wird sich das früher oder später nicht vermeiden lassen. In allen Fällen kann man aber zumindest den mit einer Umstellung verbundenen Aufwand minimieren und das Risiko verringern, früher oder später wieder in die gleiche Situation zu kommen. Dabei hilft die technische Entwicklung ebenso wie die gestiegene Reife bei der Projektumsetzung von Identity- und Access-Management-Infrastrukturen.

Bis vor nicht allzu langer Zeit war eine monolithische Schicht für das Provisioning noch der Standard. Viele Unternehmen haben sich aber schon immer damit schwergetan, eine Provisioning-Lösung umzusetzen. Technische Herausforderungen wie die optimale Unterstützung von Host- oder SAP-Umgebungen, schnelle Veränderungen durch Zukäufe oder politische Grabenkämpfe zwischen der SAP-Lobby (SAP NetWeaver Identity Management), der Microsoft-Lobby (Microsoft Forefront Identity Manager) und anderen Gruppen im Unternehmen haben sich hier als Hürde erwiesen.

Nicht umsonst setzen sich immer mehr modulare Ansätze durch, bei denen Access-Governance- und/oder Service-Management-Lösungen als integrierende Schicht dienen, um Rollen, Funktionstrennungen und Anträge zu verwalten. Die eigentlichen Provisioning-Lösungen werden damit integriert und übernehmen eine technische, ausführende Funktion.

Solche Ansätze ermöglichen es beispielsweise, schrittweise für bestimmte Systeme oder Unternehmensbereiche neue Lösungen einzuführen, ohne alles ändern zu müssen. Klar ist, dass man sich mehr Gedanken über Architektur und Integration machen muss als bei monolithischen Lösungsansätzen. Dafür kann man aber auch flexibler Änderungen vornehmen und beispielsweise schrittweise Teilbereiche migrieren, während man Systemumgebungen mit einem besonders hohen Grad an Customizing wie Host-Umgebungen länger mit „Altsystemen“ im Provisioning steuert.

Auch hier kann an unterschiedlichsten Stellen ein Änderungsbedarf entstehen, weil einer der Anbieter übernommen wurde. Nur: Man kann flexibler reagieren und muss nicht alles, sondern nur Teile des Systems verändern. Der Schutz von Investitionen wird vereinfacht.

Nebenbei bemerkt: Sich nach dem Motto „Buy IBM and you won‘t be fired“ auf die großen Hersteller zu verlassen – wobei IBM durch andere Anbieternamen ersetzt werden kann – ist alleine keine ausreichende Strategie. Denn Sun galt durchaus als großer Anbieter, Novell wurde ebenfalls eher den etablierten Herstellern zugeordnet – und auch BMC ist ja kein kleines Unternehmen. Viel besser ist es, die Systemarchitektur von Anfang an so auszulegen, dass man einzelne Teile möglichst problemlos austauschen kann.