Architekturbewertung schafft Klarheit und Fokus und hilft dabei, Risiken besser einzuschätzen und Entscheidungen abzusichern. Alternativ werden auch gerne die Begriffe Architektur-Review oder Architektur-Evaluation verwendet.

Wer eine Architekturbewertung durchführen möchte, kann zwischen etlichen Methoden wählen, die viele Überlappungen, aber auch einige Spezialisierungen haben. Diese Methoden sind häufig für eine große Bandbreite an Situationen und Herausforderungen geeignet und entsprechend allgemein beschrieben.

In dieser Artikelreihe möchten wir einen Einblick geben in konkrete Situationen aus der Praxis, in denen Architekturbewertung sehr nützlich sein kann. Die konkreten Situationen basieren alle auf realen Projekten und Situationen, die wir erlebt haben, sind aber immer generalisiert und anonymisiert. Pro Artikel beschreiben wir eine Situation und geben für diese Situation konkrete Tipps, wie eine Architekturbewertung durchgeführt werden kann und worauf besonders zu achten ist. Bisher erschienen:

• Architekturbewertung aus der Praxis (1): Qualitätsdesaster trotz Neuentwicklung
• Architekturbewertung aus der Praxis (2): Dienstleister liefert schlechte Qualität
• Architekturbewertung aus der Praxis (3): Architekturentscheidungen vor Gericht

Situation: Patentverletzung oder doch nicht?

Um über die einzelnen Artikel der Serie hinweg die wichtigsten Aspekte auf einen Blick zugänglich zu machen, liefern wir hier eine kurze Übersicht der wichtigsten Charakteristika der Architekturbewertung.

Initiator der Architekturbewertung	Geschäftsführung und leitende Anwälte
Benötigte Konfidenz	Besonders hoch
Reviewer	Externe Reviewer (1-2) mit langjähriger Review-Erfahrung
Beteiligte Organisationen	Beklagtes Unternehmen im Patentstreit
Beteiligte Stakeholder	Patentanwälte Management, Projektleitung, Architekten, Entwickler
Methoden und Praktiken	Detailliertes Herausarbeiten von Architekturentscheidungen Analyse auf unterschiedlichen Abstraktionsebenen Erarbeitung intuitiv zugänglicher Darstellungen (Praktiken aus RATE, ATAM, DCAR, … kombinierbar)
Aufwand für Reviewer	~ 5 – 20 Personentage, eventuell auch mehr
Aufwand für sonstige Beteiligte	Beklagtes Unternehmen: ~ 2 – 15 Personentage

Beispielhafte Situation

Das Unternehmen RemoteDeviceRepair entwickelt und vertreibt eine integrierte Hardware- und Softwarelösung, mit deren Hilfe Reparaturbetriebe für elektronische Geräte von überall auf der Welt Zugriff auf führende Experten für das jeweilige zu reparierende Gerät bekommen zu können. Um die Verwendung möglichst einfach zu machen, kommt die Lösung mit integrierter Kamera und Stativen, um möglichst einfach das zu reparierende Gerät und die Reparatursituation filmen zu können. Der Reparateur vor Ort kann dann den Experten von remote zuschalten, kann mit diesem sprechen, kann Videoaufnahmen teilen und der remote Experte kann auch die Kontrolle über die Steuerung der Kamera übernehmen. Diese Lösung verkauft sich sehr gut an globale Hersteller von Highend-Geräten wie Küchengeräten.

Aus heiterem Himmel wird RemoteDeviceRepair von einer Klage wegen einer Patentverletzung überrascht. Das Unternehmen RemoteOperationDevices stellt medizinische Geräte für die Operation von Herzpatienten her, bei denen ein entfernter Spezialist hinzugezogen werden kann. Dieser entfernte Spezialist kann über Audio mit dem lokalen Operateur sprechen und kann sich per Video die Situation betrachten und hat steuernden Einfluss auf die Kamera im OP-Saal. Außerdem kann er auch aktiv ins Operationsgeschehen eingreifen, indem er Operationswerkzeuge auch aus der Ferne steuern kann.

Die Anwälte von RemoteOperationDevices werden RemoteDeviceRepair vor, ein seit langer Zeit gehaltenes Patent zu verletzen. Das Patent bezieht sich auf die technische Gesamtlösung (Hardware und Software), weil Software alleine in Deutschland nicht patentierbar ist.

Der konkrete Vorwurf bezieht sich auf die Verwendung der kombinierten Übertragung von Audiosignalen in beiden Richtungen, Videoübertragung in eine Richtung und die Möglichkeit aus der Ferne auf die Videoaufnahme Einfluss zu nehmen. In der Patentschrift ist in einem Abschnitt diese Konstellation kurz beschrieben und es ist formuliert, dass dafür „3 Datenkanäle“ zum Einsatz kommen.

Die Klage wegen Patentverletzung bezieht sich auf einen sehr konkreten Vorwurf, nämlich dass in der Lösung von RemoteDeviceRepair auch genau 3 Datenkanäle verwendet würden und deswegen eine Verletzung des Patents vorliege.

RemoteDeviceRepair kannte das besagte Patent nicht und ist der Meinung, dass die beschriebene Konstellation mit Audio- und Videoübertragung und Videosteuerung eine sehr grundlegende und auch sonst schon vielfach verwendete ist.

RemoteDeviceRepair beauftragt ebenfalls eine auf Patentstreitigkeiten spezialisierte Anwaltskanzlei. Es soll durch einen Gutachter ein technisches Gutachten erstellt werden, das zeigt, dass keine Patentverletzung vorliegt. Dazu wird ein Gutachter ausgewählt. Die Kanzlei und der Gutachter betrachten es als strategisch am sinnvollsten, die Argumentation der „Genau 3 Datenkanäle“ aktiv zu widerlegen. Dabei soll insbesondere gezeigt werden, dass die Aussage „genau 3 Datenkanäle“ viel unschärfer ist, als sie auf den ersten Blick erscheint und dass sie aus technischer Architekturperspektive noch nicht mal klar zu beantworten ist.

Architekturbewertung richtig aufsetzen und durchführen

Initiator der Architekturbewertung bzw. des Gutachtens ist der leitende Anwalt der Kanzlei zusammen mit der Geschäftsführung von RemoteDeviceRepair.

In solch kritischen Situationen wird öfters der Begriff „Gutachten“ bzw. „Architekturgutachten“ verwendet.

Es handelt sich bei diesem Gutachtenauftrag nicht um eine klassische Architekturbewertung. Trotzdem kommen viele Techniken aus der Architekturbewertung zum Einsatz, vor allem das präzise Herausarbeiten der aktuellen Architektursituation und der Abgleich mit Vorgaben. Im vorliegenden Fall ist das Patent natürlich keine Vorgabe und es geht ausnahmsweise eher darum, zu zeigen, dass eine Lösung dieser „Vorgabe“ nicht entspricht.

Die Erstellung des Gutachtens ist im Interesse und Auftrag von RemoteDeviceRepair und wird RemoteDeviceRepair angestoßen und (vor-)finanziert. Das Gutachten hat das Ziel, möglichst klar den Vorwurf der Patentverletzung zu widerlegen und dafür viele Argumente für das Gericht zu liefern. Vor allem viele Argumente, die Juristen direkt gar nicht zugänglich wären, weil ihnen die technische Tiefe in der Betrachtung fehlt.

Passenden Reviewer auswählen

In dieser kritischen Situation ist ein erfahrener, externer Reviewer unbedingt notwendig. Das Architektur-Gutachten muss mit möglichst Professionalität durchgeführt werden und das ist nur möglich mit der nötigen Distanz. Deshalb sollte eine Person ausgewählt werden, die auch keine enge Bindung zum Produkt hat.

Wegen der Kritikalität sollte der Reviewer umfangreiche Erfahrung mit Architektur-Reviews haben, idealerweise in zahlreichen Unternehmen. Erfahrungen in der konkreten Branche spielen weniger eine Rolle, aber Erfahrungen in der grundsätzlichen Art von Systemen sind sehr hilfreich. Wegen der Kritikalität der Lage ist es eventuell auch anzuraten, ein Team von zwei Reviewern einzusetzen, sodass diese die Möglichkeit haben, noch mehr mitzubekommen und sich im Zuge der Informationssammlung und Analyse auch immer wieder auszutauschen.

Auch Erfahrung im Umgang mit der Aufbereitung der Ergebnisse für anwaltliche Auseinandersetzungen und Gerichtsverfahren ist hilfreich.

Ziele und Bewertungsfragen klar herausarbeiten

Im Fall der vorgeworfenen Patentverletzung ist nicht direkt klar, wie die Bewertungsfragen aussehen sollten. Es muss eine Strategie zwischen Anwalt und Gutachter erarbeitet werden, welche Argumente rechtlich zielführend und technisch gut belegbar sein könnten.

Deshalb wird im vorliegenden Beispiel nur die folgende, einzige Bewertungsfrage formuliert:

• Wie viele Datenkanäle werden im System von RemoteDeviceRepair verwendet?

Relevante Stakeholder involvieren

Für das Gutachten muss RemoteDeviceRepair insbesondere sein Management-Team involvieren und den Chefarchitekten bzw. Chefentwickler.

Benötigte Konfidenz und Maßnahmen festlegen

Aufgrund der Kritikalität der Situation und der drohenden Kosten ist eine sehr hohe Konfidenz in die erzielten Ergebnisse notwendig und damit eine tiefere Analyse und Belegung der Findings unumgänglich. Deshalb sind die folgenden Maßnahmen empfohlen, um zu einer hohen Konfidenz zu kommen.

• Einbeziehung von vielen Personen und ihren Sichtweisen
• Sammlung von Fakten und Sichtung von jeglicher verfügbaren Dokumentation (oft muss man nicht alles lesen, man muss aber wissen, was es alles gibt)
• Abgleich aller verfügbaren Fakten und Zusammensetzung eines Gesamtbilds (Big Picture)
• Einbeziehung von einschlägigen Erfahrungen mit ähnlichen Sachverhalten aus anderen Projekten
• Saubere Interpretation und Dokumentation und Präsentation der Analyse-Ergebnisse, so dass sie möglichst gut von juristischen Stakeholdern verstanden werden können

Geeignete Praktiken und Methoden einsetzen

Wegen der kritischen Situation muss eine möglichst klare, gut untermauerte und nicht auszuhebelnde Antwort und Argumentation gefunden werden.

Die tatsächliche Methodik ist aus unserer Erfahrung eher nebensächlich. In der Praxis kombiniert man sowieso Praktiken und Aspekte aus verschiedenen Methoden und fügt sie zu einem sinnvollen Projektvorgehen zusammen, das stark auf die vorliegende Situation zugeschnitten ist.

Wegen der spezifischen Situation und Fragestellung nennen wir hier einige Praktiken und auch mögliche Argumentationen, um klar herauszuarbeiten, wie eine Analyse aussehen könnte. Bei anderen Fragestellungen kann sich die Vorgehensweise deutlich unterscheiden.

• Detaillierte Analyse der Patentschrift, inklusive Interpretation der Wichtigkeit bestimmter Details zusammen mit dem Anwalt
• Analyse der Verwendung von Begriffen und ähnlichen Begriffen in der Patentschrift (z.B. der Begriff „Datenkanal“)
• Analyse und Hinterfragen der zentralen Begriffe in der Patentschrift (z.B. „Datenkanal“):
  • Wie werden diese in der Praxis verwendet?
  • Wie verstehen Ingenieure diese Begriffe? Dazu kann man eine Reihe von nicht-involvierten Praktikern ansprechen und ihnen ohne Erläuterung des Kontexts Fragen zu den Begriffen stellen.
  • Wie sind die Begriffe in der Literatur definiert? Gibt es überhaupt einheitliche Definitionen der Begriffe?
• Analyse der Architektur des verdächtigten Produkts hinsichtlich der Ähnlichkeit zum Patent
  • Wo gibt es überhaupt Ähnlichkeiten zu zentralen Mechanismen des Patents?
  • Wie lassen sich die zentralen Begriffe aus dem Patent auf das verdächtigte Produkt abbilden und gibt es dabei verschiedene Abbildungsmöglichkeiten?
  • Genaue Analyse der Mechanismen im verdächtigten Produkt, bis runter auf die Code-Ebene.
  • Betrachtung verschiedener Abstraktionsebenen: In Software gibt es meist viele Abstraktionsebenen, die in der Entwicklung betrachtet werden können und die sich oft auch in der Verwendung verschiedener Protokolle und Technologien wiederfinden. Welche Ebenen sind für den Vergleich anwendbar und was ist dann die Interpretation der Sachverhalte?
  • Erstellung von Skizzen und Diagrammen, die relevante Abstraktionen und Darstellungen der verdächtigten Software darstellen und die verdeutlichen, wo Unterschiede zu den Mechanismen des Patents liegen.

Je nach ganz konkreter Situation können auch noch weitere Analysen ergänzt werden.

Aufwand realistisch einplanen

Die sehr spitze Bewertungsfrage lässt eine starke Fokussierung der Architekturbewertung zu und erlaubt es, viele Aspekte einer Big Picture Betrachtung, die meistens sehr sinnvoll ist, einzusparen.

Wegen der der Kritikalität der Situation, der organisationsübergreifenden Analyse und Kommunikation, der Menge einzubeziehender Stakeholder und der benötigten Konfidenz muss aber sehr konzentriert und sorgfältig gearbeitet werden.

Für den (bzw. die) Reviewer kann als Größenordnung des Aufwands ein Spektrum von ungefähr 5 – 20 Personentagen angenommen werden, in speziellen Situationen könnte der Aufwand auch noch darüber liegen. Insbesondere die Abstimmung mit Anwälten und die iterierte Aufbereitung der Ergebnisse kann recht aufwändig sein.

Ergebnisse ehrlich und nützlich interpretieren und aufbereiten

Die Analyse aller notwendigen Aspekte muss sauber durchgeführt werden und führt zu zahlreichen Fakten. Das ist aber noch nicht das Ergebnis der Architekturbewertung bzw. des Gutachtens.

Reviewer müssen sich intensiv damit beschäftigen, wie die Erkenntnisse zu interpretieren sind und diese dann so aufbereiten, dass sie von außenstehenden Stakeholdern, vor allem Juristen, gut nachvollzogen werden können.

Dafür ist einiges an Aggregation und Zusammenfassung nötig. Trotzdem muss immer klar nachvollziehbar bleiben, auf welche Erkenntnisse sich bestimmte Schlüsse und Empfehlungen stützen. Diese Art der Aufbereitung braucht signifikant Zeit und sollte auch mit anderen Personen durchgesprochen werden, um die Verständlichkeit und Wirkung sicherzustellen.

Bei der Darstellung sollte viel mit passenden Grafiken gearbeitet werden, die allerdings so schematisch und gut erklärt sein müssen, dass sie auch für Nicht-Techniker, Nicht-Ingenieure und Nicht-Softwarearchitekten intuitiv nachvollziehbar sind.

Mögliche (sehr verkürzte) Ergebnisse aus dem Beispiel von RemoteDeviceRepair:

• Der Begriff „Datenkanal“ ist in der Informatik nicht klar definiert und wird von unterschiedlichen fachkundigen Personen unterschiedlich interpretiert bzw. auch als „unpräziser“ Begriff identifiziert.
• Datentransport zwischen den beiden durch die Software vernetzten Standorte funktioniert dank der Verwendung zahlreicher Standardtechnologien und -protokolle. Diese sind schichtweise aufeinander aufgebaut, nach dem ISO/OSI Schichtenmodell. Von der physikalischen Ebene von tatsächlichen Leitungen und Kabeln bis zur Anwendungsebene mit spezialisierten Protokollen bzw. individueller Entwicklung.
  • Alle diese Ebenen existieren real in der Softwarelösung. Je nachdem wie tief man reinschaut sind bestimmte Aspekte wegabstrahiert oder eben sichtbar.
  • Je nach Betrachtungsebene ändert sich die Zahl der „Datenkanäle“ sehr stark. Z.B. gibt es auf der physikalischen Ebene direkt am angeschlossenen Gerät ein physikalisches Ethernet-Kabel mit mehreren Leitungen. Auf dem Weg zum entfernten Gerät gibt es aber zahlreiche mögliche Wege, die Daten dynamisch nehmen können, was an der Konstruktion von Transportprotokollen liegt. Auf anderen Ebenen gibt es zahlreiche andere mögliche Betrachtungen, wie viele Datenkanäle man interpretieren könnte. Die genaue Ausführung tut hier nichts zur Sache.
  • Die Antwort auf die Bewertungsfrage für das Gutachten besteht dann im Wesentlichen darin, diese komplexe Gemengelage auseinanderzunehmen und verständlich zu erklären. Es gibt keine sinnvolle und eindeutige Antwort auf die Frage, wie viele Datenkanäle verwendet werden und es könnten zahlreiche Ergebniszahlen plausibel mit Argumenten belegt werden.
  • Dieses technische Gutachten muss dann durch Anwälte wiederum in eine rechtliche Interpretation zur Widerlegung der Anschuldigungen überführt werden. Nur im Zusammenspiel der juristischen und der technischen Argumentation kann eine passende Antwort erarbeitet werden

Spezifische Tipps für die konkrete Architekturbewertung

Basierend auf vielen Bewertungsprojekten in einer ähnlichen Situation nennen wir hier noch einige spezifische Tipps, die über die allgemeine Methodik hinausgehen.

• Darauf einstellen, dass diese Art der Architekturbewertung stark von üblichen Vorgehensweisen abweicht. Das erfordert gedankliche Flexibilität und volle Fokussierung auf die präzise herausgearbeiteten Bewertungsfragen.
• Starke und fundierte Kommunikation zwischen Anwälten und technischen Gutachtern aufbauen. Kontinuierlicher Austausch über Argumentationen und Fakten und wie diese verarbeitet werden könnten. Diese Interaktion kann signifikant viel Zeit kosten.
• Mit ambitionierten Zeitplänen rechnen: Oft wurde im Vorhinein recht viel Zeit vergeudet, bis tatsächlich der Entschluss gefasst ist, vor Gericht zu ziehen. Dann soll vieles ganz schnell gehen. Ein Reviewer muss trotzdem auf machbaren Zeitplänen bestehen, um keine kontraproduktiven Kompromisse in der Qualität des Gutachtens einzugehen.
• Darauf gefasst sein, dass manche Stakeholder die Ergebnisse anzweifeln oder in komplett anderer Art interpretieren. Deshalb ist gute Fundierung der Analyse und Interpretation unabdingbar.
• Der Interpretation und Aufbereitung der Ergebnisse besonders viel Aufmerksamkeit schenken und passende Runden an Personen auswählen (eher kleine Runden), um intensiv über die Ergebnisse zu sprechen. Vor allem die Story jenseits der tiefen technischen Analyse muss sehr klar aufgebaut und schlussgefolgert sein.
• Überlegen, wie die Gegenseite argumentieren würde und versuchen, diese Argumente proaktiv aufzugreifen und einzuordnen.

Fazit

„Wir machen ein Architektur-Review“ bzw. „Architektur-Gutachten“ hört sich nach Standard an, ist es aber nicht. Mit dieser weiteren Beispielsituation haben wir einen besonders herausfordernden Fall erläutert, der zeigt, wie eine angepasste Vorgehensweise aussehen kann.

Die Betrachtung von Patenten und möglichen Patentverletzungen ist natürlich sehr vielfältig. Je nach Patentinhalt und Verdacht der Patentverletzung können sehr unterschiedliche Analysen und Betrachtungen notwendig

Richtig aufgesetzt und sorgfältig durchgeführt sind Architektur-Reviews ein mächtiges Werkzeug, mit dem auch in kritischsten Projektsituationen dazu beigetragen werden kann, Klarheit zu schaffen.