Bernd Rücker ist bei uns zu Gast. Vor ein paar Wochen ist sein Buch “Practical Process Automation” erschienen und dies ist der Anlass für unser heutiges Gespräch. Was kannst Du erwarten? Wir werden uns über einige Inhalte des Buches unterhalten, aber auch das Buch in einen Kontext setzen. Du erfährst auch, was ein eher technisches Thema an organisatorische Auswirkungen hat, warum Bernds Lieblings-T-Shirts den Schriftzug ‘it depends’ tragen.
Bernd Rücker ist seit mehr als 15 Jahren Softwareentwickler und hat seinen Schwerpunkt im Bereich der Geschäftsprozessautomatisierung. Er ist Contributor zu zahlreichen Open-Source-Projekten, Sprecher auf zahlreichen Konferenzen und Gründer von Camunda, einem Anbieter für Process und Decision Automation-Software, und wir kennen uns schon seit vielen Jahren. Kurze Zeit nach der Gründung hatten wir die ersten Kontakte und MINAUTICS arbeitet seitdem freundschaftlich mit Camunda immer wieder zusammen.
BJOERN: Hallo Bernd, ich freue mich außerordentlich über dieses Gespräch. Wie geht es Dir?
BERND: Du hast ja auch ein bisschen mitbekommen, wie Camunda gerade läuft. Was Camunda angeht, läuft alles supergut. Das lässt auch mich mit guter Laune dastehen. Ich sehe langsam, wie das voran geht und welchen Impact es hat. Ich sehe auch, welche Veränderungen wir als Camunda bewirken können. Das ist supercool. Da geht es mir gut.
BJÖRN: Sehr schön. Das freut mich zu hören. Am 18. Mai ist dein Buch „Practical Process Automation“ erschienen. Wir erleben den Erfolg der Camunda-Produkte, wie kommt es denn dazu, dass das Buch notwendig war? Was hat dich dazu bewegt noch ein Buch zu schreiben?
BERND: Das waren mehrere Dinge. Einmal ist es so, dass ich von meiner Rolle her viel über Architektur nachdenke. Ich denke über die Probleme nach, die unsere Kunden eigentlich haben und wie unsere Produkte helfen, diese Probleme zu lösen. Das ist mit einer sehr technischen Brille, worüber ich eigentlich wirklich nachdenke und ganz viel mit Kunden agiere. Aber dann spreche ich auch eben gerne darüber. Das ist dann bei Vorträgen, auf Konferenzen und so. Früher ist man da noch hingefahren, hat so richtig miteinander gesprochen, mit Leuten diskutiert. Das hat mir sehr viel Spaß gemacht.
Dabei habe ich auch sehr viel gelernt über die Fragestellungen, die da draußen existieren und auch über die Missverständnisse, die so existieren. Ich habe dann mehr und mehr ein Bild zusammengesetzt und gedacht, dass, was die Entwicklerwelt von BPM oder auch Prozessautomatisierung denkt, so irgendwie nicht richtig ist. Das hat mich immer sehr gewurmt, weil ich gesehen habe, welchen Nutzen es eigentlich stiften kann und wie cool es in Projekten wirklich ist. Dieser Gap tut mir immer ein bisschen in der Seele weh. Mit diesen Learnings habe ich sehr viele Dinge besser verstanden, glaube ich. Ich habe verstanden, wie man sie vielleicht besser erklären kann, wie sie zusammenhängen.
Ab einem gewissen Punkt dachte ich mir, dass meine Mission irgendwie ist diese Prozessautomatisierungstechnologie zu den Entwicklern zu bringen und da ein Buch zu schreiben. Das war auch für mich nochmal eine schöne Übung. Jeder kennt das, dass man, wenn man Dinge aufschreibt, merkt, dass da ein Handlungsloch ist. Das muss ich irgendwie schließen. Das war cool. Das hat mir tatsächlich Spaß gemacht, auch wenn es tatsächlich sehr anstrengend ist.
BJÖRN: Corona hat dann ein bisschen Freiraum verschafft, um ein Buch zu schreiben?
BERND: Ja. In der Tat hat diese Veränderung des Arbeitsalltages einen Effekt gehabt. Ich war vorher die ganze Zeit am Reisen. Jetzt konnte ich mich mal auf das Rennrad schwingen, wenn ich über etwas nachdenken wollte. In der Tat war das für das Schreiben jetzt super. Und auch andersherum muss ich sagen, hat mir dieses Projekt tatsächlich ganz gut über die Corona Zeit geholfen.
BJÖRN: Da ist jetzt ein Buch entstanden, dass im Grunde die Zielgruppe Softwareentwickler hat. Am Markt positionieren sich ja jetzt noch so Low-Code-Anbieter. Ist dein Ansatz, den du in dem Buch beschreibst, da kompatibel?
BERND: Das ist die Diskussion, die ich momentan am spannendsten finde. Wir als Softwarehersteller, aber auch die Positionierung des Buches, geht ja eher in Richtung Pro-Code, oder Professional-Software-Developers. Ich nenne es immer gerne developer-friendly. Die Grundidee ist, also Technologie wie eine Workflow-Engine, die Methodik und die BPMN in der Welt der Entwickler gelebt werden. Die schreiben immer noch Codes, Tests und machen Continious-Integration und Deployment, wie sie es sonst auch machen. Die benutzen ihre normalen Praktiken. Und das ist sozusagen Pro-Code. Dem gegenüber steht Low-Code, was gerade ganz stark gehypt wird. Da ist die Grundidee eine ganz andere, nämlich eher, es, ohne den Professional-Developer zu schaffen. Was jetzt genau der Low-Code-Developer ist, welche Persona, welche Ausbildung, ist wahrscheinlich nochmal ein ganz eigener Podcast. Da kann man lange drüber diskutieren. Aber es ist kein unbedingt in dem Sinne ausgebildeter Informatiker, der wirklich programmieren kann. Und diese Abgrenzung, die es momentan gibt, finde ich superspannend.
Aus meiner Sicht vielleicht mal kurz gesagt: Ich glaube einfach daran, dass es gewisse Use-Cases gibt, die ich vielleicht sogar gut mit Low-Code automatisieren kann. Und es gibt Prozesse, die mit Pro-Code automatisiert werden sollten. Im Moment passiert es, dass die falschen Prozesse mit den falschen Tools angefasst werden. Und das ist sehr gefährlich. Nur mal als Beispiele. Ich finde zwei Dimensionen spannend sich anzusehen. Einmal: Was automatisiere ich hier? Ich könnte einen einzelnen Task, also nur eine Aufgabe, in einem Prozess automatisieren, in einem größeren Prozess. Aber nur in einem Schritt. Und das ist das, war RPA, also Robotic-Process-Automation gerade viel macht. Aber das automatisiert üblicherweise ein Task. Es automatisiert keinen kompletten Geschäftsprozess in mehreren Schritten. Habe ich hier zwei Systeme, die ich miteinander integriere, die vielleicht noch in der Cloud stehen und, wo es einen super Low-Code-Connector gibt? Dann ist das vielleicht mit Low-Code machbar. Das geht vielleicht gut. Oder habe ich hier meine heterogene IT, wo ich bei einem Prozess 30 Systeme integrieren will, für die es auch ganz sicher keinen Connector gibt. Dann ist das eine andere Geschichte.
Da gibt es noch ein paar mehr Dimensionen, die man sich angucken kann. Und dementsprechend hat beides, glaube ich, seine Berechtigung. Ich persönlich gucke mir klar die Pro-Code-Seite an. Das Buch fokussiert auch genau darauf.
BJÖRN: Was sind beim Thema Pro-Code-Prozessautomatisierung die Essentials, die ich brauche, um aufgabenübergreifend, Ende-zu-Ende, Prozess-zu-Prozess, zu automatisieren?
BERND: Gar nicht so viel eigentlich. Man kann das Thema sehr groß sehen. Wenn man es aber mal im Kern betrachtet, dann ist das aus meiner Sicht erstmal die Workflow-Engine, wie ich es nenne. Es gibt verschiedene Begriffe dafür. Man kann es auch Orchestration-Engine nennen, oder Process-Engine. Die sich Zustände merken. Also: Wo im Prozess stehe ich gerade? Und das ist aus meiner Sicht eigentlich sogar die wichtigste Funktionalität, weil ich damit langlaufende Prozesse ermöglichen kann. Dann will ich sehen, wenn die da zu lange warten und will eskalieren. Und so weiter. Da gibt es den ganzen Zoo, der daraus entsteht. In Essenz ist es für mich aber eigentlich diese Workflow-Engine, die ich brauche.
BJÖRN: Okay. Die Camunda-Engine ist ja, so wie ihr sie anbietet, BPMN-basiert. Welche Rolle spielt für dich BPMN als Modellierungsstandard in dem Kontext?
BERND: Vielleicht für alle, die es nicht kennen. BPMN ist ein ISO-Standard, wie ich solche Prozessmodelle malen, also modellieren kann. Aber ich kann eben nicht nur die Grafik malen, sondern auch, wie so eine Engine das dann direkt ausführt. Das ist alles mit definiert. Und das ist sehr mächtig. Die BPMN hat von den Sprachkonstrukten, die sie so kennt, genügend Möglichkeiten, dass man alle Probleme ausdrücken kann, die man draußen so findet. Das heißt, dass sie sehr mächtig ist. Auf der gleichen Seite, sehr lesbar visuell, für verschiedene Zielgruppen. Also eben nicht nur für den Entwickler, sondern auch für Business-Analysten, aber auch für Fachbereiche und Endbenutzer. Die müssen es oft nicht modellieren. Aber mit denen kann ich trotzdem darauf schauen und sie verstehen das, wenn ich es mit ihnen durchlaufe. Und das ist mächtig. Dann können sie eben auch ihren Input dazu geben. Und zur gleichen Zeit, ist es sehr verbreitet. Ich kenne keine andere Notation, die so verbreitet ist. Es gibt sehr viele Tools, die es unterstützen. Es gibt viele Engines, die das unterstützen. Es gibt sehr viele Trainings und Bücher. Also alles, was mit dieser Verbreitung zusammenhängt. Und da gibt es aus meiner Sicht eben nichts adäquat Vergleichbares. Was mich gerade immer so schmerzt, wenn wir in die Tekkie-Welt, oder auch so in die Cloud-Welt hineinschauen, oder man könnte ja mal ganz konkret auf Amazon schauen. Die haben auch so ein Workflow-Tool in ihrer Cloud. Bei denen heißt das Step-Functions. Die haben sich zum Beispiel ihre eigene Sprache ausgedacht. Das war auch vor zehn Jahren. Das ist die Amazon-State-Language. Und das ist ein bisschen prototypisch für das, was andere in dieser Welt auch machen. BPMN ist zu komplex. Wir brauchen nur was Einfacheres.“ Und das ist interessant. man kann sich diese Amazon-Language mal ansehen und wird feststellen, dass sie über die Jahre immer neue Konstrukte erweitert haben, wo man immer sagen kann, dass das das ist in BPMN und das, das, und so weiter. Warum? Wenn sie eben doch reale Prozesse abbilden, dann kommen sie irgendwann zu diesen Problemen und müssen sie ausdrücken können. Und da hat BPMN einfach diesen Reifeprozess hinter sich. Ich sehe keine guten Gründe, warum man es nicht einfach anwenden sollte. Das ist einfach sehr mächtig. Wir machen so gute Erfahrungen damit. Es gibt Vorbehalte, aber wenn es dann eingesetzt wird, ist es supermächtig.
BJÖRN: Du hast gerade schon den Hinweis gebracht, auf das BPMN-Praxis-Handbuch. Bernd und Jakob Freund, haben zusammen das Praxishandbuch BPMN 2.0 im Hansa Verlag veröffentlicht, welches seit Jahren erfolgreich und mittlerweile in der fünften Ausgabe ist. Es vermittelt Einsteigern Einblicke in die Business Model and Notation. Das Buch ist auf Deutsch, Englisch und Spanisch verfügbar. Für Interessierte verlinken wir das Buch auch im Beitrag. Oder euch wird eine Suche beim Buchhändler eures Vertrauens sicherlich helfen.
BERND: Ich wollte es gerade hochheben, aber es liegt zu weit weg.
BJÖRN: In deinem Buch vertrittst du die Meinung, dass sich alles orchestrieren lässt. Das Kapitel 4 ist sogar mit den Worten „Orchestrate Anything“ überschrieben. Kannst du ausführen, was du damit meinst? Gibt es da vielleicht auch Grenzen in der Praxis?
BERND: Ja. Was man vielleicht dazu sagen sollte, je nachdem, wer das jetzt hört, dass das auch ein bisschen die technische Sichtweise darauf ist. Orchestrierung heißt für mich, dass es eine Komponente gibt, die einer anderen sagt, was sie in diesem Moment tun soll. Dann orchestriere ich den anderen. Und in dem Sinne kann man wirklich auch alles orchestrieren. Zum Beispiel Menschen. Das klingt jetzt echt am blödesten: „Ich orchestriere einen Menschen.“ Aber de facto heißt das einfach, dass die Maschine mir sagt, wann ich dran bin. Sie guckt auch, wann ich fertig bin. Oder ich sage der Maschine, wann ich fertig bin. De facto kennen wir das alle. Und meistens freuen wir uns darüber, wenn unser Kalender uns sagt: „Hey. Du musst noch das und das machen.“ Es gibt viele Beispiele, wo ich dann den Menschen orchestriere. Und genauso orchestriert so eine Workflow-Engine auch andere Dinge. Das sind irgendwelche Service-Aufrufe, irgendwelche Micro-Services, irgendwelche RPA-Bots, und so. RPA hatten wir ja gerade schonmal kurz angesprochen. Aber auch echte Roboter werden orchestriert. In Pharma-Labs habe ich gesehen, wie echte Roboter angesteuert werden. Denen wird dann gesagt, was die zum Beispiel zu tun haben. Serverless-Functions, irgendwelche Entscheidungen, und so weiter.
Eigentlich kann man alles orchestrieren. Das heißt nur, dass ich in einem Prozess sage: „Okay. Jetzt kommt das. Und wenn das fertig ist, dann kommt als nächstes jenes.“ Das ist Orchestrierung. Da kann man erstmal alles orchestrieren. Man kann sicherlich darüber streiten, aber aus meiner Sicht gibt es einfach keine Grenzen. Es gibt so viele Programmiersprachen und Libraries. Es gibt so viele Möglichkeiten. Ich kann damit ansteuern, was ich möchte. Und daher auch dieses Orchestrate Anything.
BJÖRN: Wir laufen ja immer mehr in Richtung Cloud. Ihr habt selbst auch ein Produkt am Start, welches Cloud-native ist. Ohne jetzt auf euer Produkt einzugehen: Was bedeutet denn eine Workflow-Engine, wenn ich mit Cloud-Services und -Applikationen arbeite? Gibt es da ein Szenario, wo du sagen würdest, dass das total Sinn ergibt? Oder wie muss ich damit arbeiten, wenn ich solche Komponenten einbinden möchte?
BERND: Es ändert die Architektursichtweise ein bisschen. Vielleicht auch kurz noch zur Abgrenzung, weil man das dann besser verstehen kann: Wenn wir so zehn Jahre zurückschauen, dann haben wir mit Workflow-Engines Architekturen gebaut, wo wir sagten, dass es hier eine eigebettete Workflow-Engine gibt. Ich baue mir ein Stück Anwendung, die ist wirklich programmiert. Und da binde ich die Workflow-Engine ein für die langlaufenden Aspekte. Und wenn ich dann einen Service zum Beispiel aufrufen will, schreibe ich mir ein Stück Glue-Code, was dann zum Beispiel einen Rest-Call macht, oder einen Soap-Web-Service-Call, oder so. Und dann war das sozusagen ein Ding.
Und das funktioniert mit Cloud nicht mehr so wahnsinnig gut. In Cloud ist die Sichtweise ein bisschen anders. Ich habe in der Cloud so eine Fähigkeit, wie zum Beispiel eine Datenbank, oder eine Workflow-Engine. Und die möchte ich eben benutzen. In die Workflow-Engine kann ich ja nicht mehr Code reinpacken. Das ist ein Dienst, der für mich betrieben wird in der Public-, oder vielleicht meiner Private-Cloud. Ich muss, wenn ich Service-Tasks baue, ein Stück Glue-Code schreiben. Wir nennen das dann Pull statt Push. Der Glue-Code fragt dann bei der Workflow-Engine nach, ob er gerade etwas zu tun hat. Das ist ähnlich, wie das auch ein Mensch machen würde in seiner Aufgabenliste. So: „Hey. Soll ich gerade eigentlich was tun?“, und dann sagt mir die Workflow-Engine: „Ja. Hier sind noch 30 Rest-Calls zu machen.“ Und der macht das dann. Aber durch dieses Drehen, dass die Workflow-Engine nicht mehr aktiv dies abholt, sondern ich es abhole, trenne ich die Zuständigkeiten. Und das erlaubt mir dieses Deployment in der Cloud auch sehr einfach. Dann kann ich auch sagen, dass die Workflow-Engine in der Public-Cloud bei uns läuft, oder im Amazon-Account, wenn man das möchte. Und meine Anwendung läuft aber on premise. Ich will mein DSC/ERP-System on prem anbinden. Das könnte man tun. Es ist relativ flexibel, wie man das einfach aufbauen kann. Und in diese Richtung gehen Architekturen mit Cloud und Cloud-native heute. Da passt es ziemlich gut rein.
BJÖRN: Du sprichst in dem Buch von ‚Orchestration‘ und ‚Choreografie‘. Das adressiert a auch vielleicht ein Stück weit dieses Thema. Kannst du vielleicht kurz erklären, was damit gemeint ist? Was sind die beiden Unterschiede?
BERND: Ja, gerne. Das ist eine meiner Hauptdiskussionen, die ich die letzten fünf Jahre hatte. Moderne Architekturen sind oft aus Micro-Services, Event-getriebenen Architekturen, und oft auch noch Ideen aus Domain-Driven-Design. Das wird oft so vermischt. Das ist dann so die moderne Architektur. Und da kommen ganz viele Gedanken zu Choreografie rein. Was ist eine Choreografie? Von der Idee her sagt man: Es sind eigentlich so eventgetriebene Komponenten. Diese Metapher gibt es oft, dass ich verschiedene Micro-Services habe und es jetzt keine zentralen Dirigenten gibt, die das steuern, sondern interagieren die frei miteinander, wie in einer Tanzchoreografie. Die wissen, welchen Regeln sie folgen. In der Praxis heißt das dann typischerweise eventgetrieben. Zum Beispiel: Ihr bestellt in irgendeinem Web-Shop. Und das muss ich jetzt implementieren. Jetzt könnte es ja sein, dass, wenn ihr bestellt, irgendwo intern ein Event erstellt wird: „Hey. Da hat jemand bestellt.“ Darauf könnte so ein Bezahlen-Micro-Service reagieren und sagen: „Oh, da muss ich jetzt reagieren und Geld besorgen.“ Dann könnte der ein Event erzeugen, das sagt: „Bestellung bezahlt.“ Und dann könnte eine Lagerkomponente sagen: „Oh. Da ist eine bezahlte Bestellung. Die Ware muss ich reservieren.“ Durch diese Events entsteht ja auch quasi ein automatisierter Prozess. Den habe ich aber nirgendwo ausgedrückt. Man spricht von Emergin-Behaviours. Das entsteht zur Laufzeit. Und das war superangesagt. Das ging mindestens bis vor fünf bis sechs Jahren. Da war das ein Megatrend. Und da haben alle gesagt: „Hey. Das musst du machen. Das ist super entkoppelt, weil ich dann nicht mehr die zentrale Prozessmaschine habe, die wie die Spinne im Netz alles steuert. Das ist ja böse. Wir wollen unsere Organisation skalieren. Wir wollen unabhängige Teams haben, die Services unabhängig bauen. Die müssen entkoppelt sein.“
Ich hatte damit aber ganz große Bauchschmerzen. Aber ich sage mir dann: „Ihr versteht doch gar nicht mehr, wie dieser Orderprozess überhaupt läuft. wenn ihr den wirklich mal verändern müsst, wird das schwierig.“ Das Beispiel mag ein bisschen weit hergeholt sein, aber ich mache gerne das Beispiel: „Dreht doch mal die Reihenfolge von Bezahlung und aus dem Lager holen, weil ihr zuerst was aus dem Lager holen und Reservierungen checken wollt.“ Also: „Dreht irgendeine Reihenfolge von Schritten.“ Und dann muss man auf einmal zwei oder drei Micro-Services anfassen. Dann muss man diese Events, die da durch die Gegend geschickt werden, verstehen. Das ist echt schwierig. Und dabei muss man mit verschiedenen Micro-Services agieren. Das war eben genau nicht die Idee. Damit kann man eigentlich ganz gut zeigen, dass es nicht entkoppelt ist. Es gibt auch den Begriff der Domänenkopplung. Immer, wenn ich eine fachliche Beziehung, aufgrund des Prozesses haben möchte. Ich möchte halt nur Ware rausschicken, die bezahlt ist. Das ist eine fachliche Abhängigkeit. Und die kann ich ja nicht technisch wegbekommen. Das ist eine Denkfalle, in die viele Leute reinlaufen. Aus meiner Sicht ist Orchestration nicht command-driven, sondern ich will, dass etwas passiert. Wenn ich die Komponente bin, dann sage ich einer anderen Komponente: „Mache etwas für mich.“ In dem Order-Fullfillment-Beispiel wäre das ein eigener Micro-Service, der einfach diesen Order-Fullfillment-Ablauf sozusagen steuert. Der kann immer noch auf Events reagieren. „Hey. Da sind Bestellungen eingegangen. Cool, dann mache ich das jetzt.“ Der ist dann aber verantwortlich und zuständig das zu steuern. Dann sagt der zum Beispiel dem Bezahlen-Ding: „Jetzt zieh Geld für mich ein.“ Und dann kann der diese Abhängigkeiten steuern wie: „Erst wenn Geld da ist, wird es im Lager gemacht.“ Und das ist Orchestration, also quasi jemanden befehlen. Eventgetrieben ist immer: „Hier ist was passiert. Hallo Welt. Das ist nicht mehr mein Problem.“ Das ist sozusagen eine andere Sicht der Verantwortung. Will ich, dass was passiert? Oder sage ich einfach der Welt, dass da was passiert ist und mache nicht mehr weiter?
Das Interessante ist, dass man, wenn man eine Architektur sinnvoll aufbauen will, oft ein bisschen von beidem braucht. Das wurde ganz viel falsch verstanden in der Vergangenheit. Oft kam das aus diesem Hype raus. Da hieß es: „Hey, wir machen es modern. Wir entkoppeln. Wir machen eventgetrieben.“ Man muss ja sagen, dass das der Gegentrend war zu dem was vor zehn Jahren war. Da sagte man: „Wir machen BPM und SOA. BPM ist der große Orchestration-Layer, der alles kontrolliert.“ Das war sozusagen auch Mist. Dann kam das Gegenpendel. Das hat auch nicht funktioniert. Was ich versuche in dem Kapitel hinzukriegen ist, ein bisschen mehr Guidance zu geben: Wie kann man denn einen sinnvollen Mittelweg finden?
BJÖRN: Das heißt, dass die Workflow-Engine jetzt nicht mehr ein Orchestration-Layer, sondern ein Orchestration-Service ist im Verbund der Services?
BERND: Ja. Beziehungsweise ist es eine Orchestration-Capability, die einen Service benutzt. Tatsächlich nicht dieser Layer. Das ist das Wichtige. Wenn man solche super-high-level PowerPoint Architektur-Bilder malt, dann ist das ein kleiner Unterschied. Aber der Unterschied ist entscheidend. Ich habe nicht den Prozess-Layer, der dann oft drüber saß, sondern ist der Prozess selbst ein Bestandteil eines Services. Andersrum gedacht: Ich habe Order-Fullfillment als einen Micro-Service. Der hat zufällig einen Prozess drin. Vielleicht hat ja Zahlung auch einen Prozess drin, weil ich irgendwie Überweisungen annehmen. Dann muss ich auch auf die Überweisung warten und erinnere meinen Kunden. Das ist doch auch irgendwie ein langlaufender Prozess. Das ist in diesen Micro-Services quasi gekapselt. Das sehe ich gar nicht von außen. Und das ist der entscheidende Unterschied in der Denke. Und der funktioniert auch sehr gut. Das ist aus meiner Sicht sehr erfolgreich eigentlich.
BJÖRN: Wenn ich mal an unsere Praxisprojekte denke, denken die meisten Kunden an Orchestration-Layer. Die wollen irgendwie eine zentrale Infrastrukturkomponente nutzen, die dann von da aus irgendwie orchestriert. Was heißt den das für die Projektorganisation, wenn ich jetzt nicht den Orchestration-Layer will?
BERND: Es ist wahrscheinlich einfach die Kunst, wie man diese Services schneidet. Da gibt es ganz große Diskussionen in der Community. Ich glaube, dass das der spannendste Punkt ist. Zumindest bei größeren Organisationen, ja? Wenn ich es gut mache, dann ist a das Ziel, dass die Teams weniger miteinander kommunizieren müssen. Da soll viel in einem Team zusammengezogen werden, die arbeiten nur im Inneren, aber nach Außen habe ich aber möglichst wenige und stabile APIs. Das alles soll ein bisschen einfacher werden. Man kann das, glaube ich, auch recht leicht verstehen. Wenn ich das mit vor zehn Jahren vergleiche: Man hatte sein BPM-Team. Man hatte sein Datenbänkler-Team. Da muss ich für jedes Stück Funktionalität automatisch mit anderen Organisationseinheiten kommunizieren. Wer kennt nicht diese Jira-Tickets: „Da müssen die Datenbänkler mir noch dies anlegen.“, „Der muss mir noch das anlegen.“, und so weiter. Und dann muss ich mir vielleicht noch ein Word-File auflegen, weil mein offgeshoreter IT-Dienstleister das sonst nicht macht. Keine Ahnung. Genau diese Probleme will man versuchen zu lösen. Man will die komplette Funktionalität, was es technisch braucht, in einem Team koppeln. Wenn du das noch mit gewissen Cloudgedanken zusammenbringst, dass die sich per Klick gewisse Dienste, wie eine Datenbank, eine Workflow-Engine oder was auch immer provisionieren können, dann funktioniert das ja auch eigentlich ganz gut. Das sollte eigentlich zu weniger Kommunikation führen, sodass die Teams ein bisschen mehr können. Aber was ich vorhin meinte: Diese Domänenkopplung, die wir natürlich trotzdem haben, bleibt. Die muss ich immer noch irgendwie klären.
BJÖRN: Wenn man jetzt mal an gemeinsame Ressourcen wie eine Taskliste oder so denkt, wenn ich mehrere Teams habe, die potenziell mehrere Engines laufen haben, muss ich das ja konzeptionell schonmal zentral durchdenken, wie ich das gestalten möchte, richtig?
BERND: Das stimmt. Es gibt gewisse Themen, die man sich zentral schonmal angucken sollte. Das muss aber auch nicht immer global unternehmenszentral sein. Bei Tasklisten könnte es ja sein, dass ich verschiedene habe. Vielleicht verschiedene Usergruppen. Aber wenn ich jetzt an typische Versicherer denke: Die haben dann ihre Agents da sitzen. Natürlich wollen die, dass die eine Taskliste bekommen. Aber interessanterweise war das auch immer schon so. Wir haben ganz viele Projekte gehabt, wo man die Tasks in andere Tools gepusht hat, weil die schon draußen im Feld waren. Weil man Tasklisten auch schon benutzt hat, bevor man die Workflow-Engine eingeführt hat. Oder, weil man eine andere Workflow-Engine von früher hatte. Die wenigsten Kunden haben eine Workflow-Engine und dann ist alles out of the Box und alle sind happy. Das Problem habe ich ein Stück weit sowieso. Und das heißt: Ja es stimmt. Das sollte ich dann einmal zentral klären. Viele Kunden bauen dann auch tatsächlich ihre eigene Oberfläche. Zumindest, wenn sie viele User für ihre Taskliste haben, lohnt es sich ja manchmal auch da ein bisschen zu gucken, wie effizient die dann wirklich tickt. Da noch ein bisschen was rauszutunen, wenn da täglich 3000 bis 4000 Leute mitarbeiten, lohnt sich dann einfach.
BJÖRN: Ich würde gerne nochmal ein bisschen bei den Projekten bleiben. Also bei den Beteiligten. Wir haben schon festgestellt, dass Kommunikation essenziell ist. Zum Beispiel über die BPMN, weil ich da die Transparenz, nicht nur für den Softwareentwickler, sondern auch für die Fachbereiche und Business-Analysten, oder Anforderungssteller machen kann. Du beschreibst ja in deinem Buch ein Szenario, das mit einer schönen Redewendung endet. Ich will zitieren: „Everybody loves you and the World is Unicorns and Rainbows.“ Das ist der letzte Satz dieser Szenariobeschreibung. Was da technisch passiert, haben wir jetzt glaube ich besprochen. Kannst du da vielleicht noch ein Wort verlieren, wie so eine Projektkonstellation aussieht, damit das gut funktionieren kann? Das technisch umzusetzen ist ja das eine, aber für Unicorns und Rainbows braucht es ja vielleicht noch mehr. Und wenn die Nebenfrage noch gestattet ist: In welchem Zustand warst du eigentlich, als du die Formulierung gefunden hast?
BERND: Das war aber natürlich bewusst ein bisschen überspitzt. Im Prinzip: Was sehen wir? Wir sehen schon viele recht erfolgreiche Projekte. Ich bin persönlich gerade bei den ersten Projekten dabei. Das ist dann sowas wie Proof-of-Concept, oder Leuchtturm. Was wir sehen ist: Wenn man da die richtigen Leute zusammenbringt, was für mich einen möglichst großen Mix bedeutet, dass das gut ist. Das sind dann die Entwickler. Dazu vielleicht ein Architekt, je nachdem wie das Unternehmen aufgebaut ist. Ein Business-Analyst: Die Rolle ist ja sehr unterschiedlich besetzt, aber ich meine jemanden, der das leisten kann, dass er in diese chaotische Diskussion ein bisschen Struktur reinbringt und ein bisschen analytisch daran tritt, wie eine Art Moderator. Vielleicht, dass er ein Prozessmodell daraus extrahiert. Dann auch durchaus auch ein Fachbereichler, oder ein Endbenutzer. Ich liebe es diese Workshops dann auch wirklich breit zu haben. Wir haben gesehen, dass das viel bringt. Das muss dann halt gut vorbereitet sein. Aber dann ist ja wirklich die Power der BPMN: Ich habe viele Workshops gesehen, wo man an einem Tag relativ viel diskutiert hat, und dann hockt man sich doch mal Abends hin, macht daraus ein halbwegs strukturiertes BPMN-Modell, mal mit einem Aufschlag. Das Coole ist, dass du es ja auch direkt ausführen kannst. Was sich oft mache ist, einen Clickable-Prototype daraus zu machen, also so Formulare an gewisse Tasks dranhängen. Auch, wenn es automatisierte Aufgaben sind, mal quasi den Leuten die Möglichkeit zu geben, am nächsten Tag durch den Prozess zu klicken. Das bringt immer ganz viel Verständnis wie: „Ach. So ist das gemeint.“, oder: „Ach Da habe ich diese Daten. Aber, dann weiß ich ja das noch gar nicht.“ Das heißt, dass man eigentlich relativ früh, sehr viel Verständnis schaffen kann auf allen Seiten. Und dann kann man mal implementieren. Natürlich nicht sechs Monate, sondern man macht dann mal so einen Durchstich. Im Prinzip reden wir hier von zwei Tagen. Es kann aber auch mal zwei Wochen sein. Dann kann man was zeigen und wieder drüber sprechen. Dann kann man auch bei uns im Cockpit oder im Optimize, also im Monitoring visuell sehen. Das gibt allen Seiten sehr viel Verständnis und typischerweise auch Motivation. Und wenn man da ein bisschen gut weiter macht, kriegt man Sachen produktiv, wo die Leute tatsächlich ziemlich happy sind. Das glaube ich wirklich.
BJÖRN: Ich hätte es nicht so beschrieben. Ich glaube aber wir haben das auch schonmal in Projekten, wo die Leute, aufgrund der Visualisierung, der Transparenz, irgendwie doch schon eher das Leuchten in die Augen bekommen haben. Vielleicht kann ich das für uns in Anspruch nehmen. Wir arbeiten ja viel mit Anforderungsstellern zusammen. Sei es nun der Business-Analyst, oder in manchen Organisationen heißen die ja auch ein bisschen anders. Du hast auch gerade schon gesagt, dass die auch in ihrer Aufgabengestaltung immer deutlich anders ausgeprägt sind. Nichtsdestotrotz beschreibst du auch in deinem Buch so eine unterschiedliche Vorgehensweise von einem Wasserfall-orientierten Vorgehensmodell und dann eher in so einem agilen Modell. Wenn du dir in einem BPM-Workflow-Automation-Projekt mal den vorstellen würdest, den man eventuell Business-Analyst nennen könnte, den Anforderungssteller: Wie würdest du die Arbeit von dem in so einem Projektteam skizzieren?
BERND: Die Rolle ist aus meiner Sicht typischerweise recht zentral. Ich finde sie übrigens auch, wenn er weder Programmieren kann noch fachliche Ahnung hat, eine der schwierigsten Rollen. Es ist ja genau diese Übersetzung. Auf der einen Seite muss ich die fachlichen Anforderungen tatsächlich kapieren. Ich glaube, dass das Prozessmodell da extrem hilfreich ist. Man sollte immer Ende-zu-Ende verstehen, wo man hinwill, also wo das Ziel ist. Das Ziel sollte man schon vor Augen haben. Agil heißt ja nicht, dass ich einfach mal losrenne und dann merke, dass das die falsche Richtung war. Man sollte vielleicht schon ein bisschen wissen, wo man hinwill. Aber dann sollte man auch ganz klar sagen: „Okay. Alles klar. Dann lass uns jetzt mal diesen vorderen Bereich betrachten.“ Oder vielleicht ist es auch eher risikogetrieben: „Lass uns das da hinten mal validieren. Da sind wir uns nicht sicher, ob wir das hinkriegen.“ Und dann kann so ein Businessanalyst sehr nahe dran sein. Das ist das Coole am Agilen. Was wird dann implementiert? Dann kann man es wieder laufen sehen. Und da, wo es erfolgreich funktioniert, hat es dann auch ein sehr starkes Miteinander. Ich habe Business-Analysten erlebt, die dann da wirklich auch sehr interessiert waren, was das jetzt technisch heißt, oder was wir da genau machen, warum es da nicht so leicht geht, und sowas. Je mehr man Verständnis aller Beteiligten gewinnt, desto besser kann man ja auch die Prozesse abstimmen.
BJÖRN: Wenn du an den Business-Analysten und die BPMN denkst: Was bringt der denn dann üblicherweise? Bringt der irgendwie vier Aufgaben in einer Reihenfolge mit und hat das irgendwie hübsch in BPMN modelliert? Oder geht der runter bis auf ein potenziell ausführbares Modell? Was erlebst du da in der Praxis? Was wäre da wünschenswert?
BERND: Ich erlebe da irgendwie alles. Ich kenne auch Business-Analysten, die tatsächlich noch BPMN ablehnen. Ich glaube nicht, dass die so wahnsinnig erfolgreich sind, aber naja. Tatsächlich wird das dann typischerweise kompensiert, beispielsweise durch einen BPMN-affinen Part auf der Entwicklerseite. Das kenne ich auch. Aber was sollte er idealerweise mitbringen? Er sollte schon eine BPMN modellieren können, bis auf ein Niveau, wo man sagt: „Okay. Das ist jetzt eigentlich schon engine-ready.“ Eigentlich sollte er es schon so prototypingmäßig deployen können. Es wäre schon cool. So einen Clickable-Prototype daraus zu machen, ist nicht so ein Hexenwerk. Und man kann da vor allem jetzt auch nichts falsch machen. Das ist ja immer das Ding. Wenn ich da wirklich implementiere, oder das so ein Kernprozess ist, den ich dann live bringe, wo was weiß ich wie viele Instanzen, über Jahre hinweg drüber laufen, sollte ich halt gewisse Dinge richtig machen, sodass das wartbar ist und uns nicht um die Ohren fliegt, die Security geklärt ist und so. Aber für einen Clickable-Prototype ist das ja egal. Das wäre meine Idealvorstellung. Er sollte es automatisierungsready machen. Vielleicht auch mit einem Clickable-Prototype. Weil da kann er sehr viel mitspielen. Und dann sollte er das an die IT abgeben und da gibt es einen Entwickler, der da wahrscheinlich noch ein paar Attribute dran macht, es verdrahtet, vielleicht merkt, dass man da nochmal was ändern muss und redet nochmal miteinander. Das ist so das Idealbild.
BJÖRN: Das bringt mich gerade irgendwie zu dem Hinweis für diejenigen, die noch stärker in die BPMN einsteigen wollen. Ein Unternehmen namens Camunda, oder auch eines namens MINAUTICS bietet da BPMN-Trainings an. Und wir bereiten die Leute darauf vor, dass sie, wie Bernd sagt, engineready Modelle erstellen können. Vor einigen Wochen habt ihr jetzt die erste Version der Camunda-Cloud rausgebracht. Eine Cloud-Native-Lösung für die Projektorchestration. Wie unterscheidet sich die Camunda-Cloud von der jetzt doch schon reifen Camunda-Plattform? Und inwieweit haben die Ansätze aus dem Buch Eingang in die Camunda-Cloud gefunden?
BERND: Lass mich eine Sache vielleicht noch als Hinweis geben. Mit Camunda-Cloud haben wir nicht nur Cloud-native Technologie releast, sondern tatsächlich auch ein Cloud-Offering, also ein SaaS-Offering. Wir betreiben die auch für Kunden, was dann doch ein sehr großer Unterschied ist. Mindestens aus der Wir-bieten-es-an-Perspektive ist es ja ein ganz anderes Geschäftsmodell. Es sind ja ganz andere Dinge, die man können muss, um ein Cloud-Offering anzubieten. Aber darunter liegt eben, wie du richtig sagst, Cloud-Native-Technologie. Das heißt, dass wir einfach nochmal eine komplett neue Workflow-Engine geschrieben haben, die das Gleiche tut. Das ist vielleicht das Interessante. Die kann auch BPMN wieder ausführen. Das ist aber mit einem komplett neuen Innenleben. Von außen sieht man es schon auch, aber eigentlich ist das Innenleben das Interessante. Warum? Cloud-Native bringt ja so ein paar Themen mit. Zum Beispiel gibt es eine relationale Datenbank, die wir mit der Camunda-Plattform benutzen. Diese ist nicht so wahnsinnig Cloud-native. Die kriege ich zwar bei meinem Cloud-Provider, aber die haben beispielsweise Grenzen in der Skalierung, also was ich da noch an Durchsatz machen kann. Die haben Themen bei Georedundanz, was wir jetzt auch öfter bei großen Kunden haben. Also: Wie kann ich ein Data-Center in den USA, eines noch in Europa und eines in Asien haben? Wie bekomme ich das hin? Das kann so eine relationale Datenbank nicht so gut.
Und es ist auch dieses Betriebsmodell: Einfach Cloud-native in Kybernetis einfach mal was laufen lassen. Da baut man Anwendungen ein bisschen anders. So haben wir dann die Workflow-Engine gestrickt. Es ist ganz anders, wie sie ihre Daten speichert. Sie kann Horizont-Scales skalieren. Ich kann sie einfach in Kybernetis deployen. Und das ist schon ziemlich cool. Damit kommen wir jetzt auch einfach in andere Use-Cases hinein. Das eine ist ja die Betriebsumgebung, und wir können Cloud-Offering machen. Das alleine ist schon cool. Das ist so ein strategisches Ding. Das fragt im Moment jeder Kunde. Jeder große Kunde sowieso. Die fangen auch wirklich damit an alles als Cloud-first zu machen.
BJÖRN: In deinem Buch sagst du ja auch viel über den Wert von Prozess-Visability, wie du es im Buch nennst. Was ist damit gemeint? Was kann Euer Produkt Optimize da ganz konkret in diesem Cloud-Offering tun?
BERND: Optimize kann mir Einblick in die ganzen Daten, die ich so anhäufe mit meiner Workflow-Engine, bieten. Wie viele Prozesse laufen? Welchen Weg laufen sie typischerweise? Unter welchen Umständen laufen die vielleicht diesen Weg? Habe ich da irgendein Problem? Habe ich irgendwelche Bottle-Necks? Reiße ich irgendwelche SLRs? Solche Analysen kann ich in Optimize machen. Das funktioniert ja heute schon auf der Camunda-Plattform super. Da kriegen wir extrem gutes Feedback von den Kunden. Erster Schritt ist jetzt, das in die Cloud zu heben. Das hat zwei Use-Cases. Erstens kann es dann die Daten aus der Cloud-Engine, also aus der Workflow-Engine, die in der Cloud läuft, direkt lesen. Das ist absolut sinnvoll. Es wäre ja total bescheuert, wenn nicht. Das Zweite, was auch noch ein Thema werden könnte, da sind wir glaube ich noch dran: Du könntest auch Optimize einfach mal in der Cloud benutzen, um es an deine On-Prem-Camunda-Plattform zu hängen, weil man es nicht selbst betreiben will. Und, weil ich sage, dass diese Analysedaten vielleicht mal nicht mehr so kritisch sind. Die können vielleicht auch mal eher in der Cloud liegen. Da müssen wir mal noch ein bisschen gucken. Aber da ist der Wert, dass man es nicht selbst betreiben muss, auch schnell gegeben. Ansonsten ist das Thema Visability auch sehr spannend. Out of the Box kann Optimize einen Prozess, der auf der Workflow-Engine ist, in die Tiefe analysieren. Wir haben Optimize auch noch eine Sache mehr beigebracht: Es kann auch beliebige Events lesen. Die meisten Prozesse beginnen ja früher. Da geht zum Beispiel ein Schreiben bei einer Versicherung wo hin, wird dann gescannt, es wird eine OCR darüber laufen gelassen, dann gibt es vielleicht sowas, wie ein Regelwerk, welches sagt, dass das jetzt eine Kündigung ist und da ein Prozess gestartet werden muss. Und so weiter. Meistens passieren da Dinge außerhalb des automatisierten Prozesses. Die will man oft verstehen, um es Ende-zu-Ende zu verstehen. Und wenn man da Events erzeugt, dann kann Optimize die mit einlesen und wirklich ein Ende-zu-Ende-Bild daraus machen.
BJÖRN: Wenn ihr da draußen Camunda-Cloud mal ein bisschen testen und damit spielen und experimentieren wollt, dann findet ihr unter Camunda.com/products/cloud die Möglichkeit da mal einzusteigen. Das habe ich auch getan. Das ist sehr niederschwellig. Das hat viel Spaß gemacht. Da könnt ihr gerne mal ausprobieren und seht dann auch da die Möglichkeiten der Process-Visability, also das, was Optimize an der Stelle noch anbieten kann. Themenwechsel: Jetzt Post-COVID, denn wir sind jetzt hoffentlich durch, oder fast durch. Vielleicht gibt es noch eine Welle. Wir wollen nicht hoffen, dass sie kommt. Wenn du mal auf Camunda selbst schaust: Welche dieser Dinge, die du in deinem Buch beschreibst, was sehr technisch ist, das ist mir klar, wenn man die mal abstrahiert, waren denn vielleicht auch erfolgsentscheidend für Camunda und gerne auch ein bisschen darüber hinaus. Camunda hat sich ziemlich unbeeindruckt von der Epidemie gezeigt. Das war mein Eindruck. Was sind denn da so eure Erfolgskriterien?
BERND: Das kann ich, glaube ich, sehr schwer auf das Buch münzen ehrlich gesagt. Aber wenn ich die Firma betrachte, was du ja meinst glaube ich, und mal außen vorlasse, dass unser Produkt in der Zeit sehr dankbar war: Ein Produkt zur Automatisierung und Unterstützung von Agilität in Geschäftsprozessen, ist in der COVID-Zeit natürlich sogar gefragt. Unser Produkt war sehr dankbar, dass wir nichts anbieten, was keiner mehr braucht. Wir hatten durchaus Kunden, wo das der Fall war. Wir haben auch ein paar Kunden, die es jetzt gar nicht mehr gibt. Das haben wir schon auch gesehen. aber wenn ich jetzt rein auf die Firma schaue, kamen uns mehrere Sachen zum Vorteil. Einerseits haben wir schon vorher sehr viel remote gearbeitet. Wir haben ja mit der Internationalisierung schon deutlich früher angefangen. Wir haben in den USA schon recht viele Leute. Wir hatten auch im UK schon viele Leute. Wir haben in Singapur jemanden. Wir haben auch schon jemanden in Australien. Das heißt, dass wir dieses Remote-Work schon hatten. Das war nicht völlig neu. Man hat sich also auch schon darauf eingestellt, zum Beispiel auf der Tooling-Seite. Wir haben das dann aber auch echt ernsthaft durchgeführt. Wir sagten uns nicht: „Och. Wir müssen jetzt remote machen. Lass uns das mal irgendwie machen.“ Wir konnten sagen: „Okay. Dann machen wir wirklich remote-first.“ Jakob hat das auch wirklich konsequent einmal ausgerufen, aber auch ausgearbeitet, also was das denn bedeutet und wie man es macht. Und das meint jetzt die ganzen Themen, die da dranhängen. Wie kommuniziere ich? Wie kriege ich noch soziale Interaktion hin in so einer Welt? Was unser Backoffice so macht ist sowieso immer ganz cool. Wir haben solche Workshops organisiert. Das war dann irgendwie Remote-Yoga. Wir hatten solche Watercooler-ZOOM-Sessions. Und so weiter. Wir haben da ganz gut die Balance hinbekommen, glaube ich, dass man sagt, dass es nicht optimal ist, nie jemanden zu sehen, was wir ja jetzt alle wissen. Das ist blöd. Aber in Summe hat die Firma das ziemlich gut gemacht. Jakob hat da sehr schnell reagiert und das Thema ernst genommen. Wir konnten jetzt sogar nochmal flexibilisieren, wo die Leute jetzt eigentlich sitzen und arbeiten. Wir werden nicht alle wieder ins Büro zurück gehen und den ZOOM-Vertrag wieder kündigen.
BJÖRN: Das Buch ist jetzt geschrieben und irgendwie veröffentlich. Wenn man es jetzt in Händen hat, dann hat man ja vielleicht nochmal einen anderen Blick auf die Dinge. Gibt es eigentlich ein Kapitel, bei dem du sagst, dass du da aus heutiger Sicht nochmal ran wollen würdest? Darf man das kurz nach der Veröffentlichung fragen?
BERND: Natürlich darfst du das fragen. Nein. Tatsächlich bin ich, noch, ziemlich happy damit. Es gibt viele Kleinigkeiten, wie immer. Es gibt nicht so da sein Ding, bei dem ich sagen würde, dass man das hätte anders schreiben sollen. Ich hatte bisher auch noch kein Feedback, was in diese Richtung gezeigt hat. Ich glaube, dass wir da jetzt nochmal so ein bis zwei Jahre ins Land gehen lassen müssen. Wenn jemand etwas hat, dann sagt mir gerne Bescheid. Ich sammle das. Man kennt es ja: Nach dem Release ist vor dem Release. Ich sammle ja für eine vielleicht zweite Auflage. Bisher bin ich aber ziemlich happy. Ein Ding, aber das liegt wahrscheinlich auch daran, dass ich mich damit gerade so beschäftige, beschäftigt mich vielleicht. Ich mache sowas wie eine Process-Automation-Map. Das ist genau das, was wir vorhin hatten: Low-Code/Pro-Code? wann benutze ich welche Tools? Welche Dimensionen sollte ich mir in s einem Prozess ansehen? Im Prinzip ist das ein kurzer Abschnitt im Vorwort des Buches zu sagen: Setting the Szene, aber wir reden jetzt darüber. Ich glaube, dass ich dem vielleicht noch ein paar mehr Seiten spendieren könnte, wenn ich jetzt noch könnte. Da habe ich einfach noch ein paar mehr Sachen verstanden und hatte auch das Gefühl, dass das auch für jeden, der für Low-Code brennt, so ist, dass der es braucht, weil das in den Unternehmen diskutiert wird. Warum nehmt ihr nicht Low-Code? Warum klicken wir uns das nicht zusammen? Warum sollen wir das entwickeln? Diese Diskussion kommt, glaube ich, so oft hoch, dass es sich gelohnt hätte. Aber das ist auch ein Luxusproblem. Jetzt schreiben wir mal Blog-Posts und packen es in die zweite Auflage.
BJÖRN: Schön. Wir kommen schon fast zum Ende. Für diejenigen, die noch relativ neu in diesem Thema sind: Sag doch mal in einem kurzen Summary, was ich deinem Buch entnehmen kann, wenn ich beispielsweise mit Prozessautomation anfangen möchte, ein kleines Unternehmen bin, vielleicht ein ERP-System betreibe und jetzt denke, dass Prozessautomation irgendwie meins ist. Wie lege ich los? Wo beginnt meine Reise? Welche Orte muss ich besuchen? Was muss ich einpacken und dabei haben? Eine Minute Schnelldurchlauf Bernd. Erzähl doch mal.
BERND: Wir versuchen es mal. Erstmal muss man natürlich schauen, wer du in dem Unternehmen bist. Du brauchst irgendwann mal jemanden, der eine fachliche Ahnung hat, was wir da machen wollen und einen Entwickler. Das ist es eigentlich. Relativ schnell würde ich mir ein Projekt suchen, wo ich praktisch was machen kann. So als Pilotprojekt. Das sollte nicht zu groß und nicht zu klein sein. Aber tatsächlich etwas, was einen Wert hat. Es sollte kein Spielprojekt sein, sondern etwas Echtes, wo man wahrscheinlich gerade einen Schmerz hat. Denn dann kann man da auch dran gehen. Und dann sollte man es einfach machen. Man sollte sich zwei bis drei Entwickler dazu holen und sagen: „Wir bauen jetzt mal den Prototypen. Wir bringen ihn live. Wir bringen ihn in unsere Architektur.“ Man sollte ganz große Themen wie die ganze Architektur auf Micro-Services zu bauen, aussparen. Man sollte machen. Man sollte lernen. Und dann geht man an das nächste Projekt. Sucht euch einen Schmerz, den wir wirklich habt, wo Prozessautomatisierung helfen kann, und dann macht das.
BJÖRN: Okay. Eine Frage habe ich in der Einleitung quasi angekündigt, die noch geklärt werden müsste. Die haben wir unterwegs gar nicht geklärt. Damit hatte ich irgendwie gerechnet. Du hast es heute auch gar nicht an: Ein T-Shirt mit: „It depends“.
BERND: Aber ich habe das hier.
BJÖRN: Ah, sehr schön. Bernd hält gerade einen Zettel mit „It depends“ hoch.
BERND: Den habe ich immer griffbereit.
BJÖRN: Warum ist das für dich so wichtig?
Die Antwort hierzu erfährst Du im nachstehenden Audio-Beitrag. Das Interview dauert etwas über eine Stunde und ist aufgeteilt in drei MP3-Dateien!
