Autor: JIT

My Life with Isis (so far). Teil 2:

„My Life with Isis (so far).“

Hab ich es endlich geschafft und eine von diesen „catchy“ Überschriften produziert? (*)

Wenn es sich hier um ein GUI driven product handelt, kann ich mir darüber hinaus gut vorstellen, dass Isis auch in der Produktion gute Dienste leistet. Zugleich bedingt dieser Fokus naturgemäß Abstriche andernorts – die eierlegende Wollmilchsau, soviel sei gespoilert, hat man auch mit Apache Isis noch nicht ge- bzw. erfunden.

Ein Nachteil von Orchideen-Frameworks ist die oftmals nur spärlich vorhandene Dokumentation. Findet man für Giganten wie Spring neben den offiziellen Quellen, Myriaden an Blog-Artikeln, bis hin zu YouTube-Videos und eine Unmenge an Fragen auf Stackoverflow und Konsorten, so kann ein vergleichsweise unbekanntes Framework damit nicht mithalten.

Leider stellt Apache Isis hier meiner Erfahrung nach keine rühmliche Ausnahme dar. Mehr als einmal biss ich – nicht alleine – hart auf die Tischkante, als ich bei einem Problem die unerschöpfliche Weisheit des Internets zu Rate zu ziehen suchte und letztlich wiederum nur auf die mittlerweile fast auswendig bekannte „Beyond the Basics“ Seite (https://isis.apache.org/guides/ugbtb/ugbtb.html) verwiesen wurde, die keine Antwort auf mein Problem lieferte.

Apache Isis verwendet als Schnittstelle zur Persistenz-Ebene DataNucleus (datanucleus.com), dessen Dokumentation ebenfalls nicht mit Platzhirschen wie Hibernate mithalten kann.

Kopfschmerzen bereitete uns etwa die Tatsache, dass kein Mechanismus für innere Transaktionen bereitgestellt wird, wie sie aus Hibernate bekannt sind. Ausgesprochen positiv zu erwähnen sei hier die Reaktionszeit auf der offiziellen Mailingliste von Apache Isis. Ein von uns erdachter Lösungsansatz für eben dieses Problem, wurde binnen weniger Stunden zufriedenstellend beantwortet.

Ein weiteres Problem, dass erst in der Produktion auftrat, stellte einen Kollegen auf die Probe: Ein besonders großer CLOB, der so in keiner Test-Umgebung auftrat, konnte nicht persistiert werden. Die Dokumentation ist schwierig zu diesem Thema. Ein Workaround ließ sich auf die Schnelle nicht finden, weshalb ein Feature kurzerhand umgebaut wurde, um am mittlerweile gefürchteten DataNucleus vorbei zu operieren. (Anm: Da es sich hier nicht um ein Business-Objekt handelte, war dies auch fachlich in Ordnung)

Im Testing war die GUI oft Gold wert. Insbesondere durch die Integration in eine große Systemlandschaft konnten einzelne Button-Klicks einen langwierigen Retest erleichtern oder gar ersparen. Auch das Überprüfen von Resultaten gestaltet sich angenehm und einfach.

Bevor ich begann, war mir die Idee der Naked Objects fremd und, wie es in der Natur des Menschen liegt, war ich skeptisch – insbesondere da ich den letzten Jahren eher in Richtung funktionaler Programmierung unterwegs bin, wo Daten strikt von den Funktionen getrennt werden.

Ob es wirklich Sinn macht, wieder „Fat Objects“ zu bauen? Wo zieht man die (fachliche) Grenze? (Kunden kaufen Produkte, baut man nun eine buysProduct(Product product) Funktion im Kunden oder dich lieber eine buys(Customer customer) im Produkt)? Wenn es (streng genommen) keine – oder zumindest wenige Services gibt – wie setzt man bei einem nicht trivialen Domänenmodell Single Responsibility um oder wird es verwässert als „Alles was irgendwie mit dem Domänenobjekt X zu tun hat“?

Doch ich schob die Vorurteile so gut es eben ging beiseite, und kann heute sagen, dass die Erfahrung es wert war und meine Skepsis zwar nicht vollends verschwunden ist, aber auch nicht vollumfänglich bestätigt wurde.

Wie jedes Werkzeug sollte man auch Apache Isis vor jene Aufgaben stellen, für die es gemacht wurde. Spielt die GUI eine sehr untergeordnete Rolle, würde ich Isis nicht einsetzen, denn das wäre, als würde ich mit Rollerblades durch den Wald stapfen. Natürlich geht es, aber es bringt mich unnötig ins Schwitzen und ob es Sinn macht (und daneben gut für die Umwelt ist), sei dahingestellt.

Um hingegen ein Gefühl für die Domäne zu bekommen, schnelle Iterationen beim Rapid Prototyping zu ermöglichen, käme Apache Isis in die engere Auswahl. Wichtig dabei wäre mir, zu wissen, dass der Prototyp auch tatsächlich ein solcher ist, d.h. am Ende durch einen Neuimplementierung abgelöst wird, *oder* das Endprodukt tatsächlich GUI-driven ist.

(*) Falls Sie Mitarbeiter eines Geheimdienstes sind: Bitte nicht schießen!

My Life with Isis (so far). Teil1:

„My Life with Isis (so far).“

Hab ich es endlich geschafft und eine von diesen „catchy“ Überschriften produziert? (*)

Wenig vermag mein neugieriges Technikerherz derart zu begeistern, als die Aussicht etwas neues lernen zu dürfen. Umso entzückter war ich, als ich vor einigen Monaten die Möglichkeit erhielt, ein Projekt mit einem mir unbekannten Ansatz und Framework unterstützen zu dürfen.

Die Rede ist von Isis, das mir bis dato nur als ägyptische Göttin und aus jüngster Vergangenheit … na Sie wissen bestimmt Bescheid!

Daneben gibt es jedoch ein in der JVM-Welt angesiedeltes Apache Projekt gleichen Namens. Apache Isis (https://isis.apache.org/) basiert auf der Idee von Naked Objects. Kurz zusammengefasst, deren drei Grundprinzipien:

Erstens: Jedwede Business-Logik findet sich in den Fachobjekten = strenge Datenkapselung

Zweitens: Die graphische Oberfläche soll diese Fachobjekte 1:1 abbilden

Drittens – und das ist die Besonderheit dieses Architekturmusters: Die GUI soll automatisch aus den Fachobjekten generiert werden (weiterführend sei dem interessierten Leser die offizielle Seite http://www.nakedobjects.org/ ans Herz gelegt).

Die größte Stärke von Isis sehe ich eindeutig im dritten Punkt. Isis selbst verspricht >UI & REST „for free“< und hält dies auch ein!

Mit wenig Aufwand lässt sich eine leicht zu handhabende Oberfläche generieren, die sowohl die relevanten Daten der Business-Objekte darstellt, als auch Aktionen auf diesen unproblematisch ermöglicht. Somit wird die Verwaltung eben dieser Business-Daten durch einen Menschen zum Kinderspiel, was sich auch in den typischen Anwendungsfällen (siehe: https://isis.apache.org/pages/common-use-cases/common-use-cases.html) (https://isis.apache.org/pages/powered-by/powered-by.html) widerspiegelt.

Gerade für Rapid Prototyping ist der Ansatz ideal, da der Fokus auf dem eigentlichen Business-Modell liegen kann, während man keine Zeit „verschwendet“, bei jedem Modellierungsversuch, d.h. also insbesondere bei jeder Änderung der Business-Objekte, grafische Oberfläche (und Datenbank) anzupassen, um ein Gefühl für das Modell zu bekommen.

(*) Falls Sie Mitarbeiter eines Geheimdienstes sind: Bitte nicht schießen!

Mein Start ins Berufsleben als Developer

„Mein Start ins Berufsleben als Developer.“

Hallo, mein Name ist Tom und ich habe ein Problem … aber lasst uns am Anfang starten. Es war ein veregneter Novembertag vor über 20 Jahren als ich das Licht der Welt erblickte… oh mist, zu weit?

Letzten Sommer fasste ich den Entschluss, dass es an der Zeit wäre, mich nach der ersten Vollzeitstelle meines Lebens umzusehen. Mitten im Endspurt meines Studiums (oder eher der letzten Ferien meines Lebens *schnief*) machte ich mich also auf die Suche nach einer adäquaten Stelle und da sprang mir jene amüsante Ausschreibung ins Auge, die mein Schicksal besiegeln sollte. Von IT-Heroes und Superkräften war da die Rede! Mein Nedherz begann zu schlagen und ich durchstöberte nebst der offiziellen Webseite auch das Netz um Informationen zur Firma und meinem potenziellen Chef. (Manch einer mag es auch Stalking nennen :))
Nachdem ich mir etwas Mut ange- nach eindringlicher Überlegung, fasste ich den Entschluss, mein Glück bei J-IT zu versuchen. Zwar wusste ich, dass viele Arbeitgeber unbedingt auf ein abgeschlossenes Studium pochen, doch mein nicht nicht ganz orthodoxes Bewerbungsschreiben verfehlte sein Ziel nicht.

Und wem soll ich nun etwas vorgaukeln? Natürlich ist es eine Umstellung vom studentischen »Lotterleben« (ach, wenn es doch nur so gewesen wäre!) in eine Fixanstellung zu wechseln in der man in einem Monat soviel arbeitet wie sonst in einem halben Jahr (Klischees jetzt alle bedient? :)). Allerdings ist die Motivation auch eine ganz andere… wobei, eigentlich nicht. Abgesehen von mehr Geld in der Tasche blieb meine Grundeinstellung nämlich dieselbe: Beständige Weiterentwicklung. Das gelingt mal mehr, mal weniger, aber:

Die Arbeit mit Legacy-Technologien lernt man auf einer Universität nur bedingt – meist lächelt man lediglich darüber, wenn eine Anekdote in diese Richtung fällt – und wenngleich oftmals frustrierend, bringt sie einem doch einen nicht zu unterschätzenden Wissenszuwachs und sei es bloß ein »Urks, so macht man das aber nicht!«.
Neben antiken Relikten aus einer Zeit als Computer noch mit Dampf betrieben wurden, kommt allerdings auch die Arbeit mit (für mich) neuen Technologien nicht zu kurz. Die Mischung macht´s eben. (Randnotiz: Diesen Absatz aufheben, falls ich mal wieder an Uralt-Code verzweifle)

Woran ich mich noch nicht ganz gewöhnt habe, ist eine gewisse Volatilität bei den Arbeitspaketen und die Priorisierung von Aufgaben, die bisher ja stets bei mir selbst lag. Aber auch das wird mir mit der Zeit bestimmt leichter fallen.

Was ich an meinem Job wirklich liebe, ist der kunterbunte Haufen an Kollegen, die mehr an eine große Familie erinnern (bin ich dann eigentlich das schwarze Schaf?). Kaum eine Stunde vergeht, in der nicht von Herzen gelacht wird und jeder noch so trübe Tag vergeht, wenn man gemeinsam auf ein Ziel hin arbeitet. Egal wie schwierig eine Deadline auch einzuhalten sein mag, unseren (Galgen)Humor hat uns noch kein Kunde oder Releasetermin nehmen können. Die monotonsten Arbeiten (ja, auch die gibt es) werden erträglich, wenn man mit Leuten in einem Raum sitzt, die man mag. (*)

(*) Nein, ich wurde nicht gezwungen das zu schreiben und aua… nicht zwicken!

PS: Hilfe, ich wurde doch gezwungen das zu schreiben!

Micro Services – die Insider-Perspektive. Teil 5:

„“ZEEBE – A CONDUCTOR WITH A LIGHT HAND.” 

Lightweight BPM engines, especially designed to orchestrate Microservices, are the latest outcomes of the Microservice revolution. An excellent example for their anatomy and capabilities is Zeebe, recently introduced by the German BPM pioneer Camunda. Diese BPM-Engine wurde mit konsequentem Fokus auf Microservice-Orchestrierung entwickelt und deshalb auf horizontale Skalierbarkeit, niedrige Latenz und hohen Durchsatz getrimmt. Sie operiert mit Event-Sourcing: Sämtliche Prozessänderungen werden als Events geschrieben. Zeebe-Instanzen können in einem Cluster zusammenarbeiten. Ein Replikations-Mechanismus sorgt für Fehlertoleranz bei Ausfall von Nodes. Zeebe kann zum Process-Mining in vorhandenen, event-basierten Microservice-Architekturen integriert werden. In einer solchen reinen Beobachterrolle registriert die Engine sämtliche Events und korreliert sie mit den per Business Process Modelling & Notation definierten Geschäftsprozessen. Dies ermöglicht eingehendes und zugleich zeitnahes Monitoring der Geschäftsprozesse und macht visuell nachvollziehbar, auch – und das ist neu – in rein choreographierten Architekturen. Zeebe kann aber auch aktiv als als Orchestrierungs- und/oder Kommunikations-Layer integriert werden und Kommandos in Event-Form schreiben – entweder in einen vorhandenen Message-Bus oder der Zeebe-eigenen Messaging-Plattform. Zeebe finden wir gut – aus allen hier dargestellten Gründen. Und weil diese Engine einmal mehr beweist, dass BPMs und Microservices einander nicht ausschließen, sondern in Wahrheit ideal ergänzen.

Micro Services – die Insider-Perspektive. Teil 4:

„LIEBER LEICHT SEIN ALS SCHWER HABEN.“

Das Grundprinzip aller Micro Service-Architektur lautet: „Leicht und agil ist gut und effizient“. Es stand hinter allen Bemühungen um die Optimierung der in Teil 3 dieser Serie beschriebenen schlanken Choreografie-Lösungen. Und es erklärt, warum viele Micro Service-Pioniere fremdelten, als erstmals BPM-Engines zur Orchstrierung von Micro Service-Systemen herangezogen wurden: Zu schwergewichtig. Zu viel Initialaufwand. Zu mühsame Inbetriebnahme. Passt gar nicht zu Micro Services. Sagten sie damals. Mittlerweile haben sie ihre Meinung geändert. Mit guten Gründen.

Denn rasch erwiesen sich orchestrierte Systeme mit zentraler Steuerung als um nichts problematischer, komplexer und schwerfälliger als choreografierte Lösungen – im Gegenteil, Orchestratoren räumen buchstäblich mit den inhärenten Problemen von choreografierten Systemen auf:

Geschäftsprozesse verschwinden nicht mehr in abstrakten Codes, sondern können Parameter für Parameter in Echtzeit zentral überwacht und im BPMN-Kontext visuell dargestellt und modelliert werden. Logische Fehler werden auf einen Blick erkennbar. Timeouts und ähnliche Fehler können automatisiert verarbeitet werden. Visualisierung macht die Prozesse für alle Stakeholder verständlich. Kurz gesagt: Alles klar.

Der aktuelle State of the Art lautet deshalb: Choreographierte Systeme werden nur noch für einfache Standard-Prozesse eingesetzt, und selbst dabei ist zu bedenken, dass jeder neu hinzukommende, komplexere Prozess dem System und seinen Betreibern exponentiell wachsende Probleme bescheren würde.

Ausschließlich auf Choreografie zu setzen macht deshalb selten Sinn, umso weniger als es durchaus möglich ist, Choreographie und Orchestrierung in ein und demselben System zu mischen. Auch BPM-Engines müssen nicht zwingend als schwergewichtige, monolithische Zentralinstanzen eingesetzt werden. Im Gegenteil – es ist möglich und oft sinnvoll, abgeschlankte Engines direkt in einzelne Microservices zu integrieren. Beispielsweise könnte ein Payment-Service im Kontext eines Order-Services intern eine BPM-Engine verwenden, um den Payment-Prozess zu steuern.

Prominente Microservice-Vorreiter wie Netflix haben den Mehrwert solcher Orchestratoren für die Microservice-Architektur früh erkannt und dazu eigene, schlanke BPM-Engines entwickelt. Conductor ist ein gutes Beispiel. Auch auf dem freien Markt sind mittlerweile gleich mehrere leichtgewichtige BPM-Engines wie Camunda oder Zeebe erhältlich. Sie können als Teil eines Microservices embedded laufen und auch in der Cloud verwendet werden.

Die wachsenden Popularität solchen Lösungen spiegelt sich auch in veränderten Lizenzmodellen: Immer öfter wird nicht mehr nach Anzahl der Server oder CPUs, sondern nach Transaktionszahlen verrechnet.

Die Anatomie und Vorzüge einer solchen schlanken BPM-Engine werden wir im nächsten und letzten Teil unserer Blog-Serie betrachten.

Micro Services – die Insider-Perspektive. Teil 3:

„TANZEN ODER SPIELEN – DAS IST HIER DIE FRAGE?“

Willkommen bei Teil 3 unserer Blog-Reihe über Micro-Services – einen jungen Ansatz der IT-Architektur, der statt auf monolithische System-Dinosaurier auf hoch agile Bienenschwärme von kompakten, autonomen Services setzt. Die Kunst besteht dabei darin, die einzelnen Services als sinnvolles, effizientes, agiles Ganzes zu organisieren.

Denn kein Auto kann auf einem einzigen Rad fahren und kein Geschäftsprozess besteht aus einem einzigen Service: Microservices wie Billing, Payment und Shipping müssen kollaborieren, damit ein Prozess, und daraus ein Mehrwert für das Unternehmen, entsteht.

Gehen wir daran, solche Kollaborationen zu organisieren, dann steht eine Grundsatzentscheidung an: Orchestrieren – oder choreographieren?

Choreographierte Micro Services verhalten sich wie Tanzpaare in einem Ballsaal, die, ihren eigenen Routinen folgend, aufeinander reagieren und umeinander herum navigieren, ohne dass eine zentrale Steuerungsinstanz eingreift. Denn statt andere Services direkt aufzurufen, schreiben choreographierte Micro Services relevante Events in einen Message-Bus, z. B. Apache Kafka, den andere Services auf bestimmte, für sie relevante Events abhören. Publiziert z.B. ein Customer-Service bei der Neuanlage eines Kundenprofils den Event ‚Customer created‘, reagiert das Loyalty-Service mit den entsprechenden nächsten Prozessschritten. Wir nennen das asynchrone, event-basierte Kommunikation.

Die dabei Schritt für Schritt entstehende Eventkette bildet den gesamten Geschäftsprozess ab. Ein zentraler Steuerungsapparat ist überflüssig und die Kopplung zwischen den einzelnen Services ist so lose wie überhaupt nur möglich – ein Idealzustand in der Micro Service-Architektur.

Warum also nicht alle Micro Services orchestrieren? Weil jeder Idealzustand seinen Preis hat. Verwender orchestrierter Services entrichten ihn erstens in Form erhöhter Komplexität infolge asynchroner Kommunikation, zweitens durch totale Abstraktion, die Geschäftsprozesse nur mehr implizit in Form von Events abbildet bzw. im Code verbirgt, und drittens durch erhöhten Aufwand beim Monitoring des Gesamtprozesses: Choreografierte Systeme geben nicht von sich aus Auskunft, wie viele Prozesse derzeit laufen, wie viele Prozesse Fehlermeldungen produzierten usw.: Ein solches Monitoring müsste über kostspielige Custom-Lösungen eingerichtet werden.

Darüber hinaus lösen choreographierte Systeme das Versprechen der totalen Autonomie des einzelnen Services nur bedingt ein: Durch den Nachrichteninput und -output der Services entsteht eine indirekte Kopplung, die bei der Implementation neuer Anforderungen die Anpassung mehrerer Services erfordert – im eklatanten Widerspruch zur reinen Microservice-Lehre.

Lösen lässt sich dieses Manko durch eine Event-Command-Transformation, aber diese läge nicht im Verantwortungsbereich der beteiligten Services. Vielmehr müsste ein separates Service für diese Aufgabe erstellt werden, etwa durch Einsatz einer BPM-Engine, was aber wiederum den ersten Schritt zur zentralen Orchestrierung bedeuten würde.

Angesichts solcher Komplikationen wird verständlich, warum orchestrierte Micro Service-Systeme immer populär werden: Im Gegensatz zu choreographierten Architekturen sind sie mit einer zentralen Steuerstelle ausgerüstet. Diese lenkt den Gesamtflow, nicht unähnlich einem Dirigenten, der die Musiker eines Orchesters synchronisiert. Als Kommunikationsschiene zwischen Steuerstelle und Services wird häufig REST eingesetzt. Als zentraler Orchestrator eignen sich speziell leichtgewichtige BPM-Engines wie Camunda, Zeebe oder Conductor.

Warum solche Konstruktionen anfänglich mit Vorurteilen zu kämpfen hatten, mittlerweile aber immer öfter die beliebten Choreografie-Lösungen überholen, erfahren Sie in Teil 4 unserer Blog-Serie.

Micro Services – die Insider-Perspektive. Teil 2:

„WAS MICRO SERVICES BRAUCHEN, UM ZU FUNKTIONIEREN?“

Willkommen bei Teil 2 unserer Blog-Reihe über Micro-Services – einen jungen Ansatz der IT-Architektur, der monolithische System-Dinosaurier durch hoch agile Bienenschwärme von kompakten, autonomen, kollaborierenden Services ersetzt, wobei die Kopplung zwischen den Services idealer Weise möglichst lose und die Kohäsion innerhalb des einzelnen Services möglichst stark sein soll.

Eine solche Architektur bietet den Ausweg aus der Unbeweglichkeit und Unsteuerbarkeit komplexer, organisch gewachsener Systeme. JIT hat viele einschlägige Projekte begleitet und empfiehlt Micro-Services gerne und aus Überzeugung – allerdings nur dann, wenn die technischen und organisatorischen Rahmenbedingungen tatsächlich gegeben sind.

Das Nachdenken über organisatorische Rahmenbedingungen beginnt mit „Conway´s Law“: Wenn eine Organisation ein System entwirft, erkannte Melvin Conway schon vor einem runden halben Jahrhundert, entsteht völlig zwangsläufig eine Abbildung ihrer eigenen Team- und Kommunikationsstrukturen.

Deshalb wird ein Unternehmen, das die Migration zu einer Micro Service-Architektur vorbereitet, eingehend über Businessprozess-Anatomie, Zuständigkeitsgrenzen und Aufgabenverteilungen nachdenken müssen.

Denn um eine möglichst lose Kopplung zwischen Micro Services bei möglichst starker Kohäsion innerhalb jedes Services erzielen, müssen die Services und die zugrundeliegenden Datenmodelle sorgsam entlang klarer Domänengrenzen und Zuständigkeiten modelliert werden, die sich dann in einer klaren, effizienten Micro Service-Architektur spiegelt.

Domain-driven Design (DDD) ist das Werkzeug der Wahl für solche Modellierungen, speziell wegen der dazu verwendeten „bounded contexts“: Sie teilen die Business-Domäne sauber in klar abgegrenzte Zonen auf, zum Beispiel in Billing, Payment, Shipping usw. Jeder so definierte „bounded context“ bietet eine explizite Schnittstelle, die von kollaborierenden Services anderer Zonen verwendet wird.

Zu den organisatorischen Voraussetzungen gesellen sich auch technische Vorbedingungen. Die eine ist ein hoher Automatisierungsgrad: Continous Integration/Delivery ist in einem Micro Service-System unabdingbar.

Ebenso wesentlich ist das Monitoring: Der Zustand der einzelnen Services und des Gesamtsystems muss kontinuierlich überwacht werden. Dies gestaltet sich etwas komplexer als bei traditionellen Applikationen, da mehrere Server, Logfiles und Metriken wie CPU-Auslastung oder Response-Zeiten an einer zentralen Stelle aggregiert werden müssen. Tools wie Graylog, Graphite und Nagios sind dazu hilfreich.

Sind alle diese Rahmenbedingungen geschaffen, bleibt nur noch eine Frage: Soll das System in Zukunft spielen wie die Philharmoniker? Oder soll es tanzen wie Nijinsky? Was das bedeutet, impliziert und erfordert, verraten wie Ihnen in Teil 3 unserer Blog-Serie.

Micro Services – die Insider-Perspektive. Teil 1:

„WIR HABEN DIE LÖSUNG. FEHLT NUR NOCH DAS PROBLEM.“

Vierzehn Jahre als IT-Dienstleister – das macht etwas mit dir. Die Erfahrung wächst. Die naive Begeisterung für Hypes und Moden schrumpft. Gut so, denn IT ist ein Werkzeug. Nicht mehr und nicht weniger. Und der Wert neuer Werkzeugdesigns misst sich an den Problemen, die sie lösen.

Micro Services zum Beispiel: Seit Jahren in aller Munde, gelegentlich als Allheilmittel für wirklich, wirklich alle IT-Probleme angepriesen, sind sie auch für JIT von stetig wachsender Bedeutung, und wo wir sie einsetzen, sind Kunden in der Tat begeistert. Das liegt allerdings daran, dass wir nur dann zur Migration raten, wenn die Problemstellung den Aufwand rechtfertigt und alle organisatorisch-technischen Rahmenbedingungen stimmen.

Wirklich empfehlenswert sind Micro Services zur Revitalisierung von IT-Landschaften, die über Jahre und Jahrzehnte hinweg organisch gewachsen sind, bis sie zu groß, kompliziert und unbeweglich wurden, um sich an veränderte Umweltbedingungen anzupassen. Jurassic Systems sozusagen.

Das wichtigste Symptom akuter Systemwachstumskrisen ist die explodierende Fehlerquote: An einer in die Unüberschaubarkeit gewucherten Applikation doktern unterschiedliche Teams herum und implementieren neue Features, die meist wenig miteinander zu tun haben. Was nicht weiter stört, denn ehrlich gesagt überblickt längst niemand mehr im Unternehmen die Business-Logik der Applikation in ihrer Gesamtheit. Die ausufernde Komplexität macht Code-Eingriffe zu Weiterentwicklung und Wartung immer schwieriger, teurer und riskanter: Selbst kleinste Änderungen provozieren unterwartete Reaktionen in scheinbar unbeteiligten, weit entfernten Regionen des Systems. Das wachsende Fehlerrisiko hemmt dringend nötige Entwicklungsschritte, das Unternehmen verliert seine Agilität, der Markt läuft ihm davon.

In solchen Settings sind Micro Services eine ideale Lösung: kompakte, autonome Services, die miteinander kollaborieren, wobei die Kopplung zwischen den Services möglichst lose und die Kohäsion innerhalb des einzelnen Services möglichst stark ausgelegt wird. Die gesamte IT-Architektur folgt dem Single Responsibility Prinzip „Do one thing and do it well“. Die Vorteile liegen auf der Hand:

Kompakte, überschaubare Services können einfach, schnell und risikoarm überarbeitet werden, und das über den gesamten Lebenszyklus hinweg vom immer gleichen Team – so wird die Devops-Vision greifbar. Auch Service-Neuimplementierungen und Modernisierungen einzelner Services durch spezialisierte Technologien sind mit wenig Aufwand möglich. Performance-kritische Services können einzeln skaliert werden. Laufende, rasche, risikoarme Deployments reduzieren die Time-to-market. Services können vielfältig verknüpft werden, um neue Funktionalitäten zu schaffen.
Zusammenfassend könnte man sagen, Micro Services ersetzen System-Dinosaurier durch hoch agile Bienenschwärme.

Das sagen wir unseren Kunden. Aber wir sagen ihnen auch, dass die neue Agilität einen Preis hat, und nein, die Rede ist hier nicht von der Einstiegsinvestition, sondern vielmehr von der veränderten Risikolandschaft: Migration zur Micro Service-Architektur bringt die charakteristischen Herausforderungen komplex verteilter Systeme mit sich – Stichwort Distributed Transactions, AKID und Konsistenzen. Und siehe Bill Joy und seine „Acht Irrtümer bezüglich verteilter Systeme“.

Auch über die organisatorisch-technischen Voraussetzungen für Micro Services gibt es eine Menge zu sagen. In Teil 2 dieser Blog-Serie tun wir genau das.

Transparentes Festpreis-Angebot

„Transparentes Festpreis-Angebot“

Geht es um Individualsoftware-Entwicklung so geben sich viele IT-Dienstleister Mühe Festpreis Angebote zu vermeiden. Auch ist es der Fall, dass sich die Zusammenstellung der Aufwände nicht immer in jener Klarheit erschließen wie es vom Kunden erwartet wird.

Bezüglich Verrechnungsart wird oftmals die Abwicklung nach tatsächlichem Aufwand – also Time & Material – fokussiert. Dies bedeutet im Klartext die vollständige Übernahme des Risikos durch den Kunden.

Aus Sicht des IT Dienstleisters ist dies die perfekte Lösung – ausgenommen bis auf einen wesentlichen Aspekt: dem Kundenwunsch entsprechend Planungs- und Budgetsicherheit zu entsprechen.

Betrachtet man das Thema Abwicklung auf Festpreisbasis etwas näher so ergeben sich einfache Regeln für den IT Dienstleister, welche sich positiv auf eine Risikominimierung auswirken:

  • Unabhängig der Gesamt-Projektgröße ist darauf zu achten, dass einzelne atomare Aufgaben (z.B.: funktionale Anforderungen) eine maximale Größe an Aufwand nicht überschreiten dürfen. Ist dies der Fall so muss die entsprechende Aufgabe abermals aufgeteilt werden.
  • Dem IT-Dienstleister muss die Möglichkeit gegeben werden sich mit der Infrastruktur, den Technologien und den handelnden Personen des Kunden vertraut zu machen.
  • Klare Kommunikation bezüglich der Qualität der zugrunde liegenden Dokumente (Spezifikationen, etc.). Im Bedarfsfall hat eine Überarbeitung zu erfolgen. Gibt es diesbezüglich keine Einigung zwischen den beiden Parteien so ist dies der korrekte Zeitpunkt sich einem anderen Projekt zu widmen.

Man muss die Angelegenheiten nicht komplizierter machen als sie ohnedies sind.

Neben dem verbindlichen Preis ist für den Kunden die Nachvollziehbarkeit der zugrundeliegenden Aufwände von höchster Priorität.

Hand auf‘s Herz, wie oft haben Sie als Entscheidungsträger zu ein und derselben Anforderung mehrere Angebote erhalten und konnten diese nicht miteinander vergleichen? Ergänzend hierzu macht es oftmals die angeführte Aufteilung der Kosten unmöglich für einzelne Positionen den ROI zu errechnen.

Auch hierzu gibt es eine einfache Lösung: Das Auflisten nach fachlichen Anforderungen mit dem jeweiligen Kosten. Im Idealfall nachvollziehbar durch eine offizielle Metrik, beispielsweise dem Function-Point-Verfahren.

Fazit:

Beachtet man neben dem erforderlichen technischen Skillset einige Verhaltensweisen sowie Regeln und stellt man darüber hinaus Überlegungen an wie ein Angebot aus Kundensicht gestaltet sein soll, so hat man gute Chancen den Auftrag zu gewinnen.

Passierschein A38 – BPM ist schon längst kein gallisches Dorf mehr

„Passierschein A38 – BPM ist schon längst kein gallisches Dorf mehr.“

Was Asterix und Obelix, der Passierschein A38 und BPM miteinander gemeinsam haben? Lest selbst:

Im Kultzeichentrick „Asterix erobert Rom“ stehen Asterix und Obelix vor der Aufgabe den Passierschein A38 aus einer römischen Präfektur (Anm.: Amt) zu besorgen. Diese Prüfung gestaltet sich alles andere als einfach: Die beiden Gallier erfahren eine ständige Weiterreichung von Department zu Department, das benötigte Dokument bleibt ihnen jedoch verwehrt. Erst als Asterix sich einer List bedient und den fiktiven Passierschein A39 verlangt, gelingt es ihm, die gestiftete Verwirrung zu seinen Gunsten zu nutzen und somit dennoch den erforderlichen Passierschein A38 zu erlangen.

Diese Geschichte zeigt – wenn auch überspitzt – dass sobald eine Institution eine bestimmte Größe erreicht, eine Prozessautomatisierung unumgänglich ist, um die Effizienz der Abwicklung von diversen Abläufen zu gewährleisten. Der Schritt in Richtung Automatisierung bringt im Vergleich zur manuellen Prozessbearbeitung folgende Vorteile mit sich:

  • geringere Prozesskosten
  • schnellere Prozessdurchführung
  • weniger Prozessfehler
  • bessere Nachvollziehbarkeit

Wer nun jedoch glaubt, dass die automatische Durchführung von Abläufen nur für große Unternehmen mit entsprechenden finanziellen Mitteln Relevanz hat, der irrt. Auch kleine und mittlere Unternehmen (KMU’s) können ohne sich in finanzielle Unkosten stürzen zu müssen ihren Benefit aus der Prozessautomatisierung ziehen. Durch sogenannte „Human Tasks“ können automatische Prozessabläufe punktuell um manuelle Tasks angereichert werden. So bleiben z.B. im Prozess „Anmeldung eines neuen Mitarbeiters“ die einzelnen Schritte wie Anmeldung bei der Sozialversicherung, Anlage eines Benutzerkontos und Übergabe von Schlüssel und Zutrittskarte manuell. Durch Prozessautomatisierung wird hingegen sichergestellt, dass keiner der zuvor genannten Schritte vergessen wird.

Die Einführung von BPM ins Unternehmen gestaltet sich so einfach wie noch nie. Leichtgewichtige Open-Source Lösungen wie Camunda ermöglichen mittlerweile eine sehr geringe Einstiegshürde. Die Aufsetzung einer Prozessengine für ein Pilotprojekt kann innerhalb kürzester Zeit ohne Lizenzkosten durch einen erfahrenen Java Developer vorgenommen werden. Anschließend erfolgt in Abstimmung mit dem Fachbereich die Festlegung auf die zu automatisierenden Prozesse. Erst nach Abschluss einer erfolgreichen Pilotphase gewinnt der Einsatz von kostenpflichtigen Features an Bedeutung.

Hätte sich bezogen auf die Geschichte von Asterix und Obelix die Präfektur damals bereits an BPM bedient, wäre das Erlangen von Passierschein A38 ein leichtes gewesen. Somit zeigt sich auch schon in der Antike: BPM macht das Leben einfacher!