In den letzten beiden Artikeln zum Thema „Agiles Schätzen und Planen“ wurden bereits vorgestellt, wie es möglich ist, einen Sprint so zu planen, daß man sich möglichst immer die optimale Menge an User Stories vornimmt (nicht zu viel, aber auch nicht zu wenig).

Diese Planung wird alleine durch das Team durchgeführt (plus den Scrum Master). Eine Einflussnahme von aussen ist nicht vorgesehen, nicht einmal durch den Product Owner.

Das Team soll sich nämlich die zu erledigende Arbeit für den Sprint möglichst selbst auswählen, muss sich diesem „Sprint-Ziel“ dann aber auch verschreiben und darf auch nur noch in Ausnahmefällen davon abrücken. Auf diese Weise soll sich das Team stärker mit den Zielen identifizieren als wenn sie diese von aussen zugewiesen bekämen. Übrigens ein Ansatz, der tatsächlich funktioniert, wie unsere Erfahrungen hier eindeutig zeigen.

Natürlich möchte man aber auch dem Product Owner einen (berechtigten) Einfluss auf die Sprint-Ziele zugestehen. Wie löst man nun diese scheinbare Konfliktsituation?

Eigentlich ganz einfach:

Der Product Owner nimmt mit an der Sprintplanung teil.

Eigentlich ist dies sowieso notwendig, da nur der Product Owner dem Team den Sinn und Zweck einzelner Einträge des Product Backlogs erklären kann. Ein gutes Verständnis der Einträge ist aber wiederum unabdingbare Voraussetzung für eine gute Schätzung.

Kommt man nun gegen Ende der Planung an den Punkt, an dem das Team sich die Einträge für den neuen Sprint aussucht, so geschieht dies ja anhand der Einträge des Product Backlogs (das ja nach Geschäftswert sortiert ist). Die Sortierung aktuell zu halten gehört mit zu den wichtigsten Aufgaben des Product Owners.

Hat das Team die Liste der Features fertig erstellt, so wird sie noch einmal dem Product Owner vorgelegt, um sein Einverständnis zu erhalten. Normalerweise wird man es auch erhalten. Sollte dies aber wieder Erwarten nicht der Fall sein, so bleiben ihm noch drei Möglichkeiten der Einflussnahme:

• Er sortiert die Einträge des Product Backlog neu. Dies sollte eigentlich nur in Ausnahmefällen notwendig sein, zumindest wenn er es mit seiner Aufgabe genau nimmt, und das Product Backlog konstant aktuell hält,
• Er reduziert den Umfang eines Eintrags, um ihn so doch noch mit in den aktuellen Sprint aufnehmen zu können
• Er splittet den Eintrag auf. Der erste (dringendere) Teil wird sofort realisiert, der Rest auf einen späteren Sprint verschoben.

Somit wird die Kontrolle darüber, was in einem Sprint realisiert wird, zu gleichen Teilen auf Team und Product Owner verteilt:

Auf das Team, weil es alleine entscheidet, wieviele Story Points im Sprint umgesetzt werden können, und zudem noch die Einträge des Product Backlogs mit Story Points beschätzt.

Und auf den Product Owner, da er dem Team eine verbindliche Reihenfolge vorgibt, in der die Einträge des Product Backlogs realisiert werden müssen, und dieses bis zum Ende der Sprintplanung noch ändern kann.

Spielen alle Beteiligten ehrlich und aufrichtig zusammen, so schafft man so eine fast optimale Auslastung des Teams.

Darüber hinaus behält man auch immer den „Business Case“ (man verzeihe mir dieses Wort) im Auge, da der Product Owner, der ja derjenige mit der „Vision“ ist, immer dafür sorgt, die richtigen Anforderungen zur richtigen Zeit zu realisieren.

Die Sprintplanung ist also nun komplett, es kann also losgehen mit der Realisierung :). Bis zu Beginn des nächsten Sprints die nächste Planung ansteht…

BFI

Wie bereits im letzten Artikel erwähnt ist eine saubere Planung ein wesentlicher Garant für einen erfolgreichen Sprint. Mit den vorgestellten Methoden sollte man relativ einfach einen Umfang an Story Points errechnen können, den man in einem Sprint leisten kann.

Damit dies funktioniert, müssen natürlich zuerst alle Einträge des Product Backlogs beschätzt werden, um für jeden Eintrag einen Aufwand zu erhalten, mit dem man dann weiter planen kann.

Es gibt viele Möglichkeiten, Arbeitspakete zu schätzen.

Die einfachste Methode ist dabei ganz einfach, eine User Story dem Team zur Diskussion zu stellen und so lange zu warten, bis sich auf eine Zahl geeinigt haben. Dies wird in Fällen auch tatsächlich so gehandhabt, hat allerdings einen gravierenden Nachteil:

Im Laufe der Zeit hat sich nämlich gezeigt, daß die Diskussion üblicherweise so abläuft, daß ein Teammitglied, welches die Story gut versteht (oder zumindes denkt, dies zu tun) mit einer schnellen Schätzung rausplatzt. Dies führt dann jedoch dazu, daß andere Teammitglieder, die sich ihrer Sache nicht ganz so sicher sind, in ihrer Schätzung beeinflusst werden könnten (und wenn es nur unterbewusst ist).

In der Fachsprache nennt man dies „Anchoring“. Man sollte es wenn möglich vermeiden.

Eine einfache Methode, die dies tut, und die bei Scrum immer gerne eingesetzt wird, ist „Planning Poker“.

Sie besticht vor allem dadurch, daß sie leicht zu erlernen und relativ schnell in der Durchführung ist, dabei aber trotzdem genügend genaue Ergebnisse liefert.

Sie funktioniert wie folgt:

Zu Beginn erhält jeder Teilnehmer einen Satz Pokerkarten (ideal ist es übrigens, wenn das ganze Team teilnimmt). Ein Satz besteht aus 13 Karten mit den aufgedruckten Werten 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, [Kaffetasse] .

Wenn nun eine neue User Story beschätzt werden soll, so wird nun wie bisher so lange im Team diskutiert, bis alle soweit verstanden haben, worum es geht. In der Diskussion sind übrigens ausschliesslich sachbezogene Beiträge erlaubt. Statements mit vorauseilenden Wertungen („das ist ja einfach“) sind strikt verboten und werden mit einem nicht zu geringen Beitrag in die Kaffekasse bestraft :).

Nach Abschluss der Diskussion geht es dann an die Schätzung: Jeder Teilnehmer nimmt dann aus seinem Kartensatz diejenige Karte, von der er meint, daß sie dem Aufwand der zu schätzenden User Story (in Story Points) entspricht, und legt sie verdeckt (!) vor sich auf den Tisch.

Erst wenn auch der Letzte seine Karte Schätzung abgegeben hat werden alle Karten gleichzeitig umgedreht.

Auf diese Weise stellt man sicher, dass sich jeder seine eigenen Gedanken machen muss, und sich nicht an einem seiner Kollegen orientieren kann.

Ihnen ist vielleicht schon aufgefallen, daß die auf den Karten aufgedruckten Zahlen nicht ganz linear sind, sondern vor allem bei den höheren Zahlen größere Lücken aufweisen. Dies geschieht ganz bewusst: Auf diese Weise soll verhindert werden, daß größere Arbeitspakete mit einem falschen Sinn für Genauigkeit beschätzt werden. Je höher, je ungenauer. Aus diesem Grund ist es übrigens auch nicht erlaubt, mehr als eine Karte für eine Schätzung auszuwählen. 40+20 = 60 ist somit also nicht erlaubt. Man muss sich schon für einen Wert entscheiden.

Möchte man genauere Schätzungen erhalten, so sollte man die Story noch weiter aufteilen, und dann die einzelnen Teile beschätzen.

Der Kartensatz enthält übrigens 3 Jokerkarten: „0“, „?“ und „[Kaffeetasse]“.

• „0“ bedeutet „dieses Feature ist bereits implementiert oder nur eine Sache von wenigen Minuten.
• „?“ heisst: „Ich habe nicht mal ansatzweise eine Ahnung, worum es hier eigentlich geht“
• Kaffeetasse: „Mir langt’s erstmal. Machen wir eine kurze Pause.“

Nun decken alle „Mitspieler“ ihre Karten auf und vergleichen ihre Schätzungen. Weichen zwei der Werte stark voneinander ab, so wird dieser Umstand nochmal diskutiert und anschließend die Schätzung wiederholt. Dies geschieht so lange, bis alle Beteiligten in etwa denselben Wert schätzen.

Ob man nun den Mittelwert aller Karten nimmt, den höchsten und niedrigsten Wert ausser Acht läßt und den verbleibenden Rest mittelt, den Wert der mittleren Karte nimmt oder eine andere Metrik verwendet um auf den abschließenden Schätzwert zu kommen ist dabei jedem Team selbst überlassen. Im Laufe der Zeit wird man hier sicherlich etwas finden, womit alle Beteiligten einverstanden sind.

Nun sind wir mit der Schätzung dieses Features fertig. Diesen Vorgang müssen wir jetzt auch noch mit allen anderen Einträgen des Product Backlog machen, die für den aktuellen Sprint in Frage kommen.

Zusammen mit der im letzten Artikel vorgestellten Abschätzung des maximal in diesem Sprint zu leistenden Arbeitsumfangs ist es nun auch möglich, die zu realisierenden Features auszuwählen: Man beginnt am oberen Ende der Liste (die ja nach Geschäftswert sortiert ist) und übernimmt die entsprechende Anzahl an Einträgen ins „Sprint Backlog“. So nennt man die für die Realisierung in einem Sprint ausgewählten User Stories.

Einmal erstellt, soll das Sprint Backlog übrigens nur noch in absoluten Ausnahmefällen geändert werden, etwa wenn sich abzeichnet, daß man sich zu viel oder zu wenig vorgenommen hat.

Das Sprint Backlog wird ausschliesslich durch das Team erstellt. Der Product Owner darf keinen direkten Einfluss darauf nehmen.

Er verfügt aber über mehrere indirekte Möglichkeiten der Einflussnahme. Welche dies sind ?

Diese Frage wird im nächsten Artikel beantwortet….

BFI

In unseren Erfahrungen mit Scrum hat sich in der Vergangenheit immer wieder gezeigt, dass eine sorgfältige Sprint-Planung mit das Wichtigste Artefakt in Scrum ist. Sie entscheidet darüber, ob der anschließende Iterationszyklus das gewünschte Ergebnis liefert, oder aber in einem kompletten Chaos endet. Letzeres soll natürlich vermieden werden, wenn es irgendwie geht. Doch wie stellt man das am besten an?

Als Beispiel für eine funktionierende Sprintplanung möchte ich hier die Methode vorstellen, die Henrik Kniberg in seinem sehr empfehlenswerten Buch „Scrum and XP from the trenches“ gibt.

Grundlage für eine erfolgreiche Sprint-Planung ist ein einigermaßen sauber geführtes Product Backlog. Mit „einigermaßen sauber” meine ich hier:

• Es sollte existieren,
• auf dem aktuellen Stand sein, und
• die einzelnen Einträge sollten nach Geschäftswert priorisiert sein.

Ideal wäre außerdem noch, wenn es zu jedem Eintrag noch ein definiertes Abnahmekriterium gäbe („How to demo”), da sich so im Vorfeld bereits einige Missverständnisse ausräumen lassen (etwa über den Umfang des Eintrags). Dies alles liegt natürlich in der Verantwortlichkeit des Product Owners. Es ist daher unbedingt erforderlich, dass dieser seine Aufgabe auch ernst nimmt!

Sind diese Voraussetzungen erfüllt, so kann die eigentliche Planung beginnen. Hierfür sollte man sich genügend Zeit nehmen. Mein Vorschlag ist, sich pro Woche, die der anschließende Sprint dauert, in etwa 1 Stunde Zeit zu nehmen. Bei einem 4-wöchigen Zyklus wären das also 4 Stunden. Hört sich zwar lange an (das ganze Team einen halben Tag in Beschlag zu nehmen), ist aber jede investierte Minute wert!

Am Ende sollte man folgendes erreicht haben:

• Man hat ein Ziel für den Sprint festgelegt,
• ein Sprint Backlog erstellt,
• Termine für Sprint Review und das tägliche Statusmeeting ausgemacht, sowie
• eine Liste der Teammitglieder samt ihrer Verfügbarkeit.

Zuerst sollte man sich Gedanken darüber machen, welche Einträge aus dem Product Backlog man für den neuen Sprint übernimmt. Da diese Einträge nach Geschäftswert priorisiert sind ist dieser Schritt zunächst einmal relativ leicht:

Man beginnt am oberen Ende der Liste und übernimmt einfach so viele Einträge, wie man meint innerhalb einer Iteration realisieren zu können. Wieviele Einträge dies sind? Dazu schätzt man den Aufwand der ausgewählten Einträge und gleicht den ermittelten Wert dann mit den Erfahrungswerten aus vorangegangenen Iterationszyklen ab. Diese Technik wird „yesterday’s weather” genannt.

Natürlich steht ein solcher Erfahrungswert nicht immer zur Verfügung. Sollte dies der Fall sein, so kann man auch eine einfache Art der Ressourcenkalkulation verwenden. Basis hierfür bildet die Zahl der verfügbaren Manntage im Sprint. Bei einem 4-wöchigen Sprint in einem Team von 5 Leuten könnte eine solche Planung dann etwa wie folgt aussehen:

• Adam: 20 Manntage
• Bertram: 18 Manntage (hat 2 Urlaubstage genommen)
• Cäsar: 20 Manntage
• Dora: 10 Manntage (steht nur zu 50% zur Verfügung)
• Egbert: 20 Manntage

Insgesamt stehen für den Sprint also 88 Manntage zur Verfügung. Kann man nun also in diesem Sprint also nun Einträge im Wert von 88 Story Points realisieren? Nein, da die Einheit für Story Points aus „idealen Manntagen” besteht. Ein solcher idealer Manntag ist ein Tag, an dem eine Person die ganze Zeit über produktiv arbeitet, ohne jegliche Art von Pausen, Störungen oder Krankheit. Dies kommt in der Realität natürlich nicht allzu häufig vor. Der tatsächliche Wert wird daher etwas unter diesem Idealwert liegen. Diesen Unterschied zwischen idealem und realem Wert nennt man auch den „Fokusfaktor”.

Die Anzahl der in einem Sprint erreichbaren Story Points ist also [Zahl der Manntage] x [Fokusfaktor]. Den Fokusfaktor kann man z.B. aus vorangegangenen Sprints berechnen (über die Formel: Fokusfaktor = [realisierte Story Points] / [ Gesamtzahl Manntage]). Besser noch ist es natürlich, einen Mittelwert über mehrere Sprints zu verwenden.

Angenommen, im letzten Sprint wurden bei 90 zur Verfügung stehenden Manntagen Stories im Wert von 60 Story Points realisiert, so errechnet sich daraus ein Fokusfaktor von 60/90 = 0,66.

Für den neuen Sprint würde das dann bedeuten, dass wir damit planen können, insgesamt Einträge in der Höhe von 88 * 0,66 = 58 Story Points umzusetzen.

Was aber, wenn noch kein solcher Fokusfaktor existiert? Hier könnte man versuchen, ins Unternehmen zu schauen und ein Team zum Vorbild zu nehmen, das unter vergleichbaren Umständen arbeitet, oder aber (falls auch das nicht möglich ist) einfach einen Faktor zu schätzen. Dies hört sich im ersten Moment zwar etwas unprofessionell an, ist aber vertretbar, da dieser Fall eh nur im ersten Sprint eines neuen Projekts auftreten kann. Bereits ab dem zweiten Sprint kann man wieder echte Daten verwenden. In der Literatur (Link einfügen: „Scrum and XP from the trenches”) findet sich hier ein Wert von ~0,7, was auch in etwa unseren Erfahrungen entspricht. Falls Sie sich also keinen Wert selbst ausdenken wollen, so können Sie gerne diesen verwenden.

Der Fokusfaktor eignet sich übrigens nicht nur zum Planen eines neuen Sprints. Da er ja die Differenz zwischen idealen und tatsächlichen Manntagen darstellt, beinhaltet er somit auch alle Umweltfaktoren. Dies kann auch als Druckmittel bei Verhandlungen mit dem Product Owner dienen, wenn es etwa darum geht, Probleme zu beseitigen, die das Team in seiner täglichen Arbeit behindern. Man denke hier nur an eine im Hochsommer ausfallende Klimaanlage oder an häufig auftretende Netzwerkprobleme. Beides würde sich in einer Verringerung des Fokusfaktors niederschlagen, und somit einen direkten negativen Einfluss auf den Projekterfolg haben. Eine Beseitigung dieser Probleme hätte jedoch wieder eine Erhöhung des Fokusfaktors zur Folge, und damit auch eine Erhöhung der realisierbaren Story Points innerhalb eines Sprints.

Am Ende dieses Abschnitts wissen wir nun also, wie viele Story Points wir in diesem Sprint realisieren können. Um nun jedoch zu einer tatsächlichen Liste von Funktionen zu kommen, müssen zuerst noch alle in Frage kommenden Einträge des Product Backlogs beschätzt werden. Die Methode, die wir in solchen Fällen immer einsetzen, nennt sich „Planning Poker”. Wie diese genau funktioniert, darüber mehr im nächsten Artikel.

BFE

Wenn man sich in der Scrum-Community heute so umhört, dann stellt man schnell fest, dass die meisten Personen aus der Ecke der Softwareentwicklung kommen. Also eher die Auftragnehmerseite. Die Auftraggeberseite ist jedoch zumeist so gut wie gar nicht vertreten. Doch warum ist das so? Sind agile Methoden für die Auftraggeber nicht attraktiv genug? Oder liegt es vielleicht eher daran, dass die betroffenen Entscheidungsträger noch nichts darüber gehört haben?

Unsere bisherige Erfahrung sagt uns, dass eher Letzteres der Fall ist, denn Scrum bietet dem Auftraggeber sehr wohl eine Reihe von Vorteilen (sie auch der letzte Artikel über „Scrum und Festpreisverträge”). Für alle, die keine Lust haben, diesen Artikel nachzulesen, seien die wichtigsten Punkte an dieser Stelle nochmal wiederholt:

• Dem Auftraggeber ist es erlaubt, bisher unbearbeitete Anforderungen durch Neue auszutauschen. Dadurch erspart man sich teure Change Requests (betrifft v.a. Festpreisverträge)
• Da Software bei Scrum iterativ entwickelt wird, ist es möglich, am Ende jeder Iteration steuernd auf das Projekt einzuwirken (üblich sind hier 4 Wochen). So kann man zu jeder Zeit die Kontrolle darüber behalten, wie sich das Produkt weiterentwickelt.
• Ein iterativ entwickeltes System kann natürlich auch leicht schrittweise ausgerollt werden. Ein Big-Bang ist nicht notwendig. Das verringert das damit verbundene Risiko erheblich, hat aber auch andere Vorteile, z.B. geringere Kosten für Mitarbeiterschulungen.
• Es ist möglich, ein Projekt vorzeitig abzubrechen und dennoch ein lauffähiges System zu bekommen. Dies kann z.B. bei Budgetkürzungen der Fall sein, aber auch, wenn der erreichte Entwicklungsstand gut genug ist. So kann man sogar erreichen, das gewünschte Produkt für weniger Geld als vorgesehen zu bekommen - wann gab es das schon mal?

Darüber hinaus fallen mir aber auch noch eine Reihe weiterer Vorteile ein:

• Man erhält sehr schnell lauffähige Software, auch wenn diese noch nicht den gesamten Funktionsumfang aufweist. Dieser wird jedoch Schritt für Schritt mit jeder Iteration steigen.
• Die Abnahme (und damit auch Bezahlung) kann somit immer anhand ausgelieferter Funktionalität erfolgen. Aufwendige Abnahmetests sind nicht mehr nötig.
• Es müssen bei Projektstart noch nicht alle Anforderungen an das Produkt bekannt sein. Stattdessen kann man sich Schritt für Schritt vorarbeiten und muss sich erst dann festlegen, wenn die Entwicklung an diesem Punkt angelangt ist.

Diese Liste erhebt natürlich keinen Anspruch auf Vollständigkeit und kann sicherlich noch erweitert werden (Vorschläge hierzu am besten einfach per Kommentar). Wenn also so viele Gründe dafür sprechen, warum fordern Auftraggeber heute dann Agilität nicht noch viel vehementer ein als bisher? Auch hierfür fällt mir einiges ein:

• Die bei Agilität übliche konstante Mitarbeit des Auftraggebers stellt an diesen höhere Anforderungen als bisher. Neben dem damit verbundenen höheren (Zeit-) Aufwand denke ich hier v.a. an Entscheidungskompetenzen, da vom Auftraggeber verlangt wird, verbindliche Entscheidungen in relativ kurzer Zeit zu treffen. Nicht jede Organisation kann das jedoch leisten.
• Die Entscheider haben keine IT-Kultur. Sie begreifen das Problem der Software-Entwicklung nicht. Gerade bei fachfremden Entscheidern scheint sich bis heute hartnäckig der Eindruck zu halten, dass Software einfach zu spezifizieren und trivial zu programmieren wäre, ohne größeres Risiko. Dass gerade bei Individualsoftware (um die es hier ja geht), in der überwiegenden Mehrheit der Fälle jedoch eher das genaue Gegenteil der Fall ist, scheint sich dagegen bisher noch nicht sehr weit rumgesprochen zu halten.
• Gerade bei größeren Unternehmen treten oft auch organisatorische Zwänge auf. Verträge mit auf Agilität ausgelegten Klauseln (wie im Artikel „Scrum und Festpreisverträge” vorgeschlagen) sind oft einfach nicht vorgesehen. Sie zu installieren, wäre jedoch für ein einzelnes Projekt ein zu aufwendiger Prozess, der ewig dauert, und dessen Ausgang ungewiss ist. Also lässt man es lieber.

Und schließlich natürlich noch der trivialste, aber meiner Meinung nach zugleich auch der wichtigste Grund:

• Scrum ist in vielen Unternehmen einfach noch unbekannt. Es sollte daher unsere Aufgabe sein, dies zu ändern und das Wort hinaus in die Welt zu tragen. Vielleicht schaffen wir es, dass Scrum mal in der Tagesschau kommt :-).

Andererseits: Vielleicht sind hier auch wir als Auftragnehmer mehr gefordert unseren Kunden „ein Angebot zu machen, das sie nicht ablehnen können”. Hier greife ich gerne die Idee meines Kollegen Olivier Guillet auf, der vorschlägt, Angebote auf zwei verschiedene Weisen zu kalkulieren und dem Kunden selbst die Entscheidung zu überlassen:

1. Agil, mit kürzerer Laufzeit, mit Flexibilität bei den Anforderungen, konstanter Mitarbeit des Kunden und einem auf Stundensätzen basierenden Vertrag, der aber im Normalfall zu einem geringeren Preis als bei Festpreisverträgen führt (auch wenn dieser Preis hier natürlich nicht garantiert werden kann)
2. Standard-Festpreis-Modell: Längere Laufzeit, geringere Involvierung des Kunden („Über-den-Zaun”-kompatibel), dafür mit einem garantierten Festpreis, aber teurer als Variante 1.

Und selbst wenn ein Kunde dann immer noch einen Standard-Festpreis-Vertrag verlangt, so kann man ihm die angesprochenen Modifikationen vorschlagen, um etwas Agilität in den Vertrag zu bringen. Die Chancen hierfür stehen nicht schlecht: Uns sind bereits erste Beispiele für Unternehmen bekannt, die speziell an Scrum angepasste Verträge eingeführt haben, und dies sogar aktiv von ihren Auftragnehmern einfordern. Da der erreichte Effizienzgewinn für sich spricht, ist es wohl nur noch eine Frage der Zeit, bis Agilität zum Standard wird.

Mir wäre es jedenfalls recht…

BFE

Wie von Alexander Maisch schon im Artikel über den Nokiatest erwähnt gibt es bei InterFace in loser Regelmäßigkeit alle 2 Wochen ein Treffen aller am Thema Scrum interessierten Kollegen: Die Scrum-Sprechstunde.

Eines der Themen, welches in letzter Zeit hier immer wieder mal Gegenstand der Diskussion war, ist das Thema Scrum und Festpreisverträge.

Bevor wir hier jedoch eine konkrete Empfehlung abgeben, wie man diese zwei scheinbaren Gegensätze zusammenbringen kann, möchten wir jedoch die Gelegenheit nutzen, etwas zu Festpreisverträgen an sich zu schreiben.

Festpreisverträge sind etwas, was in den letzten Jahren immer mehr üblich wurde, und in manchen Bereichen mittlerweile eher die Regel als die Ausnahme sind. Doch warum ist das so?

Unserer Ansicht nach liegt der Grund hier vor allem im Wunsch des Auftraggebers, das mit dem Projekt verbundene Risiko vermeintlich auf den Auftragnehmer zu übertragen.

Die Nachfrage nach einem Festpreisprojekt ist daher auch immer ein Stück weit mit der unterschwelligen Aussage verbunden “eigentlich denken wir, das Projekt scheitert eh, deswegen sichern wir uns lieber schon mal dagegen ab”. Ein ideales Softwareprojekt sollte daher immer mit einem auf Stundensätzen basierenden Vertrag abgewickelt werden, da das bereits im Vorfeld ein größeres Vertrauen an den Auftragnehmer signalisiert und so eine gemeinsame Vertrauensbasis für eine erfolgreiche Projektabwicklung geschaffen wird.

Ein solches Idealbild existiert in der Realität jedoch leider nicht immer. Früher oder später wird wohl jede Organisation, egal ob sie nun mit Scrum arbeitet oder nicht, mit Festpreisprojekten konfrontiert werden. Es existieren jedoch verschiedene Möglichkeiten, mit dieser Situation umzugehen. Wir haben eine Reihe dieser Möglichkeiten an dieser Stelle mal zusammengefasst:

Bei Festpreisprojekten wird vom Kunden üblicherweise ja ein „Über-den-Zaun“-Vorgehen erwartet (d.h., man wirft eine Spezifikation über den bildlichen Zaun und hofft, dass das erwartete Produkt zurückgeworfen wird).

Bei agilen Methoden ist das jedoch ein wenig anders: Hier wird auf die konstante Mitarbeit des Kunden während des gesamten Projektverlaufs gesetzt. Um hierfür einen Anreiz zu schaffen könnte man einen Festpreisvertrag mit ein paar zusätzlichen Modifikationen jedoch mit etwas mehr Agilität versehen (siehe auch das Scrum-FAQ von Ken Schwaber:

• Jede Anforderung, die noch nicht bearbeitet wurde, darf vom Auftraggeber jederzeit durch eine andere Anforderung von gleichem Wert ersetzt werden (auch eine Neue!).
• Alle Anforderungen, die noch nicht bearbeitet wurden, dürfen vom Auftraggeber jederzeit umpriorisiert werden.
• Der Kunde kann die vorzeitige Auslieferung eines geplanten Software-Inkrements verlangen. Sollten hierbei jedoch zusätzliche Kosten anfallen, so werden diese gesondert in Rechnung gestellt.
• Sollte der Kunde mit dem Produkt bereits zufrieden sein, bevor alle Anforderungen abgearbeitet wurden, so wird ihm die Möglichkeit eingeräumt, das Projekt schon zu einem früheren Zeitpunkt zu beenden. Es wird dann zwar eine (vorher vereinbarte) Konventionalstrafe fällig, diese fällt jedoch nicht allzu hoch aus.

Diese (auf den ersten Blick unscheinbaren) Änderungen verbessern die Situation des Kunden in einigen Punkten wesentlich.

Schon die erste Änderung bringt einen riesen Vorteil: Da es hier erlaubt ist, bisherige Anforderungen auch durch komplett Neue zu ersetzen eliminiert man auch die bisherige Praxis mit nachträglichen Change Requests (denn gerade damit können Auftragnehmer bisher gutes Geld verdienen). Übrigens leistet man so auch einen wertvollen Beitrag gegen die heutzutage immer mehr grassierende „Featuritis“: Da bei traditionellen Festpreisverträgen nachträgliche Änderungen immer zusätzliches Geld kosten, werden zu Beginn oft alle Eventualitäten, und seien sie auch noch so unwahrscheinlich, mit Anforderungen abgedeckt. Das Resultat ist dann oftmals ein Produkt mit überbordender, aber selten gebrauchter oder zum Zeitpunkt der Fertigstellung sogar schon überholter Funktionalität.

Trägt man jedoch, wie hier, dem Umstand Rechnung, dass Anforderungen zu Beginn oft noch unklar sind, und sich im Laufe der Zeit zudem noch öfters mal ändern können, so ist die Wahrscheinlichkeit, ein zielgerichtet auf die Kundenwünsche entwickeltes Produkt zu erhalten wesentlich höher, auch wenn am Ende etwas ganz anderes herauskommt, als am Anfang gedacht war.

Dies wird noch weiter unterstützt durch die Möglichkeit, ein Projekt vorzeitig abzubrechen. Wenn dem Auftraggeber der erreichte Stand gut genug ist (bzw. das Budget plötzlich gekürzt wird) kann man das Projekt stoppen und trotzdem eine brauchbare Software-Lösung bekommen – und das ohne alle ursprünglich gedachten Features implementiert haben zu müssen.

Die dritte Klausel ermöglicht das schrittweise Ausrollen eines IT-Systems (also kein “Big-Bang”), was die Risiken des Projekts erheblich reduziert (wenn man die Anzahl an gescheiterten IT-Projekten bedenkt) und interessante Perspektiven eröffnet: Wenn das neue System schrittweise jeden Monat eingeführt wird, muss man nicht alle Mitarbeiter in teure Schulungen schicken: Sie können sich schrittweise mit dem neuen System vertraut machen.

Soweit die graue Theorie. Doch wie sieht es in der Praxis aus? Schlecht! Warum dies?

Mehr dazu im nächsten Artikel…

BFI

In der heutigen Zeit ist oftmals von der “Informationsflut” die Rede, die immer mehr über uns hereinbricht. War in früheren Zeiten Information noch ein knappes Gut, dessen größtes Problem die Beschaffung war (ihre Verwendung, sollte sie einmal in Besitz sein, jedoch klar), so hat sich diese Situation in unserer heutigen Informationsgesellschaft genau ins Gegenteil verkehrt:

Informationen sind überall, zu (fast) jedem beliebigen Thema, in großer Zahl und leicht erhältlich.
Nun ist es ist die Verarbeitung, die uns vor Probleme stellt. Dies ist auch dadurch bedingt, daß es heute i.d.R. eine Informationsmenge zu sichten gilt, die für Menschen nicht mehr überschaubar ist. Der Einsatz computergestützter Mittel ist daher oftmals der einzige Ausweg.

Dies bedeutet daher, mithilfe statistischer Methoden eine große Menge von zur Verfügung stehenden Informationen nach zusammenhängenden Strukturen zu durchsuchen (etwa nach Person, Sache oder Ereignis), und daraus automatisiert Wissen abzuleiten.
Eine solche zusammenhängende Struktur nennt man ein Profil. Je nachdem, ob das durch das Profil repräsentierte Subjekt eine Person oder eine Gruppe ist kann man zudem weiter verfeinern in persönliche Profile oder Gruppenprofile.

Profiling kann somit auch als “der Prozess der Erstellung oder Anwendung eines Profils einer Gruppe oder einer Person” bezeichnet werden (freie Übersetzung nach FIDIS ).

Profiling ist zudem mit einem Lernprozess verbunden. Die bloße Anwendung eines Satzes von Regeln ist nicht ausreichend. Deswegen sind aus Profiling gewonnene Erkenntnisse auch immer kritisch zu hinterfragen und sollten nicht automatisch als korrekt angesehen werden. Ihre Qualität ist außerdem auch abhängig von der Menge an Informationen, die zur Analyse zur Verfügung stehen: Je größer die zugrundeliegende Datenbasis, desto besser wird in der Regel auch das Ergebnis sein (auch wenn man das natürlich nicht garantieren kann).

Profiling ist in der heutigen Zeit sehr verbreitet. Beispiele hierfür findet man z.B. auf Shopping-Seiten (”Andere Kunden, die dieses Produkt gekauft haben, kauften auch dieses andere Produkt…”), bei Rabattsystemen, die Kunden im Austausch für persönliche Daten bestimmte Vergünstigungen anbieten (Beispiel “Payback”) oder auch bei Kreditkartenfirmen, die Profiling einsetzen, um möglichen Kartenmißbrauch aufzuspüren. Einige der neuen Dienste im Web nutzen Profiling sogar als zentralen Aspekt ihres Angebots, etwa der Musikdienst last.fm. Dieser bietet eine Art persönliche Radiostation an, die nur Titel spielen soll, die einem auch gefallen. Hierzu werden die musikalischen Vorlieben eines Benutzers anhand seiner in der Vergangenheit häufig gespielten Lieder ermittelt, um dann andere Benutzer zu finden, die über einen ähnlichen Musikgeschmack verfügen. Die Titel, die ihn deren persönlicher Abspielliste stehen werden dann auch für die eigene persönliche Radiostation übernommen.

Man kann sich nun leicht vorstellen, warum Profiling ein sehr sensibles Thema ist, und auch eine hohe datenschutzrechtliche Relevanz besitzt:

• Man arbeitet in der Regel mit einem sehr großen Satz an Daten (heutige Data Warehouses erreichen schon mal mehrere 100 Terabytes)
• Diese Daten lassen sich alle auf bestimmte Personen oder Gruppen von Personen beziehen
• Man versucht, durch geeignete Verknüpfung dieser Daten neue Erkenntnisse zu gewinnen, aber
• Diese Erkenntnisse müssen nicht korrekt sein

Beim Einsatz von Profiling ergeben sich daher eine Reihe von Risiken.

Welche Risiken das sind, und wie man am besten mit ihnen umgeht, wird jedoch Thema von Teil 2 dieses Artikels sein.

In meinem letzten Post habe ich bereits über einige Vorteile gesprochen, die sich durch den Einsatz eines IDM-Systems erreichen lassen.

Dies ist aber natürlich noch nicht das Ende der Fahnenstange. Richtig eingesetzt, ergeben sich noch weitere Vorteile:

- Höhere Produktivität bei der Verwaltung der Nutzerkonten: Bedingt durch den höheren Automatisierungsgrad lassen sich mit weniger Aufwand mehr Konten verwalten. Die Verwaltungskosten pro Account sinken.

- Da ein Großteil der Arbeit, die bisher von den Administratoren manuell verrichtet wurde, nun durch das IDM-System übernommen wird, bekommen diese nun endlich den Freiraum, um die im System vergebenen Berechtigungen durchzugehen und auf den aktuellen Stand zu bringen. Ein Problem manueller Rechteverwaltung ist nämlich gerade auch die Tatsache, daß Berechtigungen zwar bei Bedarf mehr oder minder schnell erteilt, jedoch in der Regel nie mehr entzogen werden. Dadurch kommt es zum vielen Leuten bekannten Phänomen des Rechtesammelns (besonders “gefährlich” sind hier v.a. Personen, die oft Abteilungen und Aufgaben wechseln, z.B. gerade auch Praktikanten!). Dies verletzt jedoch das “Least Priviledge”-Prinzip, das besagt, daß jeder nur über die Berechtigungen verfügen sollte, die er zur Ausführung seiner ihm übertragenen Aufgaben minimal beötigt, und das Grundlage einer jeden Rechtevergabe sein sollte. Die Arbeit der Administratoren ist daher auch nach einer IDM-Einführung noch wichtig. Keinesfalls sollte eine solche Einführung zum Anlass genommen werden, personelle Kürzungen vorzunehmen. Hiermit lässt sich vielleicht erreichen, daß der Status Quo zu geringeren Kosten aufrecht erhalten werden kann. Da dieser jedoch meistens nicht von einer besonders hohen Qualität gekennzeichnet ist sollte stattdessen besser die Alternative “steigende Qualität bei gleichen Kosten” realisiert werden.

- Bessere Einhaltung von gesetzlichen Vorgaben, dadurch Vermeidung möglicher Sanktionen (neudeutsch „Compliance“): Gerade im Bereich der IT-Sicherheit gibt es heute eine Vielzahl von Gesetzen und Regeln, denen sich Organisationen unterwerfen müssen (z.B. BGB, GmbH-Gesetz, SOX, Basel II etc.). In einigen Fällen beinhalten diese Gesetze auch (teils regelmäßige) Nachweispflichten, die sich zumeist auf die Beantwortung der Frage reduzieren lassen, wer zu welcher Zeit was gemacht hat. Die Betonung liegt in diesem Falle auf „Wer“. Eine Antwort auf diese Frage kann in Zeiten zunehmend automatisierter Geschäftsprozesse manuell nur schwer erfüllt werden und wäre zumeist mit einem unrentabel hohen Aufwand verbunden. Eine mögliche Lösung besteht daher in der Einführung eines IDM-Systems. Tatsächlich hat sich in den letzten Jahren gezeigt, dass gerade Compliance eine der Haupttriebfedern für die Einführung von IDM-Systemen war.

- Effiziente Unterstützung Service-orientierter Architekturen (SOAs): In den letzten Jahren sind viele Unternehmen dazu übergegangen, neue Prozesse und Dienstleistungen auf Basis von serviceorientierten Architekturen anzubieten. Diese zeichnen sich in der Regel durch eine eher lose Kopplung verschiedener Systeme aus, die zudem in vielen Fällen noch über eigene Benutzer- und Berechtigungsverwaltung verfügen (und die schlimmstenfalls auch noch alle komplett unterschiedlich realisiert sind). Dies kann bei Einbindung in eine SOA zu hohen Aufwänden führen – und bei einem weiteren Ausbau der IT-Landschaft sogar gänzlich unbeherrschbar werden. Auch die Erreichung von Compliance wird auf diese Weise, d.h. ohne ein einheitliches Vorgehen beim Management von Identitäten, Rollen, Berechtigungen und Auditierung, nur schwer erreichbar sein. Man kann deswegen ohne weiteres sagen, dass Service-orientierte Architekturen ohne Identitätsmanagement nur sehr schwer zu verwirklichen sind, und eine sorgfältig geplante “Identitätsschicht” in jede SOA gehört.

Man darf hier jedoch nicht den Fehler machen und IDM als ein einzelnes Produkt sehen, das einmal installiert alle Probleme in diesem Bereich löst (obwohl einem die Softwarehersteller das immer gerne glauben machen wollen). Stattdessen handelt es sich eher um eine Art Technologierahmenwerk, das vor einem tatsächlichen Einsatz immer erst auf das jeweilige Unternehmen angepasst werden muß.

Es gilt daher immer abzuwägen, ab welcher Schwelle sich der Einsatz eines IDM-Systems für ein Unternehmen lohnt, bzw. ab wann so ein Einsatz sogar unverzichtbar ist.

Für diese Berechnung wurden verschiedene Kennzahlensysteme entwickelt, deren Vorstellung jedoch hier den Rahmen sprengen würde. An dieser Stelle möchte ich daher gerne auf einen der nächsten Artikel verweisen.

Soweit die erste Einführung in das Thema Account Management. Der nächste Artikel wird sich dann um das Thema Föderierung drehen. Auch das ist ein sehr spannendes Themengebiet, das gerade dabei ist so richtig in Fahrt zu kommen, und das das Zeug dazu hat, zu einem der wichtigsten Treiber für IDM-Projekte zu werden.

BFI

In meinem letzten Post (nachzulesen hier) habe ich kurz die Klassifikation von IdM-Systemen nach dem FIDIS-Modell vorgestellt.

Darauf aufbauend möchte ich nun gerne etwas über die Grundlagen des Typ 1-Identitätsmanagement erzählen : Was versteht man darunter, und was sind hierbei die Herausforderungen und Schwierigkeiten?

Beim nächsten Mal werde ich dann darauf eing ehen, warum es sich dennoch lohnt, und in einigen Fällen sogar unerläßlich ist.

Basis dieses Artikels ist im übrigen ein Foliensatz über einen Vortrag, den ich letztes Jahr an einem “Blue Friday” der InterFace AG gehalten habe. Wenn jemand an diesem Foliensatz interessiert ist, oder natürlich auch daran, daß ich diesen Vortrag bei einer anderen Gelegenheit nochmal halte, so lade ich ihn gerne ein, sich bei mir zu melden ( unter bernhard.findeiss (at) interface-ag.de).

Wie bereits im letzten Post erwähnt, kann Account Management definiert werden als die konsistente Verwaltung von Identitäten und deren Zugriff auf IT-Ressourcen eines Unternehmens über die gesamte Dauer ihres Lebenszyklus hinweg.

Dies beinhaltet u.a.:

- Personen: Interne sowie externe Mitarbeiter, aber auch technische Objekte, soweit sie Zugang zu Ressourcen benötigen (etwa Drucker, die automatisiert EMails verschicken können etc.).

- Speicherung von identitätsbezogenen Daten (Zulieferung zumeist aus Personalsystemen)

- Weitergabe von Daten an Zielsysteme, z.B. um Benutzerkonten einzurichten, Berechtigungen zuzuweisen bzw. zu entziehen, bzw. ganz allgemein zur Synchronisation von Daten zwischen IdM-System und Zielsystem. Die Zahl und die Art der anzubindenden Zielsysteme trägt im Übrigen maßgeblich zur Komplexität von IdM-Projekten bei.

- Unterstützung von Workflows, die im Unternehmensalltag benötigt werden, z.B. Anlage/Änderung/Löschung von Identitäten, Zuweisung/Entziehung von Ressourcen, Definition von Rollen etc.

Account Management ist für Unternehmen natürlich beileibe kein neues Thema, sondern wird in der Regel bereits genauso lange praktiziert, wie zugriffsgeschützte (IT-) Ressourcen vorhanden sind. Bisher wurde ein Großteil dieser Arbeit jedoch von einem Administrator “per Hand” erledigt, was natürlich mit sehr viel Aufwand verbunden ist, und auch eine höhere Fehlerrate beinhaltet, als wenn man dies automatisiert durch Anbindung an ein IdM-System macht.

Zudem hat man auch noch das Problem der Datensynchronisierung, da man natürlich auch hier sicherstellen muß, daß alle Systeme, zu denen eine Person Zugang haben soll, auf dem selben Satz von Identitätsdaten basieren. Diese sind aber nicht fest, sondern können sich im Laufe der Zeit ändern (etwa durch Heirat oder Umzug). Die Daten dann konsistent zu halten kann durchaus eine Herausforderung darstellen (z.B. Auflösung von Widersprüchen zwischen 2 Systemen).

Um dieses Problem zu lösen wurden in den 1990er-Jahren die ersten Verzeichnisdienste eingeführt. Diese sammeln alle personenbezogenen Daten und stellen sie über eine einheitliche Schnittstelle zur Verfügung (am bekanntesten dürfte hier LDAP sein). Diese Schnittstelle wird dann in Bezug auf die Stammdaten als “führend” definiert, sodass alle anderen Systeme sich damit abgleichen können.

Leider aber konnten auch hiermit nicht alle Probleme gelöst werden. Nicht alle relevanten Systeme unterstützen die Externalisierung von Identitätsdaten, bei manchen (z.B. Personalsystemen) kann dies aus verschiedenen Gründen sogar unerwünscht sein.

Mithilfe eines Identitätsmanagementsystems lässt sich jedoch auch diese Situation in den Griff kriegen:

Man erlaubt allen Systemen ihre Datenhoheit zu behalten, lediglich relevante Änderungen werden an das IdM-System weitergegeben. Dieses übernimmt daraufhin die Synchronisierung mit der restlichen Systemlandschaft. Auch auf diese Weise ist es möglich, die Konsistenz der Identitätsdaten über alle Systeme eines Unternehmens hinweg zu garantieren.

Dies ist einer der Vorteile der Einführung eines IdM-Systems. Über weitere Vorteile werde ich beim nächsten Mal schreiben.

Ganz herzlich begrüßen wir in unserer Runde Bernhard Findeiss, unseren Spezialisten im Bereich Identity Management (IdM)!

Hier sein erster Post bei IF-Blog:

Eines der Themen, die innerhalb der IT-Welt immer mehr in den Fokus der Öffentlichkeit rücken, ist das Thema “Identitätsmanagement”, bzw. “Identity Management” oder “IdM”, wie man heute auf neudeutsch gerne auch dazu sagt.

Was versteckt sich jedoch dahinter, und warum sollte jeder, der heute mit einem Computer arbeitet und sich im Internet bewegt, etwas darüber wissen?

Zuerst sollte man wissen, daß sich hinter dem Begriff “Identitätsmanagement” nicht ein einziges konsistentes Thema versteckt, sondern aus mehreren verschiedenen Themengebieten besteht, die auf dem ersten Blick nicht viel miteinander zu tun haben.

Diese Unterscheidung zu treffen ist in meinen Augen jedoch sehr wichtig um zu einer gemeinsamen Gesprächsgrundlage zu kommen, da viele der in diesem Bereich tätigen Personen sich nur auf jeweils ein Teilgebiet konzentrieren, am Ende des Tages jedoch alle von “Identitätsmanagement” sprechen (und so potentiell aneinander vorbei).

Eine solche Klassifizierung wurde z.B. im Rahmen des FIDIS-Projekts der EU vorgeschlagen (nachzulesen hier). Es definiert 3 verschiedene Kategorien, in die sich alle IdM-Systeme einordnen lassen:

Typ 1: Account Management

Dies ist die Art von Identitätsmanagement, die hauptsächlich von Unternehmen durchgeführt wird. Hierunter versteht man das Management des Lebenszyklus einer Identität im Unternehmen, vom Neueintritt nach der Einstellung, über Beförderungen/Degradierungen und Abteilungswechsel bis zu einem späteren Austritt. Ziel ist es, die Mitarbeiter des Unternehmens mit Zugriffsrechten auf genau die Ressourcen des Unternehmens auszustatten, die sie zur Ausführung ihrer Arbeit brauchen (etwa EMail, Internet, Dateizugriffsrechte etc.), aber auch Rechte zu entziehen, sollten diese Anforderungen zu einem späteren Zeitpunkt ändern.

Diese Art der Administration wird üblicherweise zentral von speziell dafür beauftragten Administratoren erledigt, nur in Ausnahmefällen vom Benutzer selbst. Der Fokus dieser Art von Identitätsmanagement liegt in der sicheren Identifizierung von Personen (”Authentifizierung”) und der anschließenden sicheren Zuweisung von Berechtigungen an diese Person (”Autorisierung”), weniger jedoch in der Aufrechterhaltung von Privatsphäre.

Typ 2: Profiling von Benutzerdaten durch eine Organisation

Typ 2-Identitätsmanagement beschäftigt sich damit, aus einer Menge von vorhandenen Daten über eine Person auf deren Verhalten und Vorlieben zu schließen. Ähnlich wie Typ 1 wird auch diese Art von Identitätsmanagement durch eine Organisation durchgeführt, genau wie auch hier der Fokus eher auf der sicheren Zuweisung der Profilinformationen zu einer Person liegt, als auf der Aufrechterhaltung von Privatsphäre.

Im Unterschied zu diesem steht jedoch bei Typ 2-IdM nicht der Zugang zu unternehmenseigenen Ressourcen im Vordergrund, sondern der Erkenntnisgewinn über eine Person (oder auch einer Gruppe von Personen) aus der Analyse der zur Verfügung stehenden Daten.

Als Grundlage für Profiling können öffentlich zugängliche Informationen aus dem Internet zum Einsatz kommen, die die meisten Personen im Laufe der Zeit hinterlassen, aber auch solche, die durch eigens für den Zweck der Datensammlung angelegte Systeme gewonnen werden.

Ein Beispiel für ein solches System ist z.B. das bei vielen Personen so beliebte Payback-Programm, mit dessen Hilfe mehr über unser Kaufverhalten herausgefunden werden soll. Auch Kreditkartenfirmen setzen Profiling ein, um so etwa Kartenmissbrauch aufzudecken, der sich in aller Regel durch ein abweichendes Nutzungsprofil auszeichnet.

Mittlerweile gibt es auch bereits spezielle Suchmaschinen, die öffentlich zugängliche Informationen aus dem Internet zu einem Profil über diese Person verknüpfen . Wer dies mal für sich selbst versuchen will, dem sei der Besuch der Seite www.yasni.de oder auch www.spock.com empfohlen, auch wenn letztere Seite sich hauptsächlich auf US-Bürger konzentriert.

Typ 3: Benutzergesteuertes kontextabhängiges Rollen- und Pseudonymmanagement

Hinter diesem etwas sperrigen Begriff versteckt sich die Art von Identitätsmanagement, die wir betreiben müssen, wenn wir die Spuren, die wir hinterlassen, wenn wir uns im Internet bewegen, bewusst steuern wollen, um z.B. ein späteres Profiling zu verhindern oder zumindest zu erschweren.

Das Hauptaugenmerk dieser Art von Identity Management liegt deswegen auf der Verwaltung persönlicher Daten, (üblicherweise Daten über einen selbst), und dem Schutz der (eigenen) Privatsphäre, z.B. indem man sich genau überlegt, auf welchen Internetseiten man welche Informationen hinterlässt.

Einem bewußten Typ-3-Identitätsmanagement wird in Zukunft noch wesentlich mehr Aufmerksamkeit zuteil werden als dies aktuell der Fall ist, kann sich aber auch heute schon lohnen, etwa wenn man beim nächsten Bewerbungsgespräch peinlichen Fragen über zu fortgeschrittener Stunde entstandenen und bei Youtube veröffentlichten Videos ausweichen will.

Mittlerweile gibt es sogar spezialisierte Unternehmen, die sich einzig und allein darum kümmern, solcherlei “Fehler” im Sinne ihrer Kunden zu korrigieren, und so das Profil der betreffenden Person in einem positivem Licht erscheinen zu lassen. Wenn man bedenkt, wie sorglos heute vor allem Jugendliche auf Seiten wie StudiVZ, Lokalisten usw. mit ihren persönlichen Daten umgehen, scheint dies ein Geschäftsmodell mit viel Potential für die Zukunft zu sein.

Soweit der kurze Überblick über die drei Aspekte des Themas Identitätsmanagement nach der FIDIS-Klassifikation.

Aufbauend auf diese Klassifizierung wollen wir in Zukunft in loser Folge weitere Artikel zu spannenden Themen in diesem Bereich veröffentlichen, etwa zu Identity Federation, kontext-basierter Authentifizierung oder SOA und IdM.

BFI