Business Function Modeling

Mit Business Function Modeling die fachliche Architektur beschreiben

Vom Elfenbeinturm ins reale Leben

Die Komplexität von IT-Projekten steigt stetig. Deutlich wird das unmittelbar bei Technik und Infrastruktur, aber auch die fachlichen Anforderungen und der funktionale Anspruch nehmen zu. Mit dem Ziel der Customer Centricity versucht man es dem Kunden so einfach wie möglich zu machen, verlagert damit aber die Komplexität in die Software (siehe Stefan Grösser: „Projekte scheitern wegen dynamischer Komplexität“). Hinzu kommt, dass Entscheidungsprozesse zunehmend heterogen werden und dass das Business-Know-how über viele Köpfe und Abteilungen verstreut ist. Allerdings ist nichts so entscheidend für den Projekterfolg wie eine gute fachliche Architektur, also das Anforderungsmanagement und das gemeinsame fachliche Verständnis. Methoden zum Management der Fachlichkeit gewinnen daher zunehmend an Bedeutung. Eine davon ist Business Function Modeling.

Herunter vom Turm

Fast jedes Unternehmen hat eine Gruppe gut ausgebildeter Spezialisten, die sich mit dem Management von Komplexität bestens auskennen: die Enterprise Architekten. Sie sind üblicherweise in einer zentralen Organisationseinheit außerhalb der Projekte oder in einer Stabsstelle angesiedelt. Sie haben oft Monitoring- und Vorgabenfunktion. Von ihrem Elfenbeinturm sieht die Welt einfach aus und es bietet sich ein weiter Ausblick, ohne die Hindernisse und Unebenheiten unten im Land wahrzunehmen. Damit die Projekte von ihrem Know-how profitieren, müssen die Architekten herunter vom Turm, rein ins unbestellte Feld der einzelnen Projekte (s. Abbildung). Sie behalten Ihren Fokus bei, den Überblick zu wahren, und nutzen ihre Kenntnis von Strategie und Zielen. Das dazu passende Werkzeug bringen sie selbst mit: Business Function Modeling. Wie durch diese Methodik der Enterprise Architektur Mehrwert generiert und gewinnbringend auf IT-Projekte angewendet werden kann, wollen wir uns genauer ansehen.

Wenn die Architekten von der Spitze des Turms heruntergestiegen sind, sehen sie vielleicht vor lauter Einzelheiten das Wesentliche nicht mehr. Beim Versuch, jeden Grashalm zu beschreiben, sind Zeit und Budget schnell aufgebraucht. Dies ist die Gefahr beim klassischen Requirements Engineering, bei dem jede einzelne Anforderung möglichst vorab detailliert erfasst wird. Zusätzlich konterkariert diese Detailspezifikation die Grundidee der Agilität.
Auch die beliebte Prozessmodellierung (BPM) birgt erhebliche Gefahren. Beschriebene Abläufe sind schnell veraltet und füllen als endlose Reihe von Aktenordnern den Turm. Deutlich stabiler ist das Ergebnis des Business Function Modeling, eine Art Landkarte, anhand derer jeder einen schnellen, einen strukturierten Überblick erhält. Gleichzeitig kann die Methodik fachlich “in der Breite” vollständig sein, ohne tiefer zu gehen als aktuell sinnvoll und nötig. Damit lässt sich die gewünschte Funktions-Landkarte in einer vorgegebenen, begrenzten Zeit erstellen – eine wichtige Vorarbeit für viele Projekte!

Das Land bestellen

Am Anfang steht die Frage, welche Geschäftsfunktionen (“Business Functions”) des Unternehmens durch die Anwendung unterstützt werden sollen. Diese werden im Weiteren in Teilfunktionen untergliedert, so dass eine Hierarchie von Funktionen entsteht. Um im Bild zu bleiben: auf dem Feld entstehen Äcker und in diesen wiederum Parzellen.
Im Weiteren wird der Begriff „Funktion“ als Kurzform für „Geschäftsfunktion“ bzw. „Business Function“ verwendet.

Eine fachliche Architektur ist in diesem Sinne eine hierarchische Zerlegung der Geschäftsfunktionen (s. Abbildung). Dabei wird ein Top-Down Ansatz verfolgt, was ein wesentlicher Unterschied zu klassischem Anforderungsmanagement ist. Jede gegebene Funktion wird erneut in die weiteren Funktionen untergliedert, die für ihre Durchführung notwendig sind. Dadurch erhält man die jeweils nächste Ebene der Hierarchie. Bei all dem interessiert nicht, in welcher Reihenfolge die Funktionen zusammenwirken, sondern nur, welche es überhaupt gibt. Es handelt sich also um eine statische, rein funktionale Sicht auf die Fachlichkeit.

Frühstück vorbereiten als Beispiel

Das Beispiel “Frühstück vorbereiten” kann das verdeutlichen. Hier gibt es die Teilfunktionen „Brötchen einkaufen“, “Tisch decken” und “Kaffee zubereiten”. “Kaffee zubereiten” könnte wiederum aus “Kaffeebohnen mahlen” und “Wasser kochen” bestehen. Dieser Prozess geht (theoretisch) so lange weiter, bis man auf der Ebene angekommen ist, die nicht feiner spezifiziert werden kann. Bei Softwaresystemen ist die unterste Ebene die der einzelnen Anforderung. In der Praxis zerlegt man allerdings nur so weit, wie es für die aktuelle Fragestellung sinnvoll ist – und gerade das ist eine der großen Stärken der Methode!

Das Ergebnis ist schließlich eine fachliche Architektur als Baumstruktur (s. Abbildung). Dies sollte jedoch nicht zu der Annahme führen, eine Geschäftsfunktion sei nur ein “Kästchen” in der Grafik. Wenn auch die Visualisierung sehr hilfreich ist, braucht dennoch jede Funktion auch eine textuelle Dokumentation (s.u.). Während man die Geschäftsfunktion dokumentiert, kommen auch die jeweils betroffenen Daten zur Diskussion. Aus diesen Informationen kann eine erste Version eines groben fachlichen Datenmodells und eines Glossars abgeleitet werden, welches essentiell für Klarheit und Kommunikation im Projekt ist und einen weiteren Mehrwert darstellt.

Sobald die meisten Funktionen gefunden sind, ist es möglich, sie auch nach anderen Kriterien zu gruppieren, z.B. nach den jeweiligen Nutzern oder den benötigten Fachobjekten. Daraus lassen sich Cluster von Funktionen ableiten, die wiederum eine gute Indikation für Komponenten in einer technischen Architektur geben. Hier erhält man als Architekt eine Methode, mit der man strukturiert technische Komponenten aus der Fachlichkeit ableiten kann, was großen zusätzlichen Nutzen schafft!

Wie man pflügt und sät

Die Erfahrung von S&N Invent mit dem Einsatz des Business Function Modeling zeigt, dass eine frühzeitige Erstellung der fachlichen Architektur sinnvoll ist. Für die Erstellung der gewünschten Funktions-Landkarte ist ein kleines, schlagkräftiges Team mit einem erfahrenen Architekten, einem Business Analysten und einigen wenigen fachlich kompetenten Mitarbeitern ausreichend. Wichtig ist es, dem Team Raum für Diskussionen einzuräumen, denn erst in der kritischen Auseinandersetzung mit den fachlichen Inhalten entsteht eine saubere und vor allem von allen Seiten gleichermaßen anerkannte Definition der Geschäftsfunktionen.

Die Funktionen der obersten Ebene sollten zuerst benannt werden. Dabei steht die Frage nach dem “Was?” im Vordergrund – Technik, Tools und auch Details der Realisierung sollten zunächst ausgeblendet werden. Prozesse können insofern hilfreich sein, als dass man sie als Quelle für die ersten Geschäftsfunktionen nutzen kann, denn häufig treten diese auch als Aktivitäten in Erscheinung. Danach führt die hierarchische Zerlegung zu tieferen Funktionen. Die dafür zur Verfügung stehenden Informationsquellen sind u.a. bekannte Pain Points, Stärken bereits vorhandener Lösungen, Analyse von Wettbewerbsprodukten und die Strategie des Unternehmens. Geschäftsfunktionen sollten immer mit einem starken Verb im Namen verständlich benannt werden (“Kaffeebohnen mahlen”). Es empfiehlt sich zusätzlich eine unveränderliche ID für jede identifizierte Funktion zu vergeben, mit der eindeutig referenziert werden kann.

Die Zerlegung sollte so erfolgen, dass die jeweils nächste Ebene den fachlichen Umfang der darüberliegenden Funktion vollständig wiedergibt. Alle für eine gegebene Funktion notwendigen Teilfunktionen müssen enthalten sein. Die Geschäftsfunktionen einer Ebene haben im Ergebnis idealerweise die gleiche Granularität, sind also vergleichbar “mächtig” und ähnlich detailliert. Eindeutigkeit ist ein weiteres wichtiges Kriterium, d.h. sollte dieselbe Funktion an verschiedenen Stellen benötigt werden, ist diese als Referenz zu betrachten und keinesfalls doppelt zu erfassen. Auf der anderen Seite können auf den ersten Blick identische Funktionen eine Falle darstellen, denn oft verleitet nur ein ähnlicher Name zu einer solchen Vermutung, die sich später als falsch erweist.

Um klar getrennte Äcker und Parzellen zu erhalten, muss bekannt sein, was dort anzubauen ist. Daher sollte die Definition der einzelnen Geschäftsfunktionen nicht vernachlässigt werden, denn der Name allein lässt zu viel Spielraum bei der Interpretation. Eine textuelle Beschreibung ist unerlässlich. Zu ihr gehören auch nicht-funktionale Anforderungen und wenn möglich Vor- und Nachbedingungen.

Erntezeit - wer bekommt die Früchte

Sobald auf den Äckern Getreide und Obst wachsen, stellt sich die Frage: was geschieht damit? Die fachliche Architektur dient zunächst der Kommunikation. Ihre grafische Repräsentation zeigt unmittelbar, welche Funktionen die zukünftige Anwendung besitzen wird. Dabei beschreibt die fachliche Architektur sowohl das große Ganze, als auch detailliert die jeweilige fachliche Bedeutung der einzelnen Funktionen. Dadurch wird eine strukturierte Diskussion über funktionale Inhalte möglich, von der verschiedenste Rollen profitieren, u.a. Enterprise Architecture, IT Entwicklung, Infrastrukturbetrieb, Management und Fachbereiche.

Beispielhafte Vorteile einzelner Rollen:

Der CIO kann auf einen Blick alle vom Projekt bereitgestellten Funktionen in einem für ihn verständlichen Format erkennen und weitere Maßnahmen wie z.B. Projekte oder Changes ableiten.
Der IT Betriebsleiter kann Auswirkungen auf die Gesamt-IT des Unternehmens bei Ausfällen oder Kapazitätsengpässen abschätzen.
Entwickler verstehen, welche Features betroffen sind, wenn sie an einer tiefer liegenden Funktion arbeiten.
Product Owner erhalten ein übergreifendes Backlog und eine globale Übersicht.
Architekten können Komponenten ableiten (s. Grafik) und haben einen Überblick, wo welche Fachlichkeit verbaut ist.
Projektleiter können Teams und Releases entsprechend schneiden

Agiler Ackerbau

Der Turm ist verlassen und hunderte Architekten arbeiten auf den Feldern? Wohl hoffentlich nicht. Denn eine agile IT ist alles andere als wahr gewordenes Chaos – sie benötigt mehr denn je Menschen mit Überblick und klare Strukturen.
Entgegen der naiven Annahme entstehen auch in einem agilen Projekt die fachlichen Anforderungen nicht spontan Sprint für Sprint, sondern sind – zumindest in groben Zügen – meist bekannt. Es gibt hier viele Ansätze, diese Fachlichkeit zu strukturieren:

Clusterung von Stories,
Verteilung auf fachlich spezialisierte Teams,
Bildung von Epics,
Agile Story Mapping.

Ein Gesamtüberblick ist jedoch für jeden Product Owner (PO) dringend notwendig. Es liegt nahe, diesen Überblick mit Business Function Modeling herzustellen.
Ist die Methodik noch nicht im “Werkzeugkasten” des Product Owners (SCRUM – Stresstest mit der Wirklichkeit), so empfiehlt sich die Unterstützung durch einen Business Analysten oder Architekten mit entsprechender Erfahrung. Ein sauber dokumentiertes Feld, bei dem klar ist, wo welches Getreide wächst, und wo die Grenze zu anderen Parzellen ist, erleichtert den Überblick und die Kommunikation.
Business Function Modeling hilft, um den Scope zu definieren und zu erkennen, was alles von dem Projekt betroffen ist. Sobald die Funktions-Landkarte steht, ist sie erfahrungsgemäß ein gutes Werkzeug Fortschritte zu verfolgen (also welche Geschäftsfunktionen bereits wie weit umgesetzt sind) und Ergebnisse zu kommunizieren. Zudem lässt sich eine Ebene in der Hierarchie der Geschäftsfunktionen finden, aus der sich Epics für die Abarbeitung in den Teams ableiten lassen, so dass die Funktions-Landkarte ein Ausgangspunkt für das Backlog darstellt. Des Weiteren liefert sie eine gute Basis für die Kommunikation mit den Stakeholdern und Teams.

Fazit: Pflügen - aber richtig

Business Function Modeling ist eine Methode aus der Enterprise Architektur. Sie kann sehr erfolgreich und lohnend auch zur Analyse der Fachlichkeit in konkreten Projekten verwendet werden. Die entstehende Funktions-Landkarte erlaubt dabei unabhängig vom Detailgrad fachlich vollständig zu sein. So schafft man es, das ganze Feld zu bestellen ohne sich festzufahren. Der Abstieg aus dem Turm bringt für beide Seiten Vorteile mit sich:

Der Rückfluss an Informationen aus den Projekten an die Enterprise Architektur ist auf diese Weise viel strukturierter und meist auch besser an das Domain Model des CIO anzugleichen.
Die Funktions-Landkarte des Projekts stellt somit eine Verfeinerung eines Ausschnitts des gesamten Domain Models dar.

Wie bei allen Methoden gilt auch hier: „Nicht immer passt es“. Business Function Modeling eignet sich am besten auf dem “brown field”, wenn also das Land bereits abgesteckt ist. Das ist z.B. bei Ablöseprojekten oder Ausschreibungen der Fall. Weniger gut passt die Methode zu einem “green field”, bei dem erst die Holzfäller den Wald roden müssen. In Projekten mit entsprechend hoher Unsicherheit oder völligem Neuland empfiehlt sich auch in der fachlichen Analyse eher ein vollständig iterativ-inkrementeller Ansatz.

Sind die Voraussetzungen gegeben, dann profitieren vor allem mittlere bis große Vorhaben (z.B. nach SAFe skalierte agile Projekte) vom Business Function Modeling, denn es ermöglicht strukturierte Entscheidungen bei Scope Management, fachlicher Priorisierung und Teamaufteilung. S&N Invent wendet diese Methode seit einigen Jahren erfolgreich und nachhaltig in Projekten an – kommen sie bei Fragen gerne auf uns zu.

IREB Gold Partner

In der Architektur spielen Requirement Engineering und Business Analyse eine zentrale Rolle.
Die Business Unit Consulting von S&N Invent zertifiziert daher Ihre Berater nach CPRE und hält aktuell den IREB Gold Partner Status.
IREB, das International Requirements Engineering Board, ist eine Non-Profit-Organisation und der Entwickler des CPRE (Certified Professional for Requirements Engineering) Zertifizierungskonzepts.