2. Clean Start

Ein bisschen Input für Ihre Arbeit dürfen Sie als Entwicklungsteam schon erwarten. In dem zweiten Kapitel stellen wir Ihnen drei Zutaten vor, die Sie als Architekt(in) von anderen auf jeden Fall einfordern sollten. Wir nennen das zusammenfassend einen „Clean Start“ für Ihr Projekt oder Ihre Produktentwicklung. Für den Fall, dass das nicht klappt, kennen Sie ja Ihr Schicksal: dann müssen Sie diese Teile der Analysearbeit auch noch selbst in die Hand nehmen.

1. Jedes Unterfangen sollte eine klare Vision und/oder klare Ziele haben
2. Die „Mitspieler“ sollten bekannt sein (neudeutsch: Ihre Stakeholder)
3. Und Sie sollten Ihre Spielwiese kennen, die Gebiete, die Ihr Team beeinflussen kann (neudeutsch: Ihren Scope)

Die drei Aspekte beeinflussen einander gegenseitig: Je ehrgeiziger Ihre Ziele, desto mehr Mitspieler; je größer der Scope, desto vielfältiger die Ziele. Es spielt daher keine Rolle, in welcher Reihenfolge Sie als Architekt(in) das angehen oder einfordern – Sie benötigen grundsätzlich alle drei.

Visionen und Ziele

Sie müssen damit leben, dass sich Anforderungen mit durchschnittlich 1 – 3% pro Monat ändern. Wir definieren Vision oder Ziele als denjenigen Teil der Requirements, die sich in dem geplanten Zeithorizont möglich NICHT ändern sollen; also als das, was wir in einer Iteration oder Entwicklungsphase wirklich anstreben.

Ein Projekt kann Ziele für unterschiedliche Zeithorizonte definieren, die aufeinander abgestimmt werden sollten. Für große Systeme haben wir drei unterschiedliche Zeithorizonte kennen gelernt:

• strategische Ziele gelten für teilweise für 3 – 5 Jahre
• Ziele für den Budgetzyklus von Firmen gelten üblicherweise 1 Jahr
• Release-Ziele gelten Wochen bis wenige Monate (unter der Voraussetzung, dass Sie innerhalb eines Jahres mehrere Releases liefern)

Innerhalb der Iterationen, die zu einem Release führen, sollten Sie dafür sorgen, dass die Anforderungen möglichst stabil bleiben. An den Übergängen zwischen Iterationen gibt es jedoch Zeitfenster, in denen Sie Ziele, Inhalte und Umfang den geänderten Wünschen oder Randbedingungen anpassen können. Tom de Marco & Co nennen das in [DeMarco-07] „Zeit für Änderungen“. Die Toleranz gegenüber Änderungen sollte einen Verlauf ähnlich Abbildung 2.2 nehmen: Je näher Sie einem Release kommen, desto stabiler sollten Anforderungen bleiben.

Wie kommuniziert man Visionen und Ziele

Die klassische Art ist es Ziele einfach umgangssprachlich festzuhalten. Dafür hat sich die Formel „PAM“ bewährt. Legen Sie pro Ziel Purpose, Advantage und Metrik fest.

• „Purpose“ beschreibt, was Sie erreichen wollen,
• Advantage motiviert, warum man dieses Ziel anstrebt, und die
• Metrik gibt vor, wie man Zielerreichung überprüfen möchte.

Ein Projekt sollte höchstens eine Handvoll solcher Ziele haben. Sorgen Sie also dafür, dass Sie von Ihren Managern oder Analytikern 3 – 5 solche Aussagen (natürlich abgestimmt mit den wichtigsten Stakeholdern) bekommen. Sie wollen definitiv ohne Zielkonflikte starten können.

In der agilen Welt finden Sie einige weitere Spielarten von Zieldefinitionen. Eine davon ist die Erstellung eines „Produktkoffers“ (vgl. Abbildung 2.3). Neben dem Namen des Produkts und einem Logo, das allen Beteiligten das Gefühl vermittelt „Das sind wir“, „Das ist unser Baby“ sollten darauf 3 – 5 Haupteigenschaften des geplanten Produkts stehen, möglichst so formuliert, dass die Kunden oder Nutzer das Produkt unbedingt haben wollen.

Eine Alternative dazu sind die „News from the Future“. Schreiben Sie am Anfang eines Projektes einen kurzen Zeitungsartikel, von dem Sie annehmen, dass er am Tag nach der Freigabe auf der Titelseite Ihrer Lieblingszeitung erscheint. Darin wird – vor Beginn der Entwicklung – festgehalten, was Sie als Lobeshymne auf Ihr Produkt am Tag nach dem Release lesen wollen.

Alle drei Arten der Zieldefinition finden Sie in [IREB] ausführlicher beschrieben. Die Notation spielt keine Rolle, aber als Architekt sollten Sie die Ziele des Business auf jeden Fall kennen.

Stakeholder

Der zweite wesentlich Einflussfaktor, den Projektmanagement und Analytiker bereits geklärt haben sollen, bevor Sie zu arbeiten beginnen, sind die Stakeholder Ihres Vorhabens. Wer hat welchen Einfluss? Wer kann wobei helfen oder hindern? Und auf dieser Liste sollte viel mehr stehen als nur der Sponsor des Vorhabens und Ihre potentiellen Kunden oder Nutzer. Die allerwichtigsten Ihrer Stakeholder haben erheblichen Einfluss auf die Ziele und den Scope des Vorhabens.

Eine solche Liste zu erstellen, ist kein Hexenwerk. Setzen Sie eine kleine Gruppe von Projektbeteiligten an einen Tisch und lassen Sie diese 15 Minuten brainstormen. Dann haben Sie wahrscheinlich schon 20 bis 30 Stakeholder identifiziert. Nun schicken Sie diese Liste an alle gefundenen Personen und fragen, wen Sie noch vergessen haben. Mit diesem „Schneeballeffekt“ wird Ihre Stakeholderliste schnell vollständig.

Warum ist die Kenntnis der Stakeholder so wichtig? Sowohl für Analyse wie auch für Architektur und Entwicklung gilt: Vergessene Stakeholder sind vergessene Requirements! Damit ist nicht gesagt, dass Sie alle Stakeholder, die Sie finden, auch intensiv am Projekt beteiligten müssen. Wenn Sie alle wichtigen potentiellen Interessenten kennen, dann können Sie aktiv entscheiden, wie viel oder wenig Sie diese in das Projekt einbinden wollen oder müssen.

Bezüglich der Form gilt – ähnlich wie für die Ziele: Sie haben Freiheiten. Nehmen Sie eine einfache Tabelle und führen Sie untern den Überschriften „Rolle“, „Ansprechpartner“, „Einfluss“,… Ihre Stakeholder einfach linear auf. Oder zeichnen Sie eine Stakeholder-Map, in der Sie Stakeholder und deren Abhängigkeiten bzw. Kommunikationskanäle visualisieren. Hilfreich ist oft auch eine Stakeholder-Matrix (vgl. Abbildung 2.4), um das Verhältnis zwischen Einfluss und Interesse auszudrücken.

Für Ihre Architekturarbeit kommen dann sicherlich noch viele weitere Stakeholder hinzu: alle, die mit der Lösung zu tun haben bzw. Teilsysteme oder Technologien zuliefern. Diese spielten eventuell für Ihr Management und die Analytiker noch keine Rolle. Als Architekt(in) müssen Sie aber all diese Personen und Organisation identifizieren.

Weitere Tipps zum Umgang mit Stakeholdern haben wir online unter [Stakeholder] oder in [Starke&Hruschka-16] für Sie zusammengestellt.

Scope

Der dritte Bestandteil eines „Clean Start“ wird oft in der Praxis ignoriert, obwohl doch die Festlegung von Scope und Kontext den weiteren Verlauf des Projekts erheblich beeinflussen. Die Definitionen der beiden Begriffe sind einfach: Scope ist der Bereich, den das Projekt aktiv gestalten kann – ihre Spielweise. Zum Kontext gehören alle Personen und IT-Systeme (evtl. auch Hardware-Sensorik und Aktuatorik), über die Sie nicht alleine entscheiden können (vgl. Abbildung 2.5). Wenn Sie im Kontext bzw. an den Schnittstellen zwischen Scope und Kontext etwas ändern wollen, dann müssen Sie mit den Nachbarn darüber verhandeln. Wenn Sie nicht verhandeln können oder dürfen, dann gelten die Festlegungen aus dem Kontext für Sie einfach als nicht beeinflussbare Randbedingungen.

Die Scope-Festlegung sollte erfolgen, um „innen“ von „außen“ unterscheiden zu können und die Schnittstellen zwischen „innen“ und „außen“ zu identifizieren. Eine einfache Notation dafür ist das sogenannte Kontextdiagramm (vgl. [Hruschka-19]), das nur aus drei Elementen besteht: Ihr System oder Produkt in der Mitte, rundherum alle Personen oder Systeme im Kontext, und allen Informationen, die aus dem Kontext in den Scope fließen bzw. aus dem Scope in den Kontext – kurz gesagt: die Ein- und Ausgaben Ihres Systems. Für Analytiker und Projektmanager reicht es aus, früh im Projekt über die ein- und ausgehenden Daten Bescheid zu wissen. Sie als Architekt(in) werden die Schnittstellen später noch sehr viel genauer betrachten müssen (Technologie, Protokolle, Push- oder Pull, Mengengerüste, Vertrauen in die Schnittstelle, …). Als Einstieg gilt aber: Schnittstelle erkannt, Gefahr halbwegs gebannt. Vergessene Schnittstellen gehören zu den Dingen, die Ihnen als Architekt(in) das Leben erschweren.

Erfahrungsgemäß tun sich viele Projekte und/oder Teams schwer damit, diese einfache Abgrenzung präzise vorzunehmen: Was gehört in unseren Scope und mit wem müssen wir verhandeln? Deshalb wollen wir im folgenden genauer auf die Feinheiten der Scope-Festlegung eingehen.

Produktscope und Projektscope

Wenn man von Produkt oder System spricht, ist meist ein IT-Produkt oder ein IT-System gemeint. Sollte Ihre Aufgaben also darin bestehen, ein (einziges) neues IT-System zu schaffen, so sind Produktscope und Projektscope identisch. In der Praxis betreffen Projekte manchmal auch mehrere vorhandene IT-Systeme. Möglicherweise müssen Sie ein System neu entwickeln oder kräftig modifizieren, und im Rahmen dessen auch notwendige Anpassungen anderer IT-Systeme gleich mit erledigen (siehe Abbildung 2.6).

Wie Sie an der Abbildung 2.6 erkennen müssen Sie sowohl die Schnittstellen des neuen (oder zu modifizierenden) Systems zu den Benutzern und zu IT-System 2 festlegen, als auch die Leistungen, Funktionalität und Schnittstellen innerhalb der IT-Systeme 1, 3 und 4 identifizieren, die angepasst werden müssen.

Sollten Sie als Projektverantwortlicher keine Entscheidungsgewalt über die notwendigen Änderungen an den IT-Systemen 1, 3 und 4 haben, so ist Ihr Projekterfolg vom guten Willen dieser drei Nachbarsysteme abhängig: Sie brauchen dort Änderungen, dürfen die aber nicht selbst ausführen oder anordnen, sondern müssen mit den Verantwortlichen dieser Systeme verhandeln.

Nutzen Sie in einer für die Scopefestlegung Ihres Projektes eine visuelle Gesamtübersicht („Kontextdiagramm“) des neuen oder zu modifizierenden Systems, zusammen mit den Nachbarsystemen 1 bis 4. Wir mögen dazu Komponentendiagramme mit einer kurzen (tabellarischen) Erklärung der Funktionalitäten und Schnittstellen. Das erleichtert die Diskussion über alle notwendigen Änderungen und Anpassungen.

Notationen für Scope und Kontext

Requirements-Analysten können Schnittstellen einfach vorgeben – in der Entwicklung bereiten diese den Entwicklungsteams möglicherweise viel Aufwand und beinhalten hohe Risiken.

Zur Festlegung der Grenze zwischen Scope und Kontext reicht anfangs die Betrachtung der ein- und ausgehenden Daten Ihres Systems. Die klassische Darstellungsweise dafür ist ein sogenanntes „fachliches Kontextdiagramm“, [Hruschka-19], wie Sie es als Beispiel für einen Bordcomputer eines PKWs in Abbildung 2.7 sehen. Das System soll den Fahrer mit typischen Informationen wie Durchschnittsgeschwindigkeit, Treibstoffverbrauch, Außentem-peratur, etc. versorgen, wie auch Navigation ermöglichen, einen Tempomaten zur Verfügung stellen, Wartungsintervalle überwachen und den Fahrer über Radiosender und Telefonanrufe informieren.

Sie sollten in einem Kontextdiagramm ALLE Nachbarsysteme identifizieren und für jedes davon die Ein- und Ausgaben benennen. Eine Aufzählung von Funktionen (oder Features und Epics) genügt meist nicht, um den Scope des Produktes festzulegen!

Falls Sie übrigens Diagramme nicht mögen, so schlägt [Hruschka-19] eine ganze Menge an alternativen Notationen dafür vor, im einfachsten Fall eine Tabellenmit allen Nachbarsystemen und deren Schnittstellen.

Wichtig ist, dass Sie

1. Ihr System klar identifiziert haben,
2. alle Nachbarn kennen und
3. die komplette Ein- und Ausgabe auf fachlicher Ebene verstanden haben.

Entwicklung braucht (Schnittstellen-)Details

Als Ergebnis einer Anforderungsanalyse genügt es, Ein- und Ausgaben von und zu den Nachbarn zu erkennen. Diese Schnittstellen explizit identifiziert zu haben, bedeutet mehr als die halbe Miete.

Bei Entwurf und Entwicklung des Systems müssen Sie bei jeder dieser externen Schnittstellen alle notwendigen Details entweder hinterfragen oder entscheiden. [Starke&Hruschka-16] gibt dazu viele pragmatische Hinweise. Sie müssen z.B. festlegen, wer der aktive Partner ist (Push oder Pull), wie die Handshakes oder Protokolle aussehen, die an der Schnittstelle einzuhalten sind, welche zeitlichen, technischen oder organisatorischen Randbedingungen einzuhalten sind, etc.

Im arc42-Termplate [arc42] haben wir Abschnitt 3 („Kontextabgrenzung“) für diese wichtigen Informationen vorgesehen. Abschnitt 3.1 enthält das fachliche Kontextdiagramm. Falls nötig können Sie in Abschnitt 3.2. noch das technische Kontextdiagramm aufnehmen, das die technischen Kanäle zeigt, über die fachliche Informationen fließen. Im obigen Beispiel würde man für das Fahrerinterface vielleicht sowohl Spracheingabe wie auch Tastatureingabe technisch zulassen. Viele der anderen Schnittstellen laufen vielleicht über den CAN-Bus. arc42-Abschnitt 3.2 enthält dann auch ein Mapping, welcher fachliche Input/Output über welchen technischen Kanal läuft.

Alternativ können Sie Details von Schnittstellen auch als technische oder querschnittliche Konzepte in Abschnitt 8 des Templates beschreiben – falls Sie beispielsweise viele Schnittstellen nach demselben Schema behandeln möchten.

Falls Sie auf die grafische Variante stehen: Die UML bietet Ihnen viele Möglichkeiten, Schnittstellen genauer festzulegen. Abbildung 2.8 zeigt zu obigem Beispiel jetzt die Verwendung von Ball- und Socket-Notation, bzw. die Einführung von Ports.

Wir Autoren vertreten diesbezüglich unterschiedliche Meinungen: Peter mag UML, Gernot eher die text- oder tabellenorientierte Beschreibung von Schnittstellen. Beides funktioniert.

Abbildung 2.8 zeigt noch eine Empfehlung: Wenn ein Produkt viele Schnittstellen aufweist, könnten Sie diese als Analyseergebnis bündeln. Abbildung 2.8 zeigt nur zwei Sensoren (Temp- und Durchfluss). Stellen Sie sich aber vor, dass Sie mehrere Dutzend Sensoren als Schnittstellen haben. Dann lohnt es sich, anfänglich in der Analyse nur über ein Sensorinterface zu sprechen (dargestellt als Sensor-Port) und das erst in Laufe der Entwicklung detailliert aufzuspalten. Als weiteres Beispiel. Nehmen Sie im Telekommunikationsbereich die Schnittstellen zu Roaming Partnern. Das sind vielleicht einige Hunderte, die teilweise ganz unterschiedliche Protokolle nutzen oder unterschiedliche Formate liefern. Trotzdem kann man sie anfangs zu einem „Roaming-Partner-Interface“ zusammenfassen. Wie gesagt: Schnittstelle erkannt, Gefahr halbwegs gebannt.

Damit sind Sie in den weitaus meisten Fällen mit Scope und Kontext fertig. Ein i-Tüpfelchen aber hätten wir noch für Sie.

Business- und Produktscope

Gründliche Requirements-Engineers unterscheiden zwischen Business-Scope und Produktscope: Der Business-Scope ist der Bereich Ihres Unternehmens oder Organisation, in dem Sie im Zuge Ihrer Software- oder Systementwicklung Entscheidungen treffen oder vorschlagen dürfen, also beispielsweise Ihr Fachbereich oder Ihre Abteilung. Normalerweise ist der Business-Scope um einiges größer als der Produktscope, weil Sie vielleicht nicht alles, was in Ihren Entscheidungsbereich fällt, auch automatisieren wollen. Sie können also in Zusammenarbeit von Analytikern und Architekten festlegen, welche Teile von Geschäftsprozessen automatisiert und welche Schritte vielleicht noch längere Zeit manuell durchgeführt werden sollen.

Abbildung 2.9 zeigt eine solche Situation. „User 1“ und „User 2a“, sowie „IT-System 1“ befinden sich außerhalb Ihres Business-Scopes. Dort haben Sie keinen direkten Einfluss. „User 2b“ und „User 3“, sowie „IT-System 2“ gehören in Ihren Business-Scope. Daher sollte es relativ leicht sein, diese bei der Neuentwicklung eines Produktes zu berücksichtigen. „IT-System n“ gehört Ihnen nicht alleine, sondern es sind auch andere Verantwortliche im Business-Kontext mit im Spiel.

Für „User 2a“ können Sie zum Beispiel entscheiden, dass Anfragen zunächst an „User 2b“ in Ihrer Abteilung gehen und dieser mit dem neuen Produkt diesen Request erfüllt. Später erhält „User 2a“ vielleicht direkter Zugriff zu dem neuen System.

Unsere Empfehlung ist es, in der Anforderungsanalyse die Scheuklappen grundsätzlich etwas weiter aufzumachen und an die Schnittstellen Ihres Business zu denken, statt an die möglicherweise eingeschränkten Schnittstellen eines Produktes.

Sie sehen schon: Scope und Kontextabgrenzung sind in vielen Fällen nicht trivial. Und wenn Sie diesen Input nicht von Requirements-Engineering oder Business-Analysts bekommen, dann ist das ein ganz wichtiger, früher Schritt bei Ihrer Architekturarbeit.

Empfehlungen

Nehmen Sie die Festlegung von Scope und Kontext ernst. Im Entwicklungsteam müssen Sie manchmal „nacharbeiten“, weil die Anforderungsanalyse oder Ihre Product-Owner Sie diesbezüglich im Stich gelassen haben.

Nutzen Sie bereits frühzeitig in Ihrem Projekt oder Vorhaben ein Kontextdiagramm als Kommunikationshilfsmittel, um Feedback Ihrer Stakeholder über die wichtigen Außenschnittstellen ihres Systems einzuholen – lange bevor Sie interne Entscheidungen treffen. Legen Sie besonderes Augenmerk auf volatile oder kritische Schnittstellen, die sich oft und ohne ihr Zutun ändern können.

Weiterer Input

Mit den Klärungen von Zielen, Stakeholdern und Scope haben Sie die wichtigsten Voraussetzungen für einen Clean Start erfüllt. Schön wäre es auch, wenn Sie einen groben Überblick über die gewünschte Funktionalität erhalten würden (z.B. in Form von Epics oder Feature-Listen), wenn man Ihnen die allerwichtigsten Qualitätsziele für das Produkt verrät (z.B. die Top 3 Qualitätsanforderungen). Sicherlich sollten Sie auch über die wichtigsten Randbedingungen klargestellt werden. Das T-Stich-Modelle in Abbildung 2.10 fasst das grafisch zusammen. Wenn der Aufwand für die komplette Klärung der Requirements 5% beträgt, dann reichen am Anfang 1 – 2 % davon aus, um volle Breite vor Tiefe zu eruieren. Parallel zu dieser Arbeit der Analytiker können Sie als Architekt(in) ja schon wichtige Eckpfeiler der Architektur festlegen (möglichst mit Ihrem Team zusammen) und auch schon erste Prototypen oder Minimal Viable Products (MVPs) implementieren. Ausgestattet mit dem Wissen bohren Sie dann iterativ da in die Tiefe, wo es sich am ehesten lohnt.

Bleiben Sie dran

Lassen Sie uns zusammenfassend unsere Empfehlung wiederholen: Bringen Sie Ihrem Management, den Product Ownern oder Business Analysts bei, dass sowohl Ziele, Scope und Stakeholder auf jeden Fall in deren Aufgabenbereich fallen. Vielleicht können diese Stakeholder Ihnen zusätzlich noch einen groben Überblick über die gewünschte Funktionalität des Systems, die dringendsten Erwartungshaltungen bezüglich Qualität sowie die härtesten Randbedingungen liefern. Dann haben Sie in Ihrer Rolle als Architekten einen entspannten Arbeitsbeginn. In diesem Sinne: Keep educating your product owners and business analysts!

Lernziele

Der [Req4Arc] Lehrplan sieht zu diesem Themenbereich folgende Lernziele vor:

LZ 2-1: Verstehen der Notwendigkeit einiger (begrenzter) Vorleistungen

• Verstehen, dass selbst bei iterativer Entwicklung einige Vorleistungen erforderlich sind.
• Wissen, dass explizite Kenntnisse über Visionen, Ziele und relevante Stakeholder erforderlich sind, damit das Entwicklungsteam fundierte Entscheidungen über die Systemarchitektur treffen kann.
• Verstehen, dass eine Vereinbarung über Umfang und Kontext erforderlich ist, insbesondere über die Schnittstellen zwischen Umfang und Kontext (d.h. die externen Schnittstellen des Produkts).

LZ 2-2: Verständnis für die Notwendigkeit von (high-level) Visionen und Geschäftszielen

• Verstehen, dass Visionen oder Geschäftsziele Ihre höchsten Anforderungen sind, d.h. die Anforderungen, die (hoffentlich) während eines Projekts nicht geändert werden.
• Verstehen, dass Visionen und Ziele quantifiziert und messbar gemacht werden sollten, um den Erfolg in Bezug auf den Geschäftswert überprüfen zu können.

LZ 2-3: Verschiedene Möglichkeiten und Notationen, um Visionen und

Unternehmensziele auszudrücken

• verschiedene Möglichkeiten kennen, um Vision und Ziele zu definieren (explizite Zielerklärungen, Wertversprechen für verschiedene Stakeholder, Visionsfeld, “Neuigkeiten aus der Zukunft”)
• Mnemotechnik für Visionen oder Geschäftszielsetzungen kennen (SMART, PAM)

LZ 2-4: Die Bedeutung der verschiedenen Stakeholder und ihr Einfluss auf das Produkt oder System

• Wissen, dass die Stakeholder die wichtigsten Quellen für Anforderungen sind.
• Verstehen, dass fehlende Stakeholder fehlende Anforderungen bedeuten können.
• Verstehen, dass Architekten sich bewusst sein sollten, dass die Stakeholder auf spezifische, angemessene Weise angesprochen werden müssen.

LZ 2-5: Unterschiedliche Bedürfnisse und Werte der verschiedenen Stakeholder (“Value Propositions”)

• Verstehen, dass verschiedene Interessengruppen unterschiedliche Bedürfnisse haben und unterschiedliche Meinungen darüber haben können, was an einem Produkt wertvoll ist.
• Wissen, dass eine priorisierte Stakeholderliste hilft, Anforderungen nach Geschäftswert zu priorisieren
• Wissen, dass Architekten mit Zielkonflikten zwischen den Bedürfnissen der Stakeholder umgehen müssen

LZ 2-6: Umfang und Abgrenzung vom Systemkontext

• Unterscheidung zwischen Geschäfts- und Produktumfang kennen
• Wissen über die Bedeutung externer Schnittstellen
• Unterscheiden zwischen verschiedenen Ebenen der Externalität (extern zum System, extern zur Geschäftseinheit, extern zum Unternehmen)
• verschiedene Möglichkeiten und Notationen kennen, um Umfang und Kontext auszudrücken, z.B. Kontextdiagramme