SAMM Inc.
International operierendes Handelsunternehmen,
Verwaltungssitz in Durango, Colorado (USA), Zentrale in Berlin.
Bündelt Kompetenzen von über 500 Spezialisten der gesamten vertrieblichen
und technischen Bandbreite: Von der effizienten Beschaffung und
Partnerbetreuung über die Konzipierung und Einführung zukunftsweisender
Konfigurations- und Verkaufsprozesse bis hin zu kundenorientiertem Vertrieb
und Service.
Mit mehr als 1.900.000 Kunden weltweit, davon 900.000 in Europa ist die
SAMM Inc. international und innovativ aufgestellt, gleichzeitig traditionell und
auf nachhaltige Kunden- und Partnerorientierung fokussiert.
aus dem
Finanzbericht
Slide 5
Slide 5 text
1992 1997 2003 2008 2013
Atlas Software
GmbH & Co. KG
Dr. Blau &
Partner
Rot AG
Hodor KG
Ing-Büro
WebDev Inc.
(London +
München)
Rot Holding +
Rot Europa
SAMM
International
Gelb Finance AG
Tocherunternehmen
in Ungarn & Pakistan
Grau GmbH
2018
Slide 6
Slide 6 text
leben...
Slide 7
Slide 7 text
Wie groß soll Ihr
Regal sein?
Breite:
Höhe:
Tiefe:
Böden:
weiter…
Maße Material Farben Bestellung
cm
cm
cm
60
60
25
1
Beratung
http:/
/samm24.com/de/shop/furniture/config
Slide 8
Slide 8 text
Franz-Georg v.S.,
Leiter Verwaltungsreferat,
Deutsche Botschaft Brasilien
aktuelle
Situation
> starker Umsatzrückgang
bei Privatkunden
> Time-to-Market inakzeptabel
> bisher kein Markteintritt in
mobiles Internet
> Kaum Innovation bei Produkten
> Gravierende technische
Probleme
Slide 23
Slide 23 text
Friedbert
Board of Directors
(Vorstand), CEO Dr. Taler
Finance &
Controlling
Delivery Research
Information
Technology
External
Relations
BER BER
DUR
DUR
5
BER
BER DUR BER
DY IT FC ER RS
> CTO
> Früher: M&A
Slide 24
Slide 24 text
Fazit Friedbert:
Mit aktuellem System Innovation unmöglich:
> Code generell zu schlecht
> Eklatante Know-How Defizite bei VENOM
Slide 25
Slide 25 text
Vorschlag Friedbert:
bimodale IT
Lean, agile IT
Slide 26
Slide 26 text
Das Startup:
> Gründung in Berlin – wie SAMM Inc.
> Friedbert übernimmt Geschäftsführung
Slide 27
Slide 27 text
Big
Bang...
Spezifikation
einzelne
MA
Daten-
migration
Entwurf +
Entwicklung
Plan: ca. 30 MA,
3+ Scrum-Teams
100 Tage
> Vielversprechende Prototypen
> Ramp-Up verzögert
> bisher nur 6 (statt geplant 16) MA
> Abhilfe: Mehr Externe
Slide 30
Slide 30 text
6 Monate
> VENOM: Starker Rückgang von Umsatz & Ertrag
> Aufwändige Klärungen zentraler Anforderungen
verzögert Features in neuem System
> byzz.io: Erste Kündigungen
Slide 31
Slide 31 text
12 Monate
Management entscheidet:
> Neues System geht (vorzeitig) live
> Datenmigration wird „fertig“ erklärt
Slide 32
Slide 32 text
sofort danach...
> Neues System zeigt desaströse Fehler im Betrieb
> byzz.io Administration massiv überfordert
> Resultate führen zu:
> Rollback auf Bestandssystem VENOM
> Rollback der Datenmigration
Slide 33
Slide 33 text
Aufsichtsrat interveniert
Slide 34
Slide 34 text
SAMM Inc.
Friedbert H. übernimmt BER
Friedbert H., langjähriger IT-Leiter der SAMM Inc., übernimmt zu
Jahresbeginn die technische Leitung des BER Flughafen Berlin-
Brandenburg.
Die Sprecherin der SAMM Inc. lobte die gute Zusammenarbeit und
die erfolgreiche Umsetzung selbst kritischer Projekte – mit
Friedbert H. verlöre die SAMM Inc. eine außergewöhnliche
Führungspersönlichkeit.
aus der
Presse...
Slide 35
Slide 35 text
Aaron S.
Slide 36
Slide 36 text
Systematische Modernisierung
e
valuate
analyze
improve
https://aim42.org
Slide 37
Slide 37 text
aim42 liefert...
> konkrete Probleme („Schmerzen“)
> Prioritäten („Schmerzkosten“)
> Vorschläge für Abhilfen
Slide 38
Slide 38 text
Systematisch verbessern
Maßnahmen
Probleme
(priorisiert)
Karin L.
> „DRAG“ – massive
Abhängigkeiten
> immer mehr Überstunden
> immer weniger Überblick
> Kaum Innovation
Karin, Entwicklerin
Slide 42
Slide 42 text
Karin L.
> Kleine Änderungen dauern
immer länger
> immer mehr Fehler
> Zu hohe technische
Schulden
Michael,
UI-Entwickler
Slide 43
Slide 43 text
Karin L.
Stakeholder
Kennen (viele)
Probleme
Releases
benötigen viele
manuelle Eingriffe
falsche Daten
im Archiv
aufwändige
Kommunikation
mit Marketing
Betriebsübergabe
von einzelnen
Personen abhängig
Build-Prozess
inhomogen,
langsam und
instabil
zuviele
Abhängigkeiten zw
Teilsystemen
Level-1: Component Disorder
Enge Kopplung der
Pricing Engine
Haskell
Entwicklerin zu
selten anwesend
konkrete Preise
hängen von zu
vielen Parametern
ab
„Heisenbugs“ bei
Preisberechnung
„komplizierte“
Interaktion zwischen
Validierung und
Preisbestimmung
Pricing-
Schnittstelle(n)
sehr volatil
Slide 48
Slide 48 text
Karin L.
> Analyse der Code-
Historie
> Suche Hotspots
Code
Archäologie (1)
Adam Tornhill: Your Code as a Crime Scene
Datenmodell auf AS/400...
> 5 Tabellen, jeweils 400 Spalten
> Massiv (!) gekoppelt
... (500)
... (300)
... (400)
... (400)
... (400)
Massive
Performanceprobleme
Daten-Chaos (2)
zentrale Tabellen
zu breit + zu eng
gekoppelt (4x400
Spalten)
Slide 54
Slide 54 text
Analyse
Stakeholder
Process
Architecture
+ Code
Data
Context
Organization
Docs
analyze
crosscutting
Flash-Konfigurator
zu aufwändig in
der Pflege
falsche Daten
im Archiv
Enge Kopplung der
Pricing Engine
Releases dauern
zu lange
Releases
benötigen viele
manuelle Eingriffe
zu hoher Anteil an
manuellem Test
Betriebsübergabe
von einzelnen
Personen abhängig
Haskell
Entwicklerin zu
selten anwesend
konkrete Preise
hängen von zu
vielen Parametern
ab
Know-How
Flaschenhälse in
Entwicklung und
Betrieb
Einkauf &
Produktdesign
komplett un-agil
Scrum in Entwicklung
kollidiert mit
Planung in
Fachbereichen
Produktdaten
verteilt auf zwei
Sales-Backends
mangelnde Qualität
(Performance, Robustheit,
Verfügbarkeit, Sicherheit) bei
Verkaufs- und Vertragsdaten
„Heisenbugs“ bei
Preisberechnung
„komplizierte“
Interaktion zwischen
Validierung und
Preisbestimmung
Expertenwissen über
Konfiguration verteilt auf
Prolog und Drools
Flash als
Sicherheitsrisiko
zu viele
Datenquellen
Pricing-
Schnittstelle(n)
sehr volatil
optisches Archiv
enthält falsche
Daten
Slide 55
Slide 55 text
Fazit Aaron
> Codequalität in Teilbereichen schlecht
> Viele Teile „gut genug“
> Hohe Kompetenz in Team(s) vorhanden
> Datenmigration zu riskant
Slide 56
Slide 56 text
Systematische Modernisierung
> Keep Treasures: Continous Restructure
> Transformation zu SCS („Modularisierung“)
> Dabei: Schneller Abbau kritischer HotSpots
> Auf Datenmigration weitgehend verzichten
> Transition zu agiler Organisation
Slide 57
Slide 57 text
Verbesserung mit Tagesgeschäft
integrieren...
day-to-day development
Practices
Practices
time
Approaches
Practices
Practices
Practices
Practices
Slide 58
Slide 58 text
Architektur-Modernisierung (1)
Change-by-Split
Client
Type 1
Flawed
System
Client
Type 2
Client
Type 1
Reduced to
Type 1
Client
Type 2
Reduced to
Type 2
New Type 1
System
Client
Type 1
Client
Type 2
New Type 2
System
Slide 59
Slide 59 text
Architektur-Modernisierung (2)
Change-by-
Extraction
Client
Flawed
(incohesive)
System
Client
„other“ other
features
Client Flawed
System
Client
„other“
other
features
Better
other features
Client
(reduced)
Flawed
System
Client
„other“
Slide 60
Slide 60 text
Venom-Splits (1)
Venom, Split-1
NGOs,
User Groups
Venom, Split-2
Private
User
Corporate
Users
Government
Users
Operations
Internal
Users
Operations
Internal
Users
Slide 61
Slide 61 text
Venom-Splits (2): NGO-Spezifika
NGOs,
User Groups
Operations
Internal
Users
kann
entfallen
Security
Extensions
Sales Frontend
Private + Corporate
Configurator Shell
Client
Contracts
UDS
(User Data Service)
Order &
Fullfillment
Voucher
s &
Rebates
eGov
Shop
Sales &
Contracts
Archive
External
Partners
Price
Manageme
nt
Data
Warehouse
Marketing &
Sales
Campaigns
Atlas
Customs &
Logistics
Pricing
Engine
Sales
Backend
Private+Corp
Hodor
Optical
Archive
Post-Sales
Services
Sales
Backend
eGovernme
nt
Slide 62
Slide 62 text
Venom-Splits (3): Commons
common
NGOs,
User Groups
Operations
Internal
Users
Sales
Frontend
Client Data
NGO User
Management
Inventory
Sales Order &
Contracts
Archive
Pricing
Engine
Sales
Backend
Security
Extensions
DB Commons
Client Contract
Common
Price Mngmt
Commons
Common User
Data
verkleinert
Geschätzte Reduktion:
von ursprünglich 2 Mio LOC auf <200 kLOC im NGO-Split
Services
Slide 63
Slide 63 text
2 Monate später...
Retrospektive zu NGO Split:
> time-to-market: 5 Tage (statt vorher >30)
> Prod-Bugs: <2/Woche (vorher >10)
> Developer-Happyness: ++
> Inter-Team Abstimmung aufwändig
> Scrum-of-Scrum für Common Services
Slide 64
Slide 64 text
gleichzeitig...
weitere Splits in Vorbereitung:
> Government
> Pharmacy
> Private
Slide 65
Slide 65 text
Systematische Modernisierung
Isolate-Core-Domains
(à la DDD)
Flawed
System
Legend:
Domain
Fragments
Better (modularized)
System
Core
Domain
Slide 66
Slide 66 text
9 Monate später...
> Re-Architecture Pricing-Engine
(Java statt Haskell)
> Jboss Drools mit modularen Regel-Sets
> Merge von Price-Management und
Price-Engine
SAMM
Inc.
SAB holt Experten für innovative
Softwarearchitektur
Aaron Schwarz, bei SAMM Inc. bis dato verantwortlich für die Entwicklung des
internen VENOM-Systems, gab auf seinem privaten Blog seinen Wechsel zur
SAB AG in Walldorf bekannt.
Schwarz hatte SAMM Inc. mit einem stringenten Modernisierungskonzept
innerhalb von nur 18 Monaten aus der Krise geführt. Das VENOM System gilt
mittlerweile als ein Vorbild für erfolgreiche Digitalisierungsstrategien im
e-Business.
Schwarz schreibt, die VENOM-Teams wären “flügge“ – und benötigten seine
Unterstützung nicht mehr. Bei der SAB AG leitet er zukünftig die Software-
Entwicklung der neu gegründeten SABank.
aus der
Presse...
Slide 69
Slide 69 text
venom-story.org
Gernot.Starke@innoq.com
Slide 70
Slide 70 text
Dr. Gernot Starke
Gernot.Starke@innoq.com
https://www.flickr.com/photos/foto_db/16000636092