Business Driven Solution Architecture

In diesem symZone-Artikel möchte ich euch einen Blick hinter die Kulissen des Secure Service Hub (SSH) geben und zeigen, wie wir eine Anwendungsarchitektur entwickeln, die den ständig wachsenden (Geschäfts-)Anforderungen an moderne Softwarelösungen wie den Secure Service Hub gerecht wird. Der entscheidende Erfolgsfaktor ist für uns, die konsequente Ausrichtung der Softwarearchitektur am Geschäftsmodell und dem damit verbundenen Wertversprechen. Dabei handelt es sich weder um ein neues Software-Entwurfsmuster, noch ersetzt es wertvolle und sinnvolle Muster wie BDD oder DDD (Behavior/Domain Driven Design), die wir ebenfalls verwenden. Es handelt sich vielmehr um eine Philosophie, die wir über alle Grenzen hinweg in der Organisation verankert haben und der sich jeder verpflichtet fühlt.

Technologie macht Spaß, ist herausfordernd und motivierend zugleich, sollte aber nie zum Selbstzweck werden. Die immer kürzeren Zyklen, in denen neue Konzepte der Softwarearchitektur, Frameworks und darauf abgestimmte Programmiersprachen auf dem Markt erscheinen, führen zu einer immer komplexeren Landschaft von Lösungsmöglichkeiten. Betrachtet man die verschiedenen Optionen relativ gekapselt und im Kontext erfolgreicher Anwendungsfälle, so sind sie in der Regel immer valide und wertschöpfend. Die große Gefahr besteht darin, dass Konzepte und Technologien aus Gründen wie der guten Erfahrungen in vorherigen Projekten, vorhandenem Know-how im Unternehmen oder aktuellem Hype im Markt eingesetzt werden, ohne den eigentlich wichtigsten Aspekt – die geschäftlichen Auswirkungen – zu berücksichtigen.

In der heutigen Welt sind es nicht mehr die technologischen Hürden, die die Grenzen des Machbaren definieren – fast jede erdenkliche Funktionalität kann mit entsprechenden Technologien wie etwa KI, Blockchain oder Virtual Reality umgesetzt werden. ABER: Es ist die Sicht auf das Geschäftsmodell, die Kunden, die Branche etc. und die daraus abgeleiteten Anforderungen, die einen entscheidenden Einfluss auf die Architektur und die in einer Lösung eingesetzten Technologien haben sollten.

Es geht also darum zu vermeiden, dass technologiegetriebene Lösungen entworfen werden, wie es leider in vielen Fällen geschieht, unabhängig davon wie viel Erfahrung das Entwicklungsteam hat oder in welcher Domäne die Lösung eingesetzt werden soll. Bei der Konzeption und der Implementierung des Secure Service Hub haben wir uns von genau diesem Ansatz leiten lassen: „Business First-Thinking“.

Ich möchte diesen Ansatz anhand von drei ausgewählten Wertversprechen erläutern, die wir unseren Kunden mit dem SSH bieten wollen. Diese sind:

• Wir halten die Markteintrittsbarriere und die Kosten (TCO – Total Cost of Ownership) so niedrig wie möglich.
• Wir liefern Innovationen in schnellen Zyklen und ohne Auswirkungen auf das Geschäft.
• Wir bieten einen Wettbewerbsvorteil durch optimierte und einfache vertikale sowie horizontale Integration in die IT-Infrastruktur.

So weit, so verständlich. Doch wie ziehen wir daraus die entsprechenden technologischen und architektonischen Schlüsse? Der erste Schritt ist, aus dem Wertversprechen Anforderungen an das Produkt, noch nicht an die Technologie oder Architektur, abzuleiten. Unsere drei obigen Wertversprechen lassen sich zu einer übergreifenden Anforderung zusammenfassen: „das Bedürfnis nach Geschwindigkeit und Agilität“.

Aus dieser Anforderung lassen sich noch keine vielversprechenden Schlüsse ziehen. Im nächsten Schritt brechen wir diese Anforderung nun in kleinere und konkretere User Stories herunter:

„Ich als Kunde möchte…

• …ein dynamisches Abrechnungsmodell, um nur für die in Anspruch genommenen Dienste zu zahlen (Pay-Per-Use) um geringe Investitionskosten zu haben.”
• …eine Lösung, die externen Betrieb und Support bietet, um interne Kosten und Ressourcen zu sparen.”
• …eine Lösung, die schnell Innovationen bereitstellt, um optimal auf Veränderungen in meinem Geschäft reagieren zu können.”
• …die nahtlose Integration in meine heterogene IT-Landschaft, um bestehende und etablierte Geschäftsprozesse unangetastet zu lassen.”
• …

Diese Liste ließe sich noch um viele weitere Punkte ergänzen. Es lässt sich aber bereits erahnen, dass diese Art von konkreten User Stories (sie beschreiben das WAS) bereits sehr valide und wertvolle Hinweise auf Architekturoptionen und einsetzbare Technologien (also das WIE) enthalten. Hier sind einige Beispiele:

• Pay-Per-Use-Geschäftsmodelle lassen sich (für beide Seiten) in einer Cloud-basierten SaaS-Architektur (Software as a Service) optimal umsetzen, da Ressourcen gemeinsam genutzt werden und bei Lastspitzen schnell und automatisch skaliert werden können → im Vergleich zu einer On-Premise-Lösung auf dedizierten Servern / VM’s.
• Ein schnelles und unterbrechungsfreies Rollout von Produktinkrementen ist mit einer Microservice-Architektur betrieben in einem Kubernetes-Cluster möglich, da dies die Entkopplung von Diensten und die Umsetzung entsprechender Rollout-Strategien (z.B. Rolling Updates) ermöglicht → im Vergleich zu einem weniger komplexen monolithischen Ansatz.
• Ein API-First-Ansatz stellt sicher, dass die wichtigsten (oder sogar alle) Funktionen des Produkts über eine API verfügbar sind, und bietet somit eine optimale Unterstützung für die Integration in die IT des Kunden → im Vergleich zu einer eher geschlossenen Architektur, welche z.B. das Customizing- und Beratungsgeschäft eines Unternehmens fördert.

Natürlich gibt es auch hier kein Schwarz-Weiß-Denken, sondern wie immer mehrere mögliche Lösungen. Aber deshalb ist es wichtig, die Technologie- und Architekturexperten im Team zu haben, um eine ganzheitliche Lösung zu entwerfen, die dem Kunden letztendlich den gewünschten Nutzen bringt… und im Idealfall trotzdem Spaß bei der Entwicklung und dem Betrieb macht.

Meiner Meinung nach ist der Ansatz zur Lösung der Architekturfrage recht einfach und offensichtlich. Es ist die Antwort auf die Frage „Für wen und warum entwickeln wir unser(e) Produkt(e) – Für unsere Kunden!” Dementsprechend sollten alle Entscheidungen bezüglich der Architektur und der in einer Lösung verwendeten Technologien auf der Prämisse beruhen, wie sie dazu beitragen, den Wert für unsere Kunden zu maximieren.

Ich hoffe, ich konnte euch mit diesem Artikel einen kleinen Einblick in die Art und Weise geben, wie wir bei symmedia die Softwarearchitektur und den Einsatz von Technologien handhaben. Weitere Details und konkrete Einblicke in die SSH-Architektur werden folgen. Bleibt dran…

Liebe Grüße,

Marius
CTO

PS:
Ihr möchtet mehr zu unserer Architektur wissen?
Ich freue mich auf eure Fragen unter burger(at)symmedia.de