Nicht interne Architektur
Werkzeuge und Systeme "drumherum"
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
Kriterien in agilen und skalierten Umgebungen
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
- DVD: Installationsmedium für den Java EE Server inkl. IDE
- 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
Turnaround Zeiten
- Sehr unproduktiv
- Gefahr noch längerer Ablenkungen sehr groß
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?!?
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
Automatisierte fachliche Abnahmetests
- Durch Testabteilung
- Getrennt von der Entwicklung
- Testautomatisierungswerkzeug der Enterprise-Klasse
- Tabellen basiertes Testen
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€
Dokumentation als Gemeinschaftsaufgabe
- UI-Mockups
- Architekturdiagrame
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
Lösungsansätze nach Systemeigenschaften
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
- Pessimistisches Locking
➥ Einschränkung der parallelen Bearbeitung
➥ Kleine gemeinsamen Feature-Branches
➥ Probleme bei der Testautomatisierung
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
- Beratung, Coaching und Projektunterstützung
- Java EE
- Buildsysteme gradle und maven/ant-Migration
- Testautomatisierung
- Coach in agilen Projekten
- DevOps