Über TPO42

1. Vision

TPO42 entstand aus der praktischen Notwendigkeit heraus, die Lücke zwischen Product Management und Software Architecture zu schließen. Als Technical Product Owner stehen Sie täglich vor der Herausforderung, Business-Anforderungen in technische Entscheidungen zu übersetzen - und dabei beiden Welten gerecht zu werden.

"Ein Technical Product Owner ist sowohl Übersetzer als auch Brückenbauer zwischen Produktvision und technischer Realität."

2. Das Problem

2.1. Getrennte Welten

Product Management Tools fokussieren auf: * User Stories und Features * Business Value und ROI * Market Requirements * Stakeholder Communication

Architecture Documentation behandelt: * Technical Decisions * System Structure * Quality Attributes * Implementation Details

2.2. Die Lücke

Zwischen beiden Welten klafft eine Dokumentations- und Kommunikationslücke:

❌ Requirements werden losgelöst von Architecture erstellt
❌ Technische Entscheidungen fehlt Business-Kontext
❌ Stakeholder sprechen verschiedene "Sprachen"
❌ Traceability zwischen Anforderungen und Architektur fehlt

3. Die TPO42 Lösung

3.1. Integration statt Separation

TPO42 verbindet req42 und arc42 unter der Haube:

// In req42 Business Goals
//tag::vision[]
=== Vision
Unser E-Commerce System soll 10x mehr Transaktionen verarbeiten können.
//end::vision[]

// In arc42 Introduction
Unresolved directive in about.adoc - include::../req42-chapters/01_business-goals.adoc[tag=vision]

3.2. Single Source of Truth

Ein Framework, eine Wahrheit: * Business Goals werden zu Architecture Drivers * Quality Requirements werden zu Architecture Constraints * Stakeholder Concerns werden zu Cross-cutting Concepts * Domain Model wird zur Architecture Vocabulary

3.3. Documentation as Code

# Ein Command, alle Perspektiven
dtcw docker generatePDF

# Generiert:
├── req42-documentation.pdf    # Product Perspective
├── arc42-documentation.pdf    # Technical Perspective
└── tpo42-integration.pdf      # Integrated View

4. Framework-Architektur

4.1. Kern-Komponenten

4.2. Tagged Sections

req42 Business Goals:

//tag::performance[]
Das System muss 1000 parallele Benutzer unterstützen.
//end::performance[]

arc42 Quality Requirements:

Unresolved directive in about.adoc - include::../req42-chapters/02_constraints.adoc[tag=performance]

Daraus folgt eine Load Balancer Architektur...

5. Zielgruppen im Detail

5.1. Technical Product Owner

Profil: * Product Owner mit technischem Background * Oder Software Architect mit Product-Fokus * Vermittelt zwischen Business und Engineering * Verantwortlich für Product + Technical Roadmap

Nutzen von TPO42: * ✅ Integrierte Dokumentation - Ein Framework für beide Welten * ✅ Stakeholder Alignment - Gemeinsame Sprache für alle * ✅ Traceability - Von Business Goal zur Technical Decision * ✅ Effizienz - Weniger Redundanz, mehr Fokus

5.2. Software Architects

Herausforderung: * Architecture Decisions ohne Business-Kontext * Schwierige Stakeholder-Kommunikation * Missing Link zu Product Strategy

TPO42 Benefits: * 🎯 Business Context für jede Technical Decision * 📊 Stakeholder Mapping für Architecture Concerns * 🔄 Bidirektionale Traceability Requirements ↔ Architecture

5.3. Senior Product Managers

Problem: * Technische Entscheidungen sind "Black Box" * Schwierige Priorisierung bei Technical Debt * Unklare Impact-Bewertung von Technical Stories

TPO42 Lösung: * 🔍 Technische Transparenz durch integrierte Dokumentation * ⚖️ Bessere Priorisierung durch Business-Tech-Verbindung * 📈 Impact Assessment für alle Entscheidungen

5.4. Development Teams

Situation: * Requirements und Architecture oft inkonsistent * Unklare Business-Motivation für Technical Tasks * Schwierige Stakeholder-Kommunikation

Mit TPO42: * 📋 Konsistente Dokumentation - Requirements + Architecture * 💡 Business Context für jeden Technical Task * 🗣️ Klare Communication mit allen Stakeholdern

6. Erfolgsgeschichten

6.1. Fintech Startup

Situation: Rapid Growth, Technical Debt, Compliance Requirements

Herausforderung: * Product Team wollte Features * Engineering Team wollte Refactoring * Compliance wollte Documentation

TPO42 Impact: * ✅ Integrierte Compliance-Dokumentation * ✅ Business Case für Technical Debt Reduction * ✅ Accelerated Feature Development durch bessere Architecture

6.2. Enterprise E-Commerce

Situation: Legacy System Migration, Multiple Stakeholder

Problem: * 15+ Stakeholder mit verschiedenen Concerns * Komplexe Legacy-Integration Requirements * Architecture Decisions mit Business Impact

Results mit TPO42: * 🎯 Stakeholder Alignment durch gemeinsame Dokumentation * 📊 Risk Assessment mit Business + Technical Perspective * ⚡ Faster Decision Making durch integrierte Views

7. Philosophie

7.1. Documentation as Code

TPO42 folgt konsequent dem Documentation as Code Prinzip:

📝 AsciiDoc als Single Source of Truth
🔄 Git Workflow für alle Änderungen
🤖 Automated Generation für verschiedene Audiences
🔗 Living Documentation die mit Code mitentwickelt wird

7.2. Single Source of Truth

Kein Copy-Paste zwischen Dokumenten:

// Definition einmal in req42
//tag::user-types[]
Wir unterscheiden Premium- und Standard-Kunden.
//end::user-types[]

// Verwendung in arc42
Unresolved directive in about.adoc - include::../req42/stakeholders.adoc[tag=user-types]

Framework	Autoren	Beitrag zu TPO42
req42	Dr. Peter Hruschka, Markus Meuten	Requirements Engineering Methodology
arc42	Dr. Peter Hruschka, Dr. Gernot Starke	Architecture Documentation Template
docToolchain	Gernot Starke, Ralf D. Müller	Documentation Generation Pipeline

Autoren

Beitrag zu TPO42

req42

Dr. Peter Hruschka, Markus Meuten

Requirements Engineering Methodology

arc42

Dr. Peter Hruschka, Dr. Gernot Starke

Architecture Documentation Template

docToolchain

Gernot Starke, Ralf D. Müller

Documentation Generation Pipeline

Vielen Dank an die req42 und arc42 Communities für die Inspiration und die solide Grundlage, auf der TPO42 aufbaut!

Haben Sie Fragen oder möchten Sie TPO42 in Ihrem Projekt einsetzen? Kontaktieren Sie uns gerne!