Ein IGA-Projekt beginnt schon vor der Implementierung Ratgeber für Identity Governance und Administrations­projekte

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

Pathlock Deutschland | akquinet enterprise solutions GmbH

valvisio international AG

One Identity GmbH

Es ist kein alltägliches Vorkommen, dass Unternehmen beschließen, ein Identity Governance und Administration (IGA) Projekt anzugehen. Manche haben die Aufgabe, digitale Identitäten und deren Berechtigungen richtlinien­gerecht zu verwalten schon in der Vergangenheit erledigt. Aus den verschiedensten Gründen muss sich jedoch der ein oder andere erneut auf den Weg machen, ein neues Produkt auszuwählen.

Für manche Unternehmen ist es jedoch das erste Mal, dass sie vor der Frage stehen, wie und wo fange ich an, um zur bestmöglichen Produktentscheidung und einem erfolgreichen Projekt zu gelangen. Die Reichweite und Bandbreite der Aspekte, die bereits vor einer Produktauswahl berücksichtigt werden sollten, ist groß. Dieser Artikel gibt eine Hilfestellung zu den grundlegenden Punkten, die bereits vor der Entscheidung für ein Produkt und der folgenden Implementierung vom Unternehmen geklärt werden müssen. Damit nicht nur die Entscheidung für ein Produkt leichter fällt, sondern sie sich als richtig erweist.

Es mag irritieren, dass ein Hersteller sich zur Produktauswahl für ein IGA-Projekt äußert, aber natürlich sieht ein Anbieter – ähnlich wie Beratungshäuser – viele IGA-Projekte und etliche Herangehensweisen an ein solches Projekt. Darunter solche, die für ein Unternehmen gut funktionieren. Aber auch Vorgehensweisen, bei denen man den Kopf schüttelt und sich beispielsweise fragt: Wie soll ein Katalog von 500 Fragen an einem Produkthersteller und ohne Bezug zum ausschreibenden Unternehmen bei der Produktauswahl helfen? Zugegeben, ein extremes, aber ein gutes Beispiel. Denn auch wenn die Anforderungen von Unternehmen zu Unternehmen ähnlich sein können, müssen die Rahmenbedingungen definiert werden. Angefangen von “Woher kommt der Bedarf, das IGA-Thema anzugehen?” bis hin zu Anforderungen, die durch die Infrastruktur und die Strategie (z.B. Cloud First) gegeben sind. Es gilt zu definieren, welches die Ziele sind und welche Prioritäten das Unternehmen setzt. Ob der Komplexität des IGA-Themas stellt sich meist recht schnell die Frage, welche Erfahrungen im Unternehmen vorhanden sind, oder ob externe Beratung und Unterstützung benötigt wird. Sind all diese Punkte bewertet, kann man sich mit dem Prozess der Produktauswahl beschäftigen. Dieser kleine Leitfaden soll helfen, das Projekt vor dem Projekt zu meistern.

Was, wer und immer wieder warum

Nun haben Sie den Auftrag, ein IGA-Projekt durchzuführen. Die erste Frage, die Sie klären sollten, ist immer „Warum stoßen Sie jetzt ein IGA-Projekt an?“. Es gibt eine große Bandbreite von Themen, die durch IGA adressiert werden. Typische Gründe sind z.B. Compliance, Effizienz und Risikominimierung. Wo liegen Ihre Themenschwerpunkte und wie sind diese gewichtet? Was bedeutet Erfolg für Ihr Projekt, und welche konkreten Ziele müssen erreicht werden? Ebenso wichtig ist es, den zur Verfügung stehenden Zeitrahmen zu verstehen. Der Zeitrahmen kann auch durch externe Anlässe wie bemängelte Compliance-Verstöße definiert. Manchmal ist es dann erforderlich, dass herkömmliche Meilensteine eines IGA-Projekts in einer ungewöhnlichen Reihenfolge angesteuert werden müssen.

Verlieren Sie nie aus den Augen, wer der Auftraggeber ist, die Projekthoheit hat und schlussendlich verantwortlich ist. Planen Sie rechtzeitig einen Lenkungsausschuss bestehend aus IT, Revision und den betroffenen Geschäftsbereichen. Es ist unerlässlich, jederzeit absolute Transparenz gegenüber dem Lenkungsausschuss oder dem Auftragsgeber sicherzustellen. Kommunizieren Sie stets, welche Ziele mit dem vorhandenen Budget in welchem Zeitraum erreicht werden können.

Ein IGA-Projekt bedarf der Mitarbeiter vieler Abteilungen und Bereiche im Unternehmen. Das sollte sich auch in der Zusammensetzung des IGA-Projektteams widerspiegeln: In der Vorbereitungsphase/Initiierung sind abgesehen vom Projektleiter und dessen Stellvertreter vor allem Personen involviert, die Informationen zu den fachlichen Anforderungen aus den verschiedenen Bereichen sammeln, diese mit der IT analysieren und abstimmen. Das weckt Begehrlichkeiten und viele Personen/Abteilungen werden ihre Wünsche äußern. Aber Sie können nicht alles initial umsetzen, und es besteht die Gefahr den Fokus zu verlieren. Je eingeschränkter der Rahmen und das Budget des Projekts ist, desto weniger Themen können aufgenommen werden.

Im Idealfall ist das Projekt Teil einer umfassenden Sicherheitsstrategie. Dann sollte man kurz- und langfristige Ziele planen und auch andere Identity-Themen wie z.B. Privileged Access Management, also den Umgang mit hoch-privilegierten Konten und dem Zugriffsmanagement im Hinterkopf behalten. Ein frühzeitiges Gesamtbild verhindert Reibungsverluste in der Zukunft.

Unterschied neues Projekt oder Migration

Nicht immer ist es das erste Mal, dass ein Unternehmen ein Identity und Governance-Projekt in Angriff nimmt. Handelt es sich um eine Migration von einem bereits implementierten Produkt zu einem anderen, haben Sie den Vorteil, dass es bereits Know-how im Hause gibt. Es wurden bereits Erfahrungen gesammelt und etwaige Fehler werden hoffentlich nicht wiederholt. Die größte Gefahr bei einer Migration ist, dass alter Wein in neue Schläuche gegossen wird, und das resultiert in einem schalen Geschmack. Imitieren Sie nicht das vorherige Produkt und schon gar keine GUIs! Nutzen Sie die Stärken des neuen Produkts, ohne sich in den neuen Möglichkeiten zu verlieren. Das schont Ihr Budget und hilft das Projektziel im Auge zu behalten. Eine Migration bietet die Chance, Prozesse neu zu beleuchten und zu optimieren. Schneiden Sie alte Zöpfe lieber ab und konzentrieren sich auf die eigentlichen fachlichen Ziele. Wenn Ihr Auftrag eine Migration ist, bedenken Sie genau, wie sie ablaufen soll. Viele vermeiden einen Big Bang, um Risiken zu senken und sich schrittweise dem Ziel zu nähern. Aber es erfordert eine präzise Konzeption, wie diese Schritte aussehen sollen und wie sie sich jeweils auf die Anwender auswirken.

Wenn IGA für Sie ein neues Projekt ist, dann haben Sie vermutlich wenig Erfahrung, und es erwarten Sie einige Überraschungen. Klären Sie, welche Erfahrungen intern vorhanden sind, ob Ihr Unternehmen später bei der Implementierung selbst mitarbeiten möchte, und wie der Betrieb geleistet werden soll. Haben sie intern kaum oder nicht ausreichend Erfahrung für ein IGA-Projekt, dann bleiben Ihnen im Prinzip nur folgende Möglichkeiten: Sie stellen einen Experten ein oder Sie holen sich Unterstützung bei einem externen Beratungsunternehmen.

Externe Unterstützung

Wollen Sie ein externes Beratungsunternehmen beauftragen, sollten Sie intern besprechen und grob festlegen, welche Phasen des Projekts unterstützt werden sollen: Planung und Definition der Anforderungen, Produktauswahl, Implementierung, Betrieb? Alles?

Folgende Punkte sollten Sie bei der Auswahl externer Berater beachten.

• Ist bereits ein (IGA-erfahrenes) Beratungsunternehmen im Haus aktiv und mit der Firma gut vertraut? Das wäre ein deutlicher Pluspunkt. Prüfen Sie also, welche Unternehmen oder Berater bei Ihnen bereits Dienstleistungen erbringen.

• Um Recherchen kommen Sie nicht herum: Sprechen Sie mit befreundeten Unternehmen, oder auch Herstellern. Auch Online-Recherchen sind wichtig, aber suchen sie hierbei gezielt nach Kundenreferenzen.

Haben sie eine Reihe von Beratungsunternehmen ins Auge gefasst, prüfen Sie eingehend:

• Welche Erfahrung hat das Beratungsunternehmen? Fragen Sie nach Referenzen. Bitten Sie um Kontakt zu anderen Kunden mit vergleichbaren Projekten. Fragen sie die Unternehmen auch danach, welches Produkt ausgewählt wurde und welche Entscheidungskriterien maßgeblich waren.

• Wenn ein externer Berater mit der Erstellung des Anforderungskatalogs beauftragt ist, sollte sichergestellt werden, dass die Diskussion nicht mit einer leeren Excel-Tabelle und der Frage des Beraters: „So, welche Anforderungen haben Sie denn?“ startet. Der Berater sollte anhand eines erprobten und standardisierten Projekt-Ausführungs-, Entdeckungs- und Analyse-Rahmenwerks handeln.

Aber: Rahmenwerk heißt nicht, dass es fertig „aus der Schublade gezogen“ und angewendet wird, unbenommen der Anforderungen des Kunden. Prüfen Sie, ob man tatsächlich auf ihre spezifischen Bedürfnisse eingeht. Prüfkriterien und Dinge, die für sie irrelevant sind, sollten nicht aufgeführt oder entsprechend bewertet werden. Prüfen sie die Gewichtung der Fragen. Viele Fragen bedeuten nicht zwangsläufig, dass es sich um einen tauglichen Kriterienkatalog handelt.

IGA-Informationsgewinnung - Machen Sie sich schlau!

Informationen kann man aus unterschiedlichsten Quellen beziehen. Sie finden online einige Beiträge zu Herausforderungen und Lösungsansätzen im Kontext des Identity Managements. Unseres Erachtens ein guter Start, um sich einen Überblick zu verschaffen und Ideen zu sammeln.

Einen Überblick über die potenziellen Hersteller finden Sie bei Analysten und in deren Berichten – da lohnt sich ein Blick in die Details. Es gibt verschiedene Fachkonferenzen, auf denen nicht nur Hersteller auftreten, sondern auch Unternehmen, die sie von ihren Erfahrungen profitieren lassen. So bekommen sie einen Eindruck, mit welchen Herausforderungen andere konfrontiert waren und wie sie das Thema bewältigt haben.

Vielleicht können Sie dort auch Kontakte knüpfen, um einen intensiveren Erfahrungsaustausch mit anderen Unternehmen zu starten, die vor ähnlichen Anforderungen standen. Unseres Erachtens eine der besten Quellen, um Ihre Optionen besser zu verstehen.

Projektrahmen abstecken

Was kann man überhaupt schaffen? Die zentrale Frage, die aus unserer Sicht im Raum steht, ist: Welche Prozesse müssen implementiert werden und welche Rahmenparameter müssen dafür geschaffen werden. Ein Beispiel: Wenn sie automatische Prozesse zur Vergabe von Konten und Berechtigungen wünschen oder einen Genehmigungsprozess für Bestellungen von Berechtigungen, dann brauchen sie eine gute Datenqualität und akkurate HR-Daten oder Kostenstelleninformationen für die Genehmigungen.

Einige Aufgaben werden nur wenig Sichtbarkeit erzielen, sind aber essenziell für den Erfolg der darauffolgenden Schritte. Auch hier ist es wichtig, klar zu kommunizieren, warum dieser Zwischenschritt erforderlich ist – wie bereits beschrieben sind Transparenz und die Klärung der Erwartungshaltung wichtige Kriterien für IGA-Projekte.

Sie haben es schon bemerkt: die Definition von Zielen, Prioritäten und eine Abgrenzung zu dem, was sie nicht tun werden, nehmen bei der Planung einen erheblichen Raum ein. Sie werden vermutlich öfter hören, dass sie ja schon Prozesse haben – vertrauen Sie aber bitte nicht darauf, dass diese auch dokumentiert sind. Die Jagd nach den Prozessen, dem wie sie wirklich gelebt werden und warum sie so sind wie sie sind, ist eine spannende und zeitfressende Aufgabe.

Wenn sie zudem die langfristigen Planungen betrachten, werden vielleicht schon vorbereitende Aufgaben durchgeführt werden müssen. Stellen Sie sicher, dass jedem klar ist, warum sie bestimmte Dinge angehen – auch wenn es noch keine messbaren Erfolge gibt.

Am Ende werden sie eine Liste von Anforderungen haben, die eine Priorität berücksichtigen und klar definieren, warum die einzelnen Anforderungen relevant und welche Auswirkungen es hat, wenn sie im Rahmen des Projektes nicht berücksichtigt werden.

Lassen Sie sich nicht von Herstellern mit einer beeindruckenden Liste von Möglichkeiten und angrenzenden Themen wie PAM, Access Management etc. aus dem Konzept bringen. Das Einzige, was zählt, sind Ihre Anforderungen. Werfen Sie dennoch Blick auf weitere Möglichkeiten, wenn Sie an die Zukunft denken. Wenn Sie eine langfristige Strategie haben, schadet es nicht, die gesamte Strategie für Identitäten gegen die favorisierten Hersteller zu verproben - unabhängig davon, ob Sie später alles aus einer Hand nehmen oder unterschiedliche Hersteller bevorzugen.

Infrastruktur und Strategie

Neben den fachlichen Anforderungen ist ein IGA-Projekt vielen Rahmenbedingungen unterworfen, in die man sich einfügen muss.

Heute ist eine der wichtigsten Randbedingungen, wie die Cloud-Strategie eines Unternehmens aussieht beziehungsweise in absehbarer Zukunft aussehen soll. Planen Sie weiterhin Ihre Infrastruktur On-Prem aufzubauen oder gilt für Sie eine Cloud First-Strategie und wenn ja, in welcher Ausprägung? Setzten Sie auf SaaS Lösungen oder planen Sie “nur” eine Bereitstellung/ein Deployment in der Cloud?

Je nachdem welche Strategie sie verfolgen, kommen nicht mehr alle Hersteller in Frage. Insbesondere, wenn sie On-Prem starten und später auf Cloud wechseln wollen, stellt sich die Frage, wie einfach sich das gestaltet und ob On-Prem und SaaS identische Produkte sind.

Wenn das Deployment-Thema geklärt ist, geht es an die einzelnen Quell- und Zielsysteme. Auch hier hat das Deployment einen Einfluss, da auch bei einem SaaS und Cloud Deployment geklärt sein muss, wie das IGA-System an On-Prem Systeme kommt.

Lassen Sie uns über die Quellen für Identitäten sprechen. Quellen für Identitäten gibt es oft mehrere. Zum einen können mehrere HR-Systeme existieren, aber es werden auch unterschiedliche Systeme für interne Mitarbeiter und Externe/Partner etc. verwende. Bisweilen soll der Lebenszyklus für einige Identitäten direkt im IGA-System abgebildet werden. Beschäftigen Sie sich zeitig mit den HR-Prozessen, um zu verstehen, wie und wann Mitarbeiter in die HR-Systeme kommen. Manchmal gibt es interessante Konstellationen in unterschiedlichen Ländern, und Mitarbeiter kommen aus IGA-Sicht viel zu spät in die HR-Systeme. Es gilt zu klären, ob alle Daten, die für die IGA-Prozesse benötigt werden, wirklich in allen Quellen verfügbar sind. Und in einigen Fällen muss man zunächst herausbekommen, welche Quellen es überhaupt gibt.

Für die Zielsysteme sollte man zunächst einige grundlegende Dinge klären: Welche Systeme müssen integriert werden? Wie sieht die Kritikalität der Systeme aus und in welcher Reihenfolge muss integriert werden? Wie viele Daten sind in den einzelnen Systemen enthalten und wie tief muss eine Integration in die Zielsysteme sein? Man sollte sich von dem Gedanken verabschieden, alle Zielsysteme schnell anzubinden. Denn in der Regel hat jedes System andere Spezialitäten und die Qualität der Daten muss ebenfalls individuell geprüft und gegebenenfalls verbessert werden.

Wenn man die Liste der Zielsysteme betrachtet und sich insbesondere bei geringen Mengengerüsten oder fehlender API die Frage stellt, wie der Aufwand im Verhältnis zum Nutzen steht, sei darauf verwiesen, dass auch eine manuelle Integration Sinn machen kann (z.B. das Erzeugen von Tickets anstelle einer technischen Integration). So sind die Daten im IGA-System sichtbar und können in Governance-Prozesse eingebunden werden.

Wir hatten bisher Personen und deren Identitäten betrachtet. Aber im Kontext von Zielsystemen sind nicht alle Konten direkt einer Person zugehörig. Welche Arten von Konten/Identitäten wollen Sie verwalten? Im ersten Moment hat man naturgemäß Mitarbeitende, Externe und Partner im Blick. Aber es gibt auch Service-Konten, Konten von Maschinen/Robots etc. - wollen Sie diese einbeziehen und haben die entsprechenden Prozesse und Verantwortlichkeiten ebenfalls geklärt?

Die Qual der Wahl – Ihr IGA-Produkt

Wenn Sie einen formalen Prozess zur Auswahl eines IGA-Produktes starten, ist das aus unserer Erfahrung der spätmöglichste Zeitpunkt, zu dem alle potentiell beteiligten Organisationsteile und Personen eingebunden werden sollten. Die Einbindung der Verantwortlichen und Experten kann temporär erfolgen. Dann, wenn deren Expertise und Entscheidungsfindung erforderlich ist. Das sind zum Beispiel HR-Prozesse, die ohne Beteiligung der Personalabteilung nicht bewertet und/oder entschieden werden können. Sie werden auch kaum über eine Anbindung von SAP-Systemen diskutieren oder entscheiden können, ohne die Bedürfnisse der SAP-Verantwortlichen zu berücksichtigen.

Die Vorgehensweisen sind aber je nach Unternehmen sehr unterschiedlich, so dass sich unseres Erachtens diesbezüglich keine Best Practice herauskristallisiert hat – es muss für Sie und Ihr Unternehmen passen. Falls Sie jemanden vergessen oder ignoriert haben, führt das häufig zu Verzögerungen, und man muss zusätzliche Überzeugungsarbeit leisten. Es hat sich gezeigt, dass z.B. den Betriebsrat zu vergessen, keine gute Idee ist.

Die Entscheidung für ein IGA-Projekt treffen Sie für viele Jahre, wenn nicht sogar Jahrzehnte. Entsprechend aufwändig gestaltet sich das Auswahlverfahren. Ein IGA-Produkt ist kein IT-Tool, das beliebig ausgetauscht wird, sondern hat Auswirkungen auf zahlreiche Abteilungen und Prozesse. Am Ende des Tages ist es für alle von Interesse, dass Sie das richtige Produkt finden und das Projekt erfolgreich ist.

Die Produktauswahl geht mit einigem Aufwand einher. Daher ist es sinnvoll, sich Kriterien zu überlegen, um die Anzahl der Produkte einzuschränken, die man sich im Detail ansehen will.

Request for Information (RfI) und Request for Proposal (RfP) - Wissen was wichtig ist

RfI (Request for Information) und RfP (Request for Proposal) sind wunderbare Mittel, um gezielt Informationen zu Anforderungen zu bekommen. Allerdings nur dann, wenn die Fragen tatsächlich gezielt erstellt und abgestimmt sind.

Nehmen wir zum Beispiel das Thema Deployment. Es macht einen immensen Unterschied, ob sie eine On-Prem-Lösung favorisieren oder eine SaaS-Lösung bevorzugen. Bei einer SaaS-Lösung werden viele rechtliche Themen, das Data Processing und die Wiederanlaufzeiten etc. einen Schwerpunkt bilden. Das ist bei On-Prem nicht notwendig, weil Sie die Lösung selbst betreiben oder sie in Ihrem Auftrag betrieben wird. Das ist eines von vielen Beispielen.

Als Hersteller, der einige RfIs/RfPs sieht, stellt man sich bisweilen die Frage: Warum macht sich das ausschreibende Unternehmen die Mühe, investiert Zeit und Geld? Insbesondere dann, wenn offensichtlich ist, dass die Fragen nicht konkret auf die individuellen Bedürfnisse zugeschnitten sind. Oder noch schlimmer, man genau diese Fragen im Wortlaut wiedererkennt, weil sie aus der Schublade eines Beraters stammen. Das hilft niemanden, denn anhand dessen ist es kaum möglich, zu bewerten, wie gut ein Produkt die gewünschten Anforderungen abdeckt. Darüber hinaus ist es auch dem Hersteller verwehrt, ein Bild zu entwickeln, wie er die Anforderungen ideal erfüllen kann. Weil er sie nicht kennt. Fehlinterpretationen sind vorprogrammiert.

Ein RfI/RfP sollte sowohl die fachlichen als auch die infrastrukturellen Anforderungen gewichtet abbilden. Machen Sie deutlich, was Sie brauchen und was Sie gerne hätten. Werden Sie so konkret wie möglich. Dann sind auch die Antworten entsprechend und klären die Details, die sie benötigen.

Der erste Termin mit dem Hersteller – Für den ersten Eindruck gibt es keine zweite Chance

Ob die ersten Termine mit einem Hersteller bereits vor einem RfI/RfP-Prozess stattfinden wird unterschiedlich gehandhabt. Um die Möglichkeiten eines Produktes zu bewerten, muss man sich das Produkt im Kontext der eigenen Anforderungen ansehen. IGA-Produkte können meist viel mehr als man in den ersten Jahren des Einsatzes nutzen wird oder was man während eines ersten Termins zeigen kann. Erläutern Sie den Herstellern, die Herausforderungen, vor denen Sie stehen und die Anforderungen bereits vor einem Termin (und ohne vorherigen RfI/RfP). So stellen sicher, dass Sie richtig verstanden werden und ein Treffen zielführend ist.

Haben Sie bereits einen validen RfI/RfP durchgeführt, ist es gut möglich, dass es nicht mehr nötig ist, konkrete Anforderungen an den ersten Termin zu formulieren.

Beim ersten Termin sollte es dem Hersteller möglich sein, potenzielle Referenzen für Sie auszumachen. Es hat sich gezeigt, dass Größe, Branche, aber auch konkrete Anforderungen wichtig sind, um die passenden Gesprächspartner bei existierenden Kunden zu identifizieren.

Proof of Concept (PoC) - Live und in Farbe

Hoffentlich hat man die Anzahl der IGA-Anbieter jetzt auf eine überschaubare Zahl reduziert. PoCs sind anstrengend und ressourcenintensiv – das gilt für den Anbieter und umso mehr für das betreffende Unternehmen, je nachdem wie viele Anbieter Sie im PoC betrachten.

Jetzt gilt es, die aus Ihrer Sicht kritischen Punkte zu beleuchten und zu verifizieren. Die ausgewählten Anwendungsfälle sollten Ihre kritischen Anforderungen und Integrationen betrachten. Viele dieser Anforderungen sollten Sie im Idealfall bereits in den Demonstrationen gesehen haben.

Bedenken Sie, dass für einen PoC ausreichend Vorbereitungszeit zur Verfügung stehen sollte. Sie müssen Anwendungsfälle und Daten erklären sowie eine entsprechende Testumgebung mit Daten bereitstellen. Gleichzeitig sollten Sie intern sicherstellen, dass all jene Mitarbeiter während eines PoCs anwesend sind, die beispielsweise den Zugriff auf zu integrierende Systeme gewährleisten können. Informieren Sie die Hersteller rechtzeitig, was Sie für den PoC planen und vor allem, in welchem Zeitrahmen er stattfinden soll. Nicht jeder Mitarbeiter des Herstellers kennt sich z.B. mit allen Zielsystemen aus (es gibt doch leichte Unterschiede zwischen Azure AD, RACF und SAP...). Auf Seiten des Unternehmens wie auf Seiten des Anbieters muss das passende PoC-Team zusammengestellt werden.

Aus unserer Sicht macht es Sinn sich alles anzusehen: Von der Installation bis zur Konfiguration und der Integration des Produktes. Es hat sich bewährt, die Einrichtung über einen Projektor/großen Monitor zu verfolgen. Sie können dann direkt Fragen stellen und sich alles erklären lassen. Sie sehen, wie ein Produkt konfiguriert wird, was ist der Standard, wo sind Anpassungen oder Programmierung notwendig. Auf jeden Fall sollten Sie darauf achten, keine vorgefertigten Implementierungen Ihrer Anwendungsfälle zu bekommen. Dann könnten Funktionen enthalten sein, die beispielsweise nicht zum standardisierten Umfang des Produktes gehören. Ein PoC sollte „Live und in Farbe“ ablaufen.

Am Ende sollten Sie ein Gefühl dafür bekommen haben, wie viele der jeweiligen Anforderungen im Standard vorhanden sind, wie flexibel ein Anbieter auf Änderungen reagieren kann und was an Erweiterungen möglich ist.

Jetzt müssen Sie nur noch eine Entscheidung treffen...

Zusammenfassung

Natürlich ist uns bewusst, dass es einigermaßen schwierig ist, alle Erfordernisse vorab zu klären und zu definieren. Zumindest ein grobes Gerüst sollte aber vorhanden sein. Manches wird erst später im Laufe des Projektes auftauchen oder sich erst dann klären lassen. Aber je besser man vorbereitet ist, je mehr man weiß und mitteilt, desto besser kann man starten. Wir hoffen, dass wir Ihnen einen interessanten Blickwinkel auf eine mögliche Produktfindung für Ihr IGA-Projekt geben konnten.

Über die Autoren:

Susanne Haase ist Spezialistin für Implementierung und die Architektur für Identity- und Access- Management-Lösungen. In ihrer aktuellen Position bei One Identity unterstützt sie Partner durch den Aufbau und die Umsetzung des Presales Partner Enablement Program.

Dr. Stephan Hausmann ist Software Sales Engineer für Identity und Access Management, EMEA, ebenfalls bei One Identity.

(ID:49642808)