Die Corona Warn App als Vorbild für eigene Projekte

Die Corona Warn App (CWA) ist seit einiger Zeit verfügbar. Die Benutzung ist freiwillig, wer will und kann darf die App verwenden. Da die Entwicklung öffentlich in GitHub erfolgte kann der Quellcode eingesehen werden. So weit wie SAP und die Telekom das ermöglicht haben. Die ersten Entwicklungen erfolgten erst intern und wurden dann auf GitHub veröffentlicht. Normal gelebte Praxis auch bei anderen Unternehmen. Aber hier geht es nicht darum wie oder warum man etwas als Open Source entwickeln sollte, sondern um drei Bereiche, in denen die CWA ein Vorbild oder Orientierung für eigene Projekte sein kann, sollte, oder vielleicht auch nicht.

• Dokumentation
• Entwicklung
• Laufzeit / Architektur

Dokumentation

Wer etwas die Berichterstattung verfolgt hat weiß schon: die Dokumentation wurde über den grünen Klee gelobt. Und zu Recht. Es gibt wenige Open Source Projekte, die eine so gute Dokumentation haben. Es gibt auch wenige proprietäre Anwendungen, die eine Dokumentation haben, die hier mithalten kann. Der Blick der Öffentlichkeit hat hier bestimmt geholfen die Dokumentation nicht zu vernachlässigen. Auch da sie die doch nicht so ganz einfache Funktionsweise der App für viele Menschen verständlich machen muss. Die Dokumentation hat, wie alle Komponenten, ein eigenes Repository bekommen. Das ist vorbildhaft, da einzelne Komponenten sich dann nicht überschneiden. Die technische Dokumentation ist wiederum Teil des dazugehörigen Repositories der Komponente: Beispielsweise beinhaltet die Android App die Dokumentation für sich selbst.

Es gibt eine Vielzahl von Dokumenten, die die einzelnen Aspekte der App detailliert beschreiben:

• Scope: Anforderungen an die Lösung.
• Architektur: Beschreibung der Lösungsarchitektur. Hier gibt es für die einzelnen Komponenten nochmals eigene Dokumente, z.B. für den Server, Verification Server, iOS App, etc.
• Sicherheit: Analyse der identifizierten Risiken.
• Dazu noch GitHub issues.
• Weitere Dokumente

Hier haben SAP und Telekom eine neue Referenz für Projekte geliefert. Für kleine Projekte wird es schwierig sein eine ähnlich hohe Qualität zu liefern. Der Aufwand für die Dokumentation dürfte nicht klein gewesen sein, und man merkt beim Lesen, das die Dokumentation sehr ernst genommen wurde.

Es wurde nicht Arc42 verwendet. Ebenso findet man keine Architecture Decision Records. Die Dokumentation hat dadurch nicht gelitten. Ist das jetzt besser oder schlechter? Ein Arc42 könnte man durchaus erstellen, nur ist es dann ein zentrales Dokument, das schon von der Vorgehensweise alle Komponenten erfasst. Da wird das Dokument dann doch zu umfangreich.

Die Architekturschaubilder sind eine Klasse für sich. Zum Erstellen dieser wird TAM verwendet. TAM wird innerhalb der SAP verwendet. Außerhalb, und das fängt schon bei eigentlich internen Organisationen wie SAP Consulting, wird TAM selten verwendet. Bei Partnern und Kunden findet man TAM schon so gut wie gar nicht mehr. TAM bietet einen Mehrwert, das kann man gerade wieder bei der CWA Dokumentation sehen und den Reaktionen von SAP Fremden, die die Architekturbilder gesehen haben. Wer TAM benutzen will: TAM Stencils kann man bei SourceForge downloaden (270 Downloads in den ersten 6 Monaten in 2020, 469 in ganz 2019). Diese können dann in Visio verwendet werden.

Vielleicht kann SAP das Feedback zur CWA Dokumentation verwenden, um TAM etwas mehr zu promoten? Oder Tools wie den SAP Enterprise Architecture Designer Interessierten bereitzustellen?

Entwicklung

Die Entwicklung einer jeden Komponenten erfolgt in einem eigenen Repository. Diese enthalten alle Informationen die notwendig sind diese Komponente zu verstehen, entwickeln und zu kompilieren. Die Komponenten können lokal kompiliert und gestartet werden, wo möglich auch in Docker. Eine Cloud Laufzeitumgebung ist nicht notwendig.

Anstatt auf den neuesten Trend zu setzen werden langweilige Technologien verwendet. Die Backends verwenden Java, die iOS App verwendet UIKit und nicht SwiftUI. Anstatt was Eigenes zu Programmieren wird auf bewährte Software zurückgegriffen, z.B. PostgreSQL, SQLCipher, Keycloak, etc. Das hilft auch externen Entwicklern, die die App sich anschauen wollen: proprietäre Frameworks müssen nicht verstanden und gelernt werden.

Viele Methoden haben die API kommentiert, andere aber auch nicht. Innerhalb der Methode ist selten ein Kommentar zu finden. Ich bin kein großer Anhänger des Mantras das Code selbsterklärend sein soll. Falls die Methodenbeschreibung nicht deutlich erklärt was gemacht ist, warum nicht noch kurz erläutern was im Code passiert? Kann aber auch sein das hier noch nachgeliefert wird. Die Priorität war ja auch eine App zu liefern die funktioniert, nicht eine Referenz für Source Code Kommentare.

Laufzeit und Architektur

Dieser Teil ist der interessanteste der ganzen CWA App, vor allem wenn man SAP Kunde ist. Die Architektur des CWA Backends ist gut dokumentiert. Diese ist wohl von Telekom Mitarbeitern geschrieben worden. Die Diagramme unterscheiden sich von denen der App Dokumentation. Wie oben schon gesagt: TAM ist gut, aber unbekannt.

Als Cloud dient die Open Telekom Cloud (OTC). Damit kommt auch fast automatisch Sicherheitsfeatures wie DDOS, CDN, VPC, Tracing, Logging und vieles mehr. Die Laufzeitumgebung ist AppAgile (OpenShift), also Kubernetes. Die CWA Backends laufen in einer modernen Umgebung. Es gibt keine Dienste die nur OTC bietet. Man könnte die App auch mit geringem Aufwand auf einer anderen Cloud laufen lassen. Wenn jemand eine neue App bauen will und nicht weiß wie diese in der Cloud laufen soll ist die CWA Architektur und OTC eine gute Orientierung. Unabhängig davon ob man OTC, Azure, AWS oder was anderes nehmen will.

Warum ist das jetzt interessant, wenn man SAP Kunde ist? SAP hat seine eigene Cloud (SCP), damals – 2012 – gestartet als generelle Cloud. SAP nannte sich sogar THE cloud company. In der CWA App findet sich nichts von den in den letzten knapp 10 Jahren von der SAP vermarkteten SCP Lösungen: SCP, HANA, Cloud Foundry, XSA, OData, Fiori, usw. Die ganzen SAP Technologien und Dienste sind schon sehr früh durch die Auswahl gefallen: die App soll viel Open Source verwenden und dazu modernes cloud native verwenden um Millionen von Nutzern zu unterstützen. Plus: Ausfallsicherheit. Ich kenne nicht die SLA und wie stabil OTC ist. Von meiner Erfahrung mit SCP aus sage ich mal: ist bestimmt besser.

Die SAP hat in der SCP z.B. einen Service für mobile Apps (SCP Mobile Services), dazu ein SDK für native Anwendungen, sogar mit Apple Partnerschaft. Man hätte durchaus die App mit dem Fiori for iOS SDK entwickeln können und SCPms verwenden. Aber dann wäre die Lösung von Kommentatoren als unfrei zerlegt worden. Es fehlen aber nicht nur Dienste und Tools, sondern jegliche Ansätze, die in der SCP gepredigt werden. In der SCP hat man die Wahl zwischen was Eigenem (Neo) oder Cloud Foundry. CWA zeigt deutlich, dass wenn man heute eine moderne cloud native App entwickelt, dann nimmt man Kubernetes. Persönlich finde ich es auch gut das man OpenShift verwendet und kein nacktes Kubernetes.

SCP ist für die Erweiterung von ERP Anwendungen aus dem SAP Umfeld. Hier ist die eindeutige Konsequenz: wer SAP Anwendungen erweitern will: nehmt SCP. Wer Lösungen aus der App Economy hat, cloud native, nicht SAP zentrierte Lösungen hat: nehmt nicht SCP. Die SCP ist eine gute Wahl in der Nische die die SAP dafür gefunden hat. Wer vor Jahren sich in SCP eingekauft hat und versucht jetzt damit Lösungen zu bauen und zu betreiben die nicht in die Wohlfühlzone von SCP passen: die Migration auf eine andere Cloud muss Priorität haben. Mir tun die SAP Kunden leid die sich vor wenigen Jahren noch auf die SCP als generelle Cloud eingelassen haben oder auf die Versprechen bezüglich cloud native mit SCP und HANA gehört haben. Zu versuchen eine App zu entwickeln mit HANA, XSA und SCP und Fokus auf Kunden (App Economy) ist wahrlich ein Wagnis.

Zusammenfassung

Abschließend bleibt nur noch kurz fest zu halten in welchen Bereichen CWA ein Vorbild für eigene Projekte sein kann.

• Dokumentation: umfangreich, aber nicht zu komplex und Grafiken sind besser als Text.
• Softwarearchitektur: verwenden von bewährten Technologien, Wiederverwendung von Bibliotheken, Eigenentwicklungen vermeiden.
• Repositories: Code trennen, aber alles was man benötigt, um eine Komponente zu verstehen und zu bauen zusammenhalten.
• Container: Bei der Entwicklung schon auf Container setzen und nicht erst nachträglich als letzter Schritt.
• Laufzeit: OpenShift, cloud native und weitere Dienste wie DDoS, CDN, etc nutzen. Kein nacktes Kubernetes oder gar selbst versuchen das selber aufzuziehen.
• Zuerst die Pflicht, dann die Kür. Manches dauert lange bis es implementiert ist, z.B. Unit und UI Tests, kann aber für den ersten Release auch als Optional gesehen werden.