REA.07: Produkte bestehen aus Business Capabilities

Business Capabilites oder Fähigkeiten als Bausteine des Designs

Mit der Definition des Begriffs «Produkt» ist uns immer wieder der Begriff der Fähigkeit begegnet. Was ist denn nun eine Fähigkeit. Eigentlich ist es ganz einfach. Eine Fähigkeit ermöglicht dem Ausübenden einer Fähigkeit eine Wirkung zu erzielen.

Michael Schumacher als Formel-Eins Rennfahrer hatte zwei wesentliche Fähigkeiten, die ihm seinen Erfolg (die Wirkung) begründeten: Er hat zum einen sein Auto beherrscht, zum anderen konnte er seinem Team genau erklären, wie das Auto für ihn eingestellt werden muss, damit er damit schnell fahren kann.

Die Fähigkeiten eines Zahlungstransaktion-Service (=Produkt) ist der zuverlässige und nachvollziehbare Transfer eines finanziellen Wertes von einem identifizierten und autorisierten Konto auf ein anderes identifiziertes und autorisiertes Konto. Dabei muss der Service nicht einmal wissen, wem die Konten gehören, sie müssen lediglich autorisiert sein für die Transaktion. Das Autorisieren ist eine Fähigkeit für sich.

Wenn wir nun ein gesamtes Unternehmen ansehen, so werden wir erkennen, dass es einer Unmenge von Fähigkeiten bedarf, um ein Unternehmen zu betreiben und den Kunden des Unternehmens Produkte und Services anbieten zu können. Ein Subset dieser Fähigkeiten dient dazu das Unternehmen zu steuern und zu verwalten. Ein weiteres Subset an Fähigkeiten dient dazu innovativ zu sein, Produkte zu entwerfen, diese initial (als MVP?) zu bauen, weiterzuentwickeln und betreiben zu können. Ein Subset an Fähigkeiten umfasst diejenigen, die in den Produkten stecken, welche den Kunden angedient werden und die den Nutzern der Produkte einen Wert liefern.

Ein Unternehmen tut gut daran zumindest die letzten beiden Sets an Fähigkeiten explizit auszuarbeiten, also das Subset an Fähigkeiten, um Produkte bauen und betreiben zu können und das Subset an Fähigkeiten, das in den Produkten selbst steckt.

Das ist ein spannender Punkt, wenn wir uns an die Diskussion erinnern bezüglich Infrastruktur und wie Produkte und Services Infrastruktur nutzen. Mit ein paar Beispielen ist das wahrscheinlich einfacher zu verstehen. Das Produkt beim Bahnfahren ist der Transport von Personen oder Ware von A nach B. Die Infrastruktur sind die Gleise, die Trasse, die Oberleitung. Ein Bahnhof ist wiederum ein Produkt, da er dem Nutzer (dem Reisenden) einen Mehrwert liefert, zum Beispiel die Kaffee Bar oder der Ticketschalter (wobei ich aus meiner persönlichen leidvollen Erfahrung vom Mehrwert des Ticketschalters nur beschränkt überzeugt bin). Bei einer Cloud Software stellen die Cloud Services die Infrastruktur dar, welche (wie das Gleis) Rechner- oder Storagekapazitäten zur Verfügung stellen.

Aus dieser Betrachtung heraus gehört Infrastruktur zu dem Set an Fähigkeiten Produkte bauen und betreiben zu können und nicht zu dem Set an Fähigkeiten, welchen die Produkte ihren Nutzern anbieten. Mit diesen Konzepten, sollte ein Unternehmen die Fähigkeit (😊) besitzen zwischen Infrastruktur, Plattform und (verkaufbaren) Produkten zu unterscheiden. Ein verkaufbares Produkt ist hierbei ein Produkt, welches Wertschöpfung bei einer zahlungsbereiten Kundin des Unternehmens generiert.

Value Streams Produkte die Business Capabilites bereitstellen

Allmählich fragen wir uns, was das Ganze mit Resilienz zu tun hat, richtig?

Die einfachste Frage diesbezüglich ist, wer ein resilientes Produkt baut. Letztlich sind es Menschen, also ein Team, das ein Produkt baut. Ideal, wenn das Team die Prinzipien eines Produktes verstanden hat und anwenden kann. Hier kommen wir zum Punkt welche Fähigkeiten ein Team benötigt, um eine resiliente Enterprise Architecture entstehen zu lassen.

Wenn ein Team einem (Elementar-)Produkt, diese Fähigkeit geben will, so ist die Anforderung an das Team, dass dieses die fachliche UND die technologische Komplexität des Produktes beherrscht. Das Team ist also nicht alleine eine Umsetzungsmaschine, welches Software umsetzt gemäss von aussen an das Team herangetragenen Anforderungen.

Das Team ist eine Einheit, welches die Fähigkeiten des Produktes, an dem es arbeitet, versteht und die Einbettung der Fähigkeiten im Gesamtkontext des Unternehmens. Das Team weiss (direkt oder indirekt) aufgrund strategischer Entscheidungen im Unternehmen, wie sich diese Fähigkeiten weiter entwickeln sollen. Das Team beherrscht die Technologie zur Implementierung der Fähigkeiten. Das Team kann autonom entscheiden das Produkt neu zu implementieren, wenn eine neue Technologie die zukünftige Entwicklung der Fähigkeiten deutlich besser unterstützt.

Einwurf
Ich persönlich bezeichne das, was ein Team erstellt und Benutzern zur Verfügung stellt als «Produkt». Das ist wahrscheinlich die feinst-granulare Sicht auf ein Produkt. Ich persönlich verwende gerne den Begriff «Elementarprodukt». Software und System Architekten verwenden typisch die Bezeichnung Komponente. Ich persönlich (schon wieder ich persönlich) lehne diese Bezeichnung als zu unspezifisch ab, da sie den Einbezug der fachlichen Fähigkeiten nicht berücksichtigt. Nur ein Subset der Komponenten sind somit auch wirklich Produkte.

Jetzt sind wir auch an dem Punkt, an dem Agilität Sinn macht. Aus Team-dynamischen Gründen besteht ein Team ideal aus 7 +/- 2 Mitarbeitenden. Ursprünglich ist das übrigens keine Forderung der Agilität, sondern eine Forderung aus der Gruppentheorie. In dem Bereich ist das Verhältnis von Produktivität zu Kommunikation optimal. Ganz wesentlichen Anteil an der optimalen Teamgrösse besitzt jedoch das «shared Knowledge», also das nicht dokumentierte gemeinsame Verständnis, welches durch Kommunikation entsteht. Shared Knowledge, sowohl fachlich wie technologisch, fördert gute und schnelle Entscheidungen im Team. Shared Knowledge macht ein Team effektiv, effizient und sorgt für hohe Lieferqualität. Das shared Knowledge ist das eigentliche Argument für konstante Teams.

Erinnern wir uns an Blog 4 und an die Aussagen zur Grösse einer Komponente. Ideal entwickelt ein Team, maximal zwei Teams ein (Elementar-)Produkt. Bei mehr als zwei Teams ist die Gesamtkomplexität, um die Fachlichkeit und Technologie zu beherrschen, ohne zusätzliche Management- oder Dokumentationsmassnahmen zu verwenden.

Nun könnte man sagen, dass dies zu sehr feingranularen Produkten führt. Hier eine Spielrechnung. Rechnen wir im Schnitt mit sieben Personen pro Team, so ergeben sich bei eintausend Personen einhundertundfünzig (150) Produkte, die über Bündelung zu höherwertigen Produkten aufgebaut werden könnten.

Ein höherwertiges Produkt könnte eine fachliche Plattform sein, ein Produkt oder ein Service, der einer Kundezielgruppe angeboten wird. Diese Mengengerüste sollten eine Enterprise Architecture, die konsequent Fähigkeiten und Produkte als Kern-Assets bewirtschaftet, beherrschen. Ein höherwertiges Produkt, zum Beispiel eine Plattform, könnte zum Beispiel aus vier bis fünf Elementarprodukten bestehen, die von insgesamt sieben Teams erstellt werden – und schon habe wir die Idee eines Value Streams.

Ein Value Stream ist bestrebt die Geschäftsfähigkeiten des oder der höherwertigen Produkte zu verbessern anhand der Anforderungen, welche an die Geschäftsfähigkeiten gestellt werden. Die Anforderungen kommen von den Benutzern des (höherwertigen) Produktes. Bei einer Plattform sind dies andere Teams im Unternehmen, welche die Plattform (als Benutzer) zur Entwicklung einsetzen.

Bei einem „End“-Produkt, welches den Kundinnen und Kunden des Unternehmens angeboten wird, sind es die Bedürfnisse der Kundinnen und Kunden, welche die Fähigkeiten des Produktes bestimmen. Da wir die Bedürfnisse des Kunden nicht genau kennen und sich diese auch noch beständig ändern, ist es relevant in schnellen „Experimenten“, d.h. neuen Versionen des Produktes, mehr über unsere Kundinnen und Kunden zu lernen und mit der Zeit die besten Produkte zu bauen – zumindest im Vergleich zu Konkurrenz. Dann haben wir ein resilientes Unternehmen geschaffen.

Auf Values Streams gehe ich im kommenden Blog noch genauer ein…

Wenden wir nun alle die Rahmenbedingungen auf ein resilientes Design der Enterprise Architecture an

• Ein Team ist 7 +/- 2 Personen gross.
• Ein Team implementiert ein Set an fachlichen Fähigkeiten und ist weitgehend autonom in der Lage diese Fähigkeiten nach einem übergeordneten Bebauungsplan fachlich weiterzuentwickeln.
• Das Lieferobjekt des Teams nennen wir Produkt.
• Ein Produkt hat technologische Schnittstellen und HCI (Benutzer) Schnittstellen, mittels derer Nutzer das Produkt verwenden.
• Schnittstellen sind für Nutzer sind grundsätzlich dem Blackbox Prinzip folgend vorhanden. Das bedeutet der Nutzer muss nichts über die Implementierung wissen, um die Schnittstellen zu benutzen.
• Das Produkt und seine Schnittstellen sind versioniert (auch die HCI-Schnittstellen).
• Es existiert eine übergreifende Schnittstellen Policy in der Weiterentwicklung der Schnittstellen

Sind diese Rahmenbedingungen erfüllt, dann ist die Komplexität, der ein Team ausgesetzt ist, begrenzt. Wenn das Team die Fachlichkeit gut versteht, dann ist ein gut ausgebildetes DevOps Team heutzutage sehr schnell in der Lage eine Implementierung der Fachlichkeit in sehr kurzer Zeit durchzuführen – und das in einer beliebigen Technologie.

Wenn also die technologische Basis des Produkts, für das sich das Team verantwortlich fühlt, gealtert ist oder architekturellen Zerfall aufweist, so ist ein gutes DevOps Team meiner Erfahrung nach – und nach den Erfahrungen aus den Startup Szenen – in der Lage in einem Zeitraum kleiner sechs Monate eine komplette Neuimplementierung der fachlichen Fähigkeiten in einer neuen Technologie durchzuführen.

Diese Betrachtung «maximal zwei Teams für ein (Elementar-)Produkt» löst noch nicht die Frage, wie ein höherwertiges Produkt oder Service idenrtifiziert wird als Aggregation aus einer Anzahl an Elementarprodukten, also fragen wie

• wer fühlt sich für ein Produkt verantwortlich
• welche Rollen sind im Unternehmen sinnvoll oder relevant
• wie identifizieren wir Value Streams im Unternehmen

Dem Thema ist der nächste Blog gewidmet

• Blog 1: Ein Essay über resiliente Enterprise Architecture
• Blog 2: Architektonische Irrungen
• Blog 3: Das Spiel mit der Komplexität
• Blog 4: Komplexität verteilen – Die Grössen einer Komponente
• Blog 5: Die Komplexität des Schnittstellen Netzwerkes
• Blog 6: Was ist eigentlich ein Produkt oder Service?

P.S.: Alle Bilder sind frei lizenzierbaren Quellen entnommen – oder meine eigenen. Daher können alle Bilder aus dieser Blogserie entsprechend Attribution weiter verwendet werden.

Resilince in Enterprise Architecture © 2024 by Rainer Grau is licensed under CC BY-SA 4.0