Beispiele

• Applikationsserver
• EAI-Werkzeuge
• BPNM-Werkzeuge
• Entwicklungsumgebung
• Lokale "Entwickler"-Infrastruktur
• Testwerkzeuge
• Buildsystem
• Dokumentationswerkzeuge
• Ticket-Tracker
• Version Control System (VCS)
• Server-Hardware-Infrastruktur
• "* as a Service"-Dienstleister

Teamfähigkeit

• Verfügbarkeit
• Parallele Nutzbarkeit
• Notwendige Lernkurve

Anpassbarkeit

• Kleine Features
• Refactorings
• Große Richtungswechsel

Testbarkeit

• Automatisierbarkeit
• Reproduzierbarkeit
• Stabilität
• Verfügbarkeit

DevOps

• Verfügbarkeit (z.B. Lizenzierung)
• Automatisierbarkeit
• Verfügbarkeit von Werkzeugen
• Stabilität
• Geschwindigkeit

Aufwand

• Lizenzen und Wartungsverträge
• Betriebskosten
• Arbeitsaufwand
• Leerlaufzeiten
• Notwendige Abstimmungen

Verzögerungen

• Time-to-Market
• Zusatzkosten durch fehlende Funktionalität
• Ausweichkosten

Schlechtere Produktqualität

• Keine Agile, iterative Produkterprobung
• Testautomatisierbarkeit
• Zuverlässigkeit der Produkts
• Zuverlässigkeit der Prozesse

Konflikte

• Entwicklung vs. Test
• Entwicklung vs. Betrieb
• Entwicklung vs. Design
• Team vs. PO
• Team vs. Management
• Team vs. Architekturabteilung
• Abteilung vs. Abteilung
• Kostenstelle vs. Kostenstelle

Disclaimar

• Geiz ist NICHT geil
• Für Software Geld auszugeben ist nicht schlecht
• Passende Software kann viel Geld sparen
• Teurere Software ist nicht immer passender
• Gesamtkosten fürs Unternehmen im Auge behalten
• Kosten/Nutzen-Rechnung muss über die Laufzeit stimmen
• Man sollte schlechtem Geld nicht noch gutes hinterherwerfen

1. Tag im neuen Projekt

• 1 blanker Windows Rechner vom Kunden
• 2 DVDs
  1. DVD: Installationsmedium für den Java EE Server inkl. IDE
  2. DVD:
     • Handverlesende - stark veraltete - IDE-Plugins für SVN und Maven
     • Tomcat
• 1 lange Anleitung
• 4 Stunden harte Arbeit und viel Warten

Enterprise Java EE Application Server

• Turnaround Zeiten
• Manuelle Installation und Konfiguration
• Lizenzierung

Mögliche Auswege

• Tools wie jRebel, DCEVM
• Leichtgewichtigere Application Server für die Entwicklung
  • Mehr Aufwand in der Entwicklung
  • Debugging komplexer
  • ... warum nur in der Entwicklung?

Manuelle Installation und Konfiguration

• Abweichende Installationen
  • Updates
  • Konfigurationsänderungen
  • Plugins und Treiber
• Nicht nur bei den Entwicklern

Beispiel

Grüne Wiese: CRM, OM + Fulfillment

• Prio 1: Business Process Monitoring
• Prio 2: Änderung der Prozesse ohne Deployment
• Anfangs: Kaum echte Anforderungen

Rahmenbedingungen

• Processengine als eigenständiger Server
• Frontend und Backend mit Java EE
• Oracle DB
• Solaris Server
• Bis zu 50 Entwickler

Processengine als eigenständiger Server

• Läuft in einem Java EE Server
• Internes VCS
• Refactoring-Möglichkeiten: Rename
• Persistenter Zustand von Prozessen (Datei und DB)
• Java Fat-Client als IDE
• Keine lokale Entwicklung
• Testunterstützung:
  • Keine Unittests
  • Keine Mocks

Keine lokale Entwicklung

• 50 Entwickler
  ➥ Sehr viele Störungen

Integrationstests

Voraussetzungen

• Stabile Umgebungen
• Definierter Stand
• Automatisches Deployment

Stabile Umgebungen

• Umgebung 1: Wird von 4 Teams zu Entwicklung genutzt
• Umgebung 2: Als PRE-PROD alle paar Monate aktualisiert
• Umgebung 3: Prod

Definierter Stand

• Codehaltung in den Umgebungen
• Processengine mit eigenem VCS
• Interner Prozesszustand
• "Tagging" von angeschlossenen Tasks in eine weitere Umgebung

Automatisches Deployment

• Wurde in Zusammenarbeit mit dem Hersteller umgesetzt
• Vermeidet Fehler beim Staging
• Für Tests zu wenig Umgebungen

Zusammenfassung

• Störungen auf den gemeinsamen Umgebungen
  • Linderung durch Absprachen
  • Keine lokalen Entwicklerumgebungen
• Kein Refactoring in der BPM-Engine
• Kein übergreifendes Refactoring
• Deployment-Automatisierung für Staging
• Produktiv-Branch über zweite Umgebung für fertige Stories
• Automatisierte Tests auf dieser Umgebung
• Umgestaltung zur Schnittstellenreduktion
• Simulator für lokale Tests des Java EE Anteils

Testautomatisierungswerkzeug der Enterprise-Klasse

• Entwicklung in VB for Applications
• Integriertes VCS auf CVS-Niveau
• Exklusives Lock notwendig
• Client-Lizenzen knapp
• Getrennte Rechner und Netzwerke

Vorgehen

• Testobjekt: Heterogene Systemlandschaft
• Sehr späte Einbindung in den Entwicklungsprozess
• Blackbox-Tests
• Mehrtägige Tests
• Gegenspieler:
  Menschen die die Testdaten der automatisierten Tests gut gebrauchen konnten

Entwicklung in VBA

• Kein Entwickler entwickelt in VBA
  ➥ Manifestierung einer Grenze zwischen Test und Entwicklung

Integriertes VCS

• Kein Merging
• Exklusive Locks
  ➥ Skaliert nicht
  ➥ Nur ein Entwicklungsstrang

Clientlizenzen und Rechner

• Kein Test vor Integration von
  • Größere Änderungen
  • Framework Updates

Implikationen auf den Prozess

• Unzureichendes VCS
• Zu wenig Lizenzen
  ➥ Nicht in den CI-Prozess eingebunden
• Testanpassung, nachdem Story "done"
  ➥ Overload der Testautomatisierung
• Testautomatisierung außerhalb der fachlichen Teams
  • Wenig Fachwissen
  • Meistens wurden rote Tests "grün gemacht"
  ➥ Keine fachliche Regression

Beispiel

Migration einer Systemlandschaft

• Quellsysteme werden über die Datenbank angebunden
• Zielsystem wird über Services angesprochen
• Transformation, Validierung und Steuerung über Java EE Anwendung
• Quell und Zielsystem sind mehr als 10 Jahre im Betrieb
  ➥ Nicht alle Details bekannt
  ➥ Datenqualität nicht durchgängig gut

Motto

Ausprobieren und Testen

Zielsysteme

• Sehr heterogen
• Anlage eines Kunden ist nur 1 mal möglich
• Zwei Testinstanzen
• Jeweils 2 Resets pro Jahr

Ziel CRM

• J2EE-Anwendung im Enterprise Java EE Server
• Externes Prozessmanagement
• Mehrere Umsysteme direkt angesprochen
• Weitere Umsysteme

Mehr Instanzen durch VMs

• Trennung Konfigurations- und Laufzeitdaten
• Mocks und Simulatoren für Umsysteme / Prozessmanagement:
  • Lizenzierung
  • Know-how
  • Ressourcenbedarf
  • Hardware Plattform
• Application Server: Im Base-Image installiert und konfiguriert
• Stabilisierung Deployment
• Automatisierte Schemaänderungen
• Startup Zeit

Pay-per-use

• Simulator as a Service
• 0,05€/Request
• Manuelle Tests im Mittel weniger als 50 Requests / Tag:
  ~ 50€ / Monat
• Automatische Migration: bis zu 200.000 Requests / Migration :
  ~ 10.000€

Dediziertes UML-Werkzeug

• Erstellung korrekter UML-Diagramme
• Viel UML-Wissen notwendig
• Viel Werkzeugwissen notwendig
• Kein direktes Editieren aus der Dokumentation
  ➥ Teamfähigkeit eingeschränkt

Zeichenwerkzeuge

• Erstellung von UML-Diagramme mit vielen Freiheiten
• Weniger Unterstützung für UML
  • Kernfeatures auswählen und schulen
• Weniger spezifisches Werkzeugwissen notwendig
• Verfügbarkeit meistens besser
• Kein direktes Editieren aus der Dokumentation
  ➥ Teamfähigkeit etwas besser

Wiki-Tools

• Erstellung von UML-Diagramme mit sehr vielen Freiheiten
• Weniger Unterstützung für UML
  • Kernfeatures auswählen und schulen
• Weniger spezifisches Werkzeugwissen notwendig
• Direkte Einbindung in die Dokumentation
  ➥ Teamfähigkeit ok

Begrenzende Lizenzierung der Entwicklungsumgebung

• Nicht alle Teammitglieder können entwickeln

Begrenzende Lizenzierung der Testwerkzeuge

• Nicht alle Teammitglieder können lokal testen
• Tests erst nach der Integration
• Kein DevOps

Begrenzende Lizenzierung der Laufzeitumgebung für Entwickler-PCs

• Entwicklung auf geteilter Umgebung
• Viele Störungen in der Umgebung
• Kein DevOps

Begrenzende Lizenzierung der Laufzeitumgebung für Test und CI

• Nicht ausreichend Branches im CI für Integrationstests
• Manuelle und automatisierte Tests auf den gleichen Umgebungen
• Komplexere Testfälle
• Zu wenig Umgebungen für manuelle Tests
• Tests erst nach der Integration möglich
• Kein DevOps

Lösungsansätze

• Keine Reduktion von notwendigen Umgebungen im Vorfeld
• Einsatz vor dem Kauf planen
  • CI/Entwicklungslizenzen mit einhandeln
  • Lizensierung für Cloudbetrieb klären
• Personalbedarf realistisch planen
  • Mögliche Spitzen in Szenarien unterbringen
• Klärung für Externe
• Abteilungssysteme müssen auch außerhalb bereitgestellt werden
• Einfache Beschaffungsprozesse etablieren

Betrieb auf spezieller Hardware / Software

• Embedded Hardware
• Rechner in bestimmten Netzen / managed Pools
• Mainframe
• Solaris auf Sparc
• IBM Power

Lösungsansätze

• Entwicklung von Mocks und Simulatoren einplanen
• Realistische Anzahl + Puffer für Kostenabschätzung

Berechtigungen

• Werden restriktiv an Rollen vergeben

Lösungsansätze

• Rollenkosten verdeutlichen
• X-funktionale Teams fordern
  • Kosten von Rollendenken deutlich machen
  • Defizite und Möglichkeiten aufzeigen
  • Abteilungsdenken reduzieren

Fehlende Trennung von Code und Daten

• Probleme bei der Erstellung von minimalen Umgebungen
• Kein Gray-Box-Testing: Behindert Testautomatisierung

Closed Source

• Debugging schwieriger
• Kein Gray-Box-Testing: Behindert Testautomatisierung

Versionierung vom entwickelten Programmcode

• Interne Versionierung
• Keine Möglichkeit zum Mergen
  • Binärdaten
  • Komplexes XML
• Pessimistisches Locking
  ➥ Einschränkung der parallelen Bearbeitung
  ➥ Kleine gemeinsamen Feature-Branches
  ➥ Probleme bei der Testautomatisierung

Lösungsmöglichkeiten

• Hersteller fragen?

Pay-per-Use

• Mainframes
• PaaS, SaaS
• API-Aufrufe
• Mock-Dienste
• Storage

Auswirkungen

• Hohe Kosten bei vielen Tests
• Einschränkungen bei Massentests

Lösungsmöglichkeiten

• Kosten einplanen
• Simulatoren / Mocks einsetzen

Entscheidungen im Management

• Früh Kontakt aufnehmen
• Aktuelle Entscheidung ergründen
• Auswirkungen ausarbeiten
• "Eh-Da"-Kosten vs. Anschaffungen
• Versucht zu quantifizieren
• In €, $, Personentagen, ...
• Macht plausible Annahmen
  • Ruhig zu Euren Gunsten
  • Ein Vertriebsmitarbeiter macht nichts anderes
    ➥ Daher wird es erwartet

Beschleunigung durch Hardware

• Mehrkosten für Rechner: 1000€
• Einsparung am Tag: 20 min
• Entwicklertag: ~ 800€
• Einsparung pro Jahr: ~5000€

Zusammenfassung

• Bei jeder Kostenabschätzung den skalierten Fall im Auge behalten
  • Einen späteren Schwenk vorsehen
  • Oder Skalierung explizit ausschließen

Stefan Hildebrandt - consulting.hildebrandt.tk

• Beratung, Coaching und Projektunterstützung
• Java EE
• Buildsysteme gradle und maven/ant-Migration
• Testautomatisierung
• Coach in agilen Projekten
• DevOps