Technisches Statement zu digitalen Lösungen

Nachfolgend richte ich mich an Informatiker und Mathematiker und natürlich auch an jene, die mehr Einblicke in unser technisches Verständnis haben möchten.

Robert Strehlow

Dipl.-Inf. // Managing Partner

Im Folgenden versuche ich, so einfach wie möglich, Ihnen nahezubringen, was wir unter nachhaltiger Software verstehen ...

 

Ich wünsche Ihnen viel Spaß bei der Lektüre - und wer weiß, vielleicht lernen wir uns auch einmal persönlich kennen - als Interessent oder auch als Bewerber?

 

Ihr

Robert Strehlow

Wozu braucht es Updates?

Modernisierung

Die Sehgewohnheiten durch das mobile Surfen auf den Smartphones und Tablets haben sich in den letzten Jahren dramatisch verändert! Auch die technischen Anforderungen wachsen und verändern sich laufend, z.B. durch neue Web-Browser auf den PCs und Mobilgeräten, durch die geänderten Vorgaben der Suchmaschinen, durch aktuelle Sicherheitsanforderungen.

Die Modernisierung ist ein kontinuierlicher Prozess, der technisch bedeutet, dass das Rückgrat der Software (die Technologiebasis, das Framework) laufend verbessert und weiterentwickelt werden muss. Ein Grundrauschen an Updates, was über die monatliche Updatepauschale finanziert wird.

Projektfortschritt

Eine erfolgreiche Plattform wird man als Betreiber immer wieder erweitern und verbessern, um den hohen Level an Kundenorientierung, Individualisierung und Komfort aufrechtzuhalten oder zu verbessern.
Zum einen wird man sie an moderne Sehgewohnheiten anpassen wollen (z.B. Autocompletion macht Vorschläge, optisches Redesign), zum anderen wird man im Dialog mit seinen Kunden dazulernen, und Dinge verbessern oder Funktionen hinzufügen.

Die Projektentwicklung vollzieht sich technisch in Etappen von Teilprojekten.

Gesamtbild

Modernisierung und Projektentwicklung greifen technisch gesehen ineinander, weil die Projektfunktionen sich auf zentrale Funktionen stützen bzw. damit verzahnt sind. Beide Entwicklungsprozesse müssen daher kontinuierlich zusammenspielen.

Was bedeutet Release-Management?

Von vielen ERP-Systemen und ihren großen Anbietern kennt man das Arbeiten mit "Release-Management".

Dabei wird monatlich oder pro Quartal ein Release angekündigt und per aufwändigem Upgrade eingespielt, incl. Fehlerbehebung im Anschluss.

Diese Vorgehensweise hat bei vielen Menschen zu der Einschätzung geführt, dass ERP-Systeme "wahnsinnig komplex" und "viel aufwändiger als Websysteme" seien - was technisch nicht zutrifft, denn eine moderne Web-Handelsplattform nimmt es in Sachen Softwarefläche oder Komplexität problemlos mit einem ERP-System auf.

Eine Bewerberin hat es einmal so ausgedrückt:
Beim Release-Wechsel werden Probleme geschaffen und anschließend heroisch gelöst.

 

 

Dazu WIKIPEDIA:

"Das Release-Management hat die Aufgabe, die Risiken der Unterbrechung von Geschäftsprozessen bei Konfigurationsänderungen bestehender Systeme, die durch schlecht geplante oder nicht ausreichend getestete Systemkonfigurationen hervorgerufen werden, zu mindern."

 

Für den Kunden der Plattform bedeutet Release-Management, dass er neue Funktionen grundsätzlich nicht zeitnah eingebaut bekommt, sondern erst mit dem nächsten oder gar übernächsten Release. Release-Wechsel sind oft mit Stillständen und hohem Fehleraufkommen verbunden.

 

 

Wir mögen diese Vorgehensweise überhaupt nicht!

Arbeitsweise

Software Features

  • Wir erstellen ständig eine Vielzahl von Updates ("Software Features"), die in Summe die Weiterentwicklung des Gesamtsystems sowie des jeweiligen Kundenprojekts darstellen; Software Features sind vergleichbar mit den Transportaufträgen der SAP-Softwareentwicklung.

Continuous Delivery

  • Die Software Features werden laufend (täglich, wöchentlich) auf den Livesystemen eingespielt.
  • Pro Monat überspielen wir ca. 600 Software Features auf jedes Staging- bzw. Livesystem.

Oft wird zur Erreichung von zeitkritischen Zielen im Kundenprojekt gleichzeitig eine Weiterentwicklung zentraler Bereiche benötigt. Diese zentralen Änderungen werden in Abstimmung mit dem QM-Team ebenso zeitnah durchgeführt und freigegeben, wie die Funktionsupdates des Kundenprojektes. Die Projektteams und das Qualitätsmanagement-Team arbeiten Hand in Hand.

Wir sind in der Lage, agil Änderungen/Erweiterungen/Weiterentwicklungen durchzuführen und fehlerfrei und zeitnah auf die Livesysteme zu bringen. Dadurch sind die Systeme sehr aktuell, so dass zukünftige Entwicklungsschritte oder zeitnahe Änderungen viel leichter möglich werden. Das Arbeiten für die Software-Ingenieure wird angenehmer, die Effizienz steigt deutlich.

 

 

Diese Vorgehensweise wird möglich durch den

Faktor Mensch

  • Vorleben von Qualität

  • Erfahrene, qualitätsbewusste Mitarbeiter (10-15 Jahre im Team)

  • Ausschließlich Akademiker

  • kontinuierliche interne Weiterbildung

  • Aktiv integriertes Qualitätsmanagement-Team

  • Themengebundene Spezialisten-Teams

  • Effizientes Miteinander durch gute Team-Kommunikation

 

Faktor Technik

  • intelligente Vorgehensweisen
    • Entwicklungs-Branches als zentraler Branch schaltbar
    • Automatisierte und manuelle Software Features möglich
    • Nicht-abwärtskompatible Änderungen routiniert ausrollen
    • Komplexe Migrationen durch Live-Branches ermöglichen

  • Automatische Testverfahren
    • Automatisierte Integritätstests
    • Kontinuierliche Software-Bedienung auf dem Entwicklungssystem mittels Selenium-basiertem System

  • mehrdimensionale Qualitätsmaßnahmen
    • Organisierter „Hello Joe“-Support der Spezialisten
    • Internes Monitoring und zeitnahes Eingreifen
    • Aufwändige Einarbeitung von neuen Mitarbeitern
    • Kontinuierliche Weiterentwicklung von gemeinsamen Vorgehensmodellen
    • Kontinuierliche Weiterentwicklung der Tools

  • spezialisiertes Ticket-/Workflowsystem
    • Kunden und Entwickler arbeiten auf derselben Ticket-Plattform
    • Hohe Integration der Entwicklungswerkzeuge mit dem Ticketsystem

  • mächtige Entwicklungswerkzeuge
    • Eigene Tools zum Datenabgleich
    • Eigenes Metamodell zur Datenbank-Modellierung
    • Eclipse mit spezialisierten Tool-Integrationen

Fehlerfreiheit

Kein Verfahren (Release Management vs. Continuous Delivery) kann eine 100%ige Fehlerfreiheit von Software garantieren. Eine sehr geringe Fehlerquote kann nur durch erheblichen Zusatzaufwand weiter gesenkt werden, z.B. durch mehrstufige Staging-Systeme und sehr aufwändiges Testen.

Dies wiederum wird erkauft durch unverhältnismäßig hohen Kosten-/Zeitaufwand sowie starke Einbußen der Agilität. Eine Mars-Mission ist extrem teuer und äußerst unspontan.

 

Wir sind der Meinung

  • dass agile Entwicklung auf höchstem Qualitätsniveau (d.h. mit sehr geringer Fehlerquote) die beste Grundlage für eine nachhaltig erfolgreiche Plattform ist.
  • Unser Credo ist: Grundsätzlich Fehler vermeiden. Entstandene Fehler schnell und effektiv beheben.
  • Wir streben seit Jahren kontinuierlich nach Perfektion, was sich in einer auffällig niedrigen Fehlerquote zeigt.
  • dass dies auch optimal für die Gesamtkostenrechnung der Kunden ist

 

Ab diesem Punkt ist die relevante Frage:

Was passiert, wenn doch einmal ein Fehler auf einem Livesystem auftritt?

Die Fehlererkennung und -behebung haben wir über viele Jahre perfektioniert:

  • technische Fehler werden von uns unmittelbar erkannt und können sofort behoben werden.
  • typische Antwortzeiten vom Auftreten des Fehlers bis zur Fehlerbehebung sind je nach Komplexität 30min (häufig) - 2 Stunden (selten).
  • inhaltliche/logische Fehler werden meist vom Kunden über unser Ticketsystem gemeldet und mit höchster Priorität bearbeitet.

In beiden Fällen hilft wiederum die hohe Aktualität der Livesysteme, dass Bug-Fixes schnell und wirksam erstellt und übertragen werden können.

 

Allgemeine Ausfälle (z.B. der Netzwerkinfrastruktur des Kunden) werden mit modernen Überwachungstool überwacht.

Stichwort Migration

Es gibt extrem umfangreiche Projekterweiterungen, die mit einem Team von Entwicklern über viele Monate als Ganzes erstellt werden, und sehr umfassende Änderungen bewirken. Solche enormen Projektschritte müssen typischerweise über eine komplexe Migration auf ein Livesystem gebracht werden.

 

Unser Ziel über viele Jahre war, den Abschaltzeitraum des Livesystems bei einer komplexen Migration immer noch kürzer zu halten.


Wir finden

Eine Plattform entwickeln ist wie ein neues Flugzeug im Hangar zu bauen. Keine Passagiere, keine Umweltgefahren, kein Stress. Nun stellen Sie sich vor, dass dieses Flugzeug dann in die Luft steigt und nie wieder landen darf. Das Tanken und die Reparaturen müssen in der Luft erfolgen!

Unmöglich?

Genau das machen wir Tag für Tag. 365 Tage im Jahr. Manchmal auch 366 Tage. Wartungen und Reparaturen und Ausbauten erfolgen in der Luft, während Sie als Kapitän fliegen und Ihre Kunden (=Passagiere) mitnehmen – ohne das Sie uns bemerken!

Natürlich könnten wir das Flugzeug zwischenlanden lassen. Doch das geht mit Verlusten für Sie einher: Google findet Ihre Seiten nicht mehr, Ihre Kunden sind verärgert, wenn diese gerade jetzt bestellen wollen. Und was, wenn die Plattform wieder online geht, aber die Warenkörbe durch die Reparaturen (den Restart) wieder leer sind.

Ausfallzeiten: aus unserer Sicht inakzeptabel.

Keine Ausfallszeit, beeindruckte Kunden

Inzwischen haben wir unsere Vorgehensweisen derart verfeinert, dass wir in der Lage sind, eine komplexe Neuentwicklung auf ein Livesystem zu bringen und dort zu testen, so dass wir letztlich

 

für den Kunden sichtbar auf Knopfdruck auf die "neue Version" umschalten können.

Hersteller & Integrator

Klassischer Ansatz

Technologiebasis und individualisiertes Projekt arbeiten eng verzahnt zusammen. Darin liegt mittel- bis langfristig das größte Risiko:


Ein klassischer Technologie-Hersteller hat eigene Vorstellungen und eine eigene Roadmap seiner Releases bei der Weiterentwicklung seiner Technologiebasis. Unter Umständen gibt es hier sogar zwei Ebenen, wie im Fall von php + Framework.

Ein klassischer Integrator, der mithilfe dieser Technologie(n) ausschließlich das Kunden-Projekt erstellt und weiterentwickelt, hat über die Jahre zunehmend Schwierigkeiten, ein Auseinanderdriften der beiden Sichtweisen zu verhindern. Er hat wenig bis gar kein Mitspracherecht bei der Technologie-Entwicklung, aber muss dennoch alle individuellen Anforderungen seiner Kunden damit versuchen zu erfüllen.

Und wie arbeiten wir?

Wir haben uns vor vielen Jahren entschieden, Basis-Technologie und Projekt aus einer Hand zu liefern. Wir sind also sowohl Hersteller, als auch Integrator.

 Das war in den ersten Jahren nicht immer einfach, ist inzwischen aber ein enormer Vorteil für alle Beteiligten. Wir entwickeln die Basis-Technologie (Java-basierter Application Server, Framework, Basisfunktionalitäten) sowie die hochgradig individuellen Projekte mit denselben Leuten, agil, im engen Austausch, im kooperativen Einvernehmen. Dadurch ist unsere Gesamteffizienz maximal und Reibungsverluste (z.B. beim „Umschiffen“ von bekannten Problemen der Basistechnologie) entfallen.
Dadurch, dass wir alle Ebenen des Spiels im Griff haben, sind wir wesentlich flexibler und handlungsfähiger. „Geht nicht“ gibt’s bei uns nicht.

Unsere kontinuierlichen Plattform-Updates (Software Features) umfassen die Entwicklungsfortschritte aus allen Ebenen (Basistechnologie bis Projekt). Damit sind unsere Live-Systeme auf allen Ebenen gleichermaßen aktuell und stimmig.

Ausgewählte Success Stories

Technisches Statement

Inhaltsverzeichnis
    Was auch immer Ihr Digitalisierungsvorhaben ist


    Sprechen Sie mit uns.