AtoBCarry_IT_Architektur_0 23 (00000002)

IT Architektur
Dokument Author: Dr. Kay Hübner
Dokument Owner: Jürgen Sprang
Dokument Version: 0.23
Letztes Update: 01.09.2015
Dr. Kay Hübner
Seite 1 von 12
17:14:23
1Dokument Historie ............................................................................................................................. 3
2Projektbeschreibung und technische Anforderungen ........................................................................ 3
3Server Setup ....................................................................................................................................... 4
4Builds und Continuous Integration .................................................................................................... 6
4.1Continuous Integration ............................................................................................................... 6
4.2Builds ......................................................................................................................................... 6
4.3Configurations ............................................................................................................................ 6
4.4„Rapid Development“ ................................................................................................................ 6
5Server – Java Applikationen, Datenbank und Frameworks ............................................................... 7
5.1Backend MVC Applikationen .................................................................................................... 7
5.2Tracking Applikation ................................................................................................................. 7
5.3Datenbank und Testing............................................................................................................... 7
6Frontend – Javascript und Frameworks ............................................................................................. 8
7Marketing Webseite ........................................................................................................................... 8
8Entwicklungsmethodik....................................................................................................................... 8
9Sonstiges ............................................................................................................................................ 8
10Hardware – Onboard Tracking ........................................................................................................ 9
11Status & Projektplanung .................................................................................................................. 9
12Zukunftsplan .................................................................................................................................. 11
Dr. Kay Hübner
Seite 2 von 12
17:14:23
1 Dokument Historie
Version
0.1
Datum
9.4.2015
Author
Dr. Kay Hübner
0.11
0.12
0.2
14.4.2015 Dr. Kay Hübner
15.4.2015 Dr. Kay Hübner
16.4.2015 Dr. Kay Hübner
0.21
0.22
0.23
17.4.2015 Dr. Kay Hübner
10.06.15 Dr. Kay Hübner
02.09.2015 Dr. Kay Hübner
Inhalt
Erstellung des Dokumentes und Struktur
Weitere Ausarbeitung, Projektplanung
Weitere Ausarbeitung erste Kapitel
Ausformulierung alle Kapitel, Projektplanung
und Zukunftsplan
Rechtschreib und Grammatik Korrekturen
Update Projektstatus
Update Projektstatus
2 Projektbeschreibung und technische Anforderungen
„AtoBCarry bringt Auftraggeber und Fuhrunternehmer zusammen, verbessert die Auslastung
der LKWs und bringt Transparenz in die Angebote.“
AtoBCarry vermittelt Transportdienstleistungen im Straßengüterverkehr in Nah-, Regional- und
wird erreicht durch den Betrieb des AtoBCarry welches die
Transportdienstleistungen direkt und hochgradig automatisiert zwischen dem Auftraggeber
und Transportunternehmer vermittelt.
Fernbereich.
Dies
AtoBCarry stellt sicher, dass alle zum Transport gehörenden Dokumente (inklusive
Rechnungen) im Namen des Transportdienstleisters für den Auftraggeber einfach und
automatisiert zur Verfügung gestellt werden.
Alle über das System abgewickelten Sendungen, sind von der Buchung bis zur Abrechnung
im System für alle Beteiligten sichtbar.
Das Projekt stellt folgende Kernanforderungen an die Technik, welche von Anfang an berücksichtigt
werden:
•
Sehr hohe Verfügbarkeit (durch einen Ausfall steht der Betrieb und es können keine Aufträge
entgegengenommen oder ausgeführt werden)
•
Skalierung essentiell (die geplante Anzahl an Benutzern stellt hohe Anforderungen an
Skalierbarkeit des System, weil mehr Fahrzeuge und Benutzer mindestens lineare
Anforderungen an die Belastbarkeit des Systems stellen)
•
Mehrsprachigkeit
•
Hohe Testabdeckung (viele Zentrale Anwendungsfälle sind betriebsrelevant und deswegen wird
eine hohe Testabdeckung von Anfang an angestrebt)
•
Sicherheit (es werden sensible Daten verarbeitet und es gibt verschiedene Ansichten für die
verschiedene Rollen)
•
Wartbarkeit (es arbeitet ein Team von Entwicklern von Anfang an am System und es findet eine
konstante Weiterentwicklung statt)
Dr. Kay Hübner
Seite 3 von 12
17:14:23
3 Server Setup
Es werden die Amazon EC2 Services für die Entwicklung und Serverumgebung benutzt.
Insbesondere folgende Services von Amazon sind im Einsatz:
•
EC2 Server (Linux Server, entweder Amazon Linux oder Ubuntu 14.04LTS)
•
Elastic Beanstalk (automatische Skalierung von Java Applikationen abhängig von der aktuellen
Last)
•
Amazon Route53 (skalierbares und hochverfügbares DNS insbesondere für Amazon
Loadbalancer)
•
Monitoring
•
Alerting (Benachrichtung bei Serverproblemen)
•
Weltweites Clustering und Redundanz (Serverinfrastruktur weltweit)
•
S3 Filestorage
Für die Entwicklung gibt es folgende Server „Environments“:
•
„local“ (jeder Entwickler entwickelt grundsätzlich lokal)
•
„dev“ (zentraler Development Server)
•
„stage“ (Abnahme Server, identisch zu live)
•
„live“
Auf „local“ entwickelte Features werden in der Regel in einem separaten „Branch“ entwickelt und in den
Hauptzweig „gemerged“ wenn ein Feature fertig ist. Dieses entspricht der „Best
Practice“ Vorgehensweise des verwendeten Sourcecode Verwaltungssystems „git“, welches in diesem
Projekt verwendet wird. Der Workflow sieht dann so aus:
Dr. Kay Hübner
Seite 4 von 12
17:14:23
Des Weiteren werden folgende Komponenten für die Entwicklung benutzt:
•
Bitbucket (als kommerzielle Sourcecode Versionsverwaltungslösung)
•
Bamboo (kommerzieller Continuous Integration Server)
•
Jira (Bugtracking und Planungstool für Agile Software Entwicklung)
•
HipChat (Kommunikationstool des Entwicklungsteams)
Dr. Kay Hübner
Seite 5 von 12
17:14:23
4 Builds und Continuous Integration
4.1 Continuous Integration
Unter Continuous Integration versteht man das laufende Ausliefern von aktuellen Softwareständen. In
diesem Projekt wird jedes Feature, welches einen bestimmten Entwicklungsstand erreicht hat, vom
Entwickler in das Sourcecodeveraltungssystem eingecheckt. Nach einer kurzen Zeit (<15 Minuten) steht
der aktuelle Entwicklungsstand auf dem zentralen „dev“ Server zur Verfügung und kann getestet werden.
Dieser Prozess ist weitgehend automatisiert. Zusätzlich gibt es einen automatischen Prozess um ein
„stage“ Release zu erzeugen.
In diesem Prozess, auch das ist eine Aufgabe des Continuous Integration Servers, sind Qualitätschecks
mit eingebaut. Ein Release wird z.B. nur durchgeführt, wenn eine definierte Testabdeckung erreicht wird.
Dadurch wird die Entwicklung mit einer bestimmten metrischen Qualität erzwungen, was spürbare
Verbesserung des Codes zur Folge hat und perspektivisch auch die Fehlerrate reduziert. Eine weiterer
Vorteil dieser Vorgehensweise ist es, dass über die Entwicklungszeit bestimmte, messbare, Fortschritte
geplant und umgesetzt werden können (siehe Kapitel Projektplanung).
4.2 Builds
Als sogenanntes „Build-Management-Automatisierungs-Tool“ wird Gradle verwendet. Im Gegensatz zu
konkurrierenden Tools wie „Maven“ haben folgende Gründe den Ausschlag gegeben:
•
Direkt ausführbarer Code und dadurch hohe Geschwindigkeit durch Parallelisierung
•
Vorteile der Konkurrenz Tools enthalten
•
Komplexe „Bauprozesse“ lassen sich elegant und effizient herunter brechen
•
Leicht erweiterbar
•
„State of the art“ mit guter Reputation
4.3 Configurations
Für verschiedene Umgebungen („dev“, „stage“, …) werden verschiedenen Konfigurationen benötigt. Das
ist notwendig, damit derselbe Code auf verschiedenen Umgebungen ohne Änderung laufen kann. Zu
diesem Zweck wird das sogenannte Feature „Spring Profile“ eingesetzt.
4.4 „Rapid Development“
Die gesamte Entwicklungsumgebung ist auf Effizienz und hohe Qualität ausgelegt. Eine weitere
Komponentenentscheidung in diese Richtung ist die Benutzung von Spring Boot, welches den Vorteil
bietet, effizienteren, und am Ende besser wartbaren, Code zu produzieren. Zudem ist die Einstiegshürde
(z.B. für neue Entwickler) dadurch niedriger und qualifiziertes Personal kann sich schneller einarbeiten.
Dr. Kay Hübner
Seite 6 von 12
17:14:23
5 Server – Java Applikationen, Datenbank und Frameworks
5.1 Backend MVC Applikationen
Die Backend Applikation ist mit Java 8 und Spring MVC realisiert.
Folgende Komponenten spielen wichtigen Rollen in der IT Konzeption von AtoBCarry:
•
Basierend auf dem aktuellen Java 8
•
Als Application Server wird Tomcat 8, ebenfalls aktuelle Version, benutzt
•
Als Framework wird Spring MVC mit diversen „plugins“ wie Spring Boot und Spring Profile benutzt
•
Hibernate als ORM Mapper mit QueryDSL als weitere SQL Abstraktionsschicht
•
Athmosphere Push Framework (Realtime Updates von Webseiten)
•
Quartz (skalierbarer Scheduler)
•
Swagger und Swagger-UI (Dokumentation der REST Schnittstelle im Sourcecode, Debugging
und Testing)
•
JavaMelody (Monitoring auf Code Ebene wie z.B. CPU Last und Speicherverbrauch, auch SQL
Monitoring)
5.2 Tracking Applikation
Der Tracking Server, momentan noch im Backend Server eingebaut, ist perspektivisch eine separate
Applikation um das Geo-Tracking der Fahrzeugen zu entwickeln, warten und skalieren zu können. Der
Hauptjob ist das zur Verfügung stellen eine API für die Tracking Daten (auf welches das Backend dann
zugreift).
Es kann diese Daten von verschiedenen Geräten empfangen, momentan sind das die IOS und Android
Applikationen, später auch separate Tracking-/Telematik-Boxen mit eigener Hardware.
5.3 Datenbank und Testing
Als Datenbank wird PostgreSQL eingesetzt, weil diese professionellen Ansprüchen näher kommt als wie
z.B. MySQL. Das sind insbesondere Features wie JSON oder Geo-Abfragen direkt auf Datenbank Ebene
verarbeiten zu können. Perspektivisch ist der Einsatz von NoSQL Datenbanken denkbar.
Als Unit Testframework wird Spock wegen seiner ausdrucksstarken Syntax eingesetzt.
Dr. Kay Hübner
Seite 7 von 12
17:14:23
6 Frontend – Javascript und Frameworks
Im Frontend werden folgende Kerntechnologien eingesetzt:
•
AngularJS, Angular UI, Angular Gantt (für die Kapazitätsplanung) und Angular Google Maps
•
Angular Konzepte: Promises und Angular Form Validierung
•
LessCSS (CSS Optimierungen und Verbesserungen)
•
Für das Testing: Jasmine und Karma (inklusive Historie der Resultate)
•
Build: Yeoman, Grunt und Bower
•
Atmosphere für Push-Technologie
Die Code Coverage im Frontend wird im Continuous Integration Prozess überwacht.
7 Marketing Webseite
Die Marketingseite ist in Wordpress umgesetzt. Hauptgrund dafür ist die einfache Pflege von Inhalten für
Marketing Optimierungen. Die Registrierung und der Login sind mit dem Java Backend verknüpft, so
dass sich für den Benutzer eine einheitliche Benutzerführung ergibt.
8 Entwicklungsmethodik
Momentan steht ein Entwicklungsteam von 4 erfahrenen Software Entwicklern und ein Projekt Manager
/ Scrum Master zur Verfügung. Es wird nach agilen Softwareentwicklungsprinzipien gearbeitet mit kurzen
Sprints von ca. 2 Wochen. Diese Vorgehensweise stellt eine regelmäßige Anpassung an die
Gegebenheiten sicher und fördert den Teamzusammenhalt.
Die Screens werden mit abstrakten Mockups/Wireframes und User Stories erarbeitet.
Dem Team steht eine Design Expertin zur Verfügung. Die Design Vorschläge, ausgehend von den
vorbereitenden Mockups, durchlaufen mehrere Iterationen bevor sie in möglichst Pixel genauen
HTML/CSS Code umgesetzt werden.
Aktuelle Technologien/Methoden wie Responsives Verhalten für verschiedene Endgeräte werden
eingesetzt.
Smartphone Endgeräte erhalten eine eigene, speziell für kleine Endgeräte angepasste, Benutzerführung.
9 Sonstiges
Folgende weitere Technologien spielen eine wichtige Rolle im Gesamtkonzept:
•
letteral (Mail-Versand und Templating)
•
liquibase (Database Refactoring und Versionierung)
•
H2 Datenbank (für den „dev“ Server)
•
cobertura (Testabdeckung)
Perspektivisch müssen noch Lösungen für das Verschicken von SMS, Pushnachrichten und E-Mails
erarbeitet werden.
Dr. Kay Hübner
Seite 8 von 12
17:14:23
10 Hardware – Onboard Tracking
Das aktuelle Konzept sieht Smartphone Applikationen für die eigentlichen Fahrer der Fahrzeuge vor.
Dieses deckt insbesondere folgenden Funktionalitäten ab:
•
Nah Echtzeit Geo-Tracking
•
Fahrer Aktionen für den Auftragsprozess (Ware abholen und abliefern, Problemfälle und weiteres)
Um diese wichtigen Aufgaben für das Gesamtsystem besser in abbilden zu können ist eine spezielle
Hardware-Box in der Entwicklung. Diese braucht nur eine SIM Karte um die aktuelle Position ohne
weitere Fahreraktionen übertragen zu können. Über ein mögliches Touchdisplay könnte der Fahrer auch
das Auftragshandling einfacher abwickeln.
Diese Box basiert auf dem Linux Betriebssystem und kann mit eigener Software versehen werden.
Perspektivisch sollen auch die Fahrer- und Mautdaten über diese Box erfasst und dem Fuhrunternehmer
zur Verfügung gestellt werden.
11 Status & Projektplanung
Der aktuelle Stand bis einschließlich August 2015:
•
Konzeption des Systems (Auswahl einer geeigneten IT- und Systemarchitektur)
•
Lastenheft als Funktionsbeschreibung
•
Mockups/Screen Konzepte vieler Anwendungsseiten
•
Teilumsetzung des Angebotsverfahrens und der Stammdatenverwaltung
•
IOS/Android App (Grundzustand, für das Geo Tracking und das Fahrer Handling)
•
Funktionierendes und erfahrenes Entwicklerteam
•
Aufgesetzte „dev“, „stage“ und „live“ Server
•
Eingerichtetes Continuous Integration System und Server Architektur
•
Funktionierende Entwicklungsprozesse (z.B. der agile Entwicklungsprozess)
•
Laufende Applikation (Backend und Tracking Server)
•
Laufende Marketingseite (mit Design)
•
Planung für Version 1.0 in ca. 7 Monaten
•
Hardware Komponente: Box Vorbereitung
•
Implementiertes und überwachtes Testing
•
Definierte Testabdeckung
Dr. Kay Hübner
Seite 9 von 12
17:14:23
Ausgehend von diesem fortgeschrittenen Status lässt sich das Gesamtprojekt auf IT-Seite fortentwickeln.
Die Einbeziehung eines größeren Teams und die Parallelisierung ist innerhalb der vorhandenen
Strukturen möglich.
Folgendes ist der Status der einzelnen Projektbestandteile:
•
Marketingseite: Design entwickelt, Design V1.0 umgesetzt, Registrierung, Anmeldung
vervollständigt
•
Applikation Backend: Anmeldung/Registrierung umgesetzt, Auftragsflow inklusive einiger Stornound anderer Konfliktfälle umgesetzt, Spotpreis/AdHoc Preis umgesetzt (mit vereinfachten
Annahmen),
Zonenpreismodell
umgesetzt,
geobasierte
Workflows
angefangen,
Rechnungsworkflow und Bewertungs- sowie Archivfunktionalität umgesetzt, News-Center
umgesetzt, Screens CRUD und Convenience Funktionen, Testabdeckung 70%
•
Applikation Frontend: Anmeldung/Registrierung umgesetzt, geobasierte Workflows angefangen,
Kapazitätsplanung angefangen, 12 Fuhrunternehmer- und 9 Auftraggeber-Screens funktional
(mit einigen vereinfachenden Annahmen) umgesetzt, 7 Verwaltungs-Screens funktional, Design
in Entwicklung
•
Applikation Tracking: Eingerichtet, IOS & Android App für das Tracking umgesetzt
Im folgenden die aktuelle Planung bis Version 1.0:
September 2015
•
Applikation Backend: Testabdeckung 70%, geobasierte Workflows (USP)
•
Applikation Frontend: geobasierte Workflows (USP)
Oktober 2015
•
Applikation Backend: Testabdeckung 75%, Kapazitätsplanung, geobasierte Workflows (USP)
•
Applikation Frontend: Kapazitätsplanung, geobasierte Workflows (USP)
November 2015
•
Marketingseite: Ausarbeitung weiterer Seiten (Impressum, Kontakt, …), Verbindung
Marketingseite & Applikation, Preise Seite, evtl. Features-/Erklärungsseite weiter ausarbeiten
•
Applikation Backend: Testabdeckung
Onboarding/Tracking Receiver
•
Applikation Frontend: Kapazitätsplanung, Operator-Workflows, Onboarding/Tracking Receiver
80%,
Kapazitätsplanung,
Operator-Workflows,
Dezember 2015
•
Applikation Backend: Testabdeckung 85%, Kapazitätsplanung, Operator-Workflows
•
Applikation Frontend: Kapazitätsplanung, Operator-Workflows
•
Marketingseite: Umsetzung weiterer Seiten
•
Marketingseite: Smartphone Version Draft
Januar 2016
•
Applikation Backend: Testabdeckung 90%, Operator-Workflows
Dr. Kay Hübner
Seite 10 von 12
17:14:23
•
Applikation Frontend: Operator-Workflows
•
Marketingseite: Design Smartphone Version final
•
Marketingseite: Design Smartphone Version Implementation
•
Smartphone Version Main App Umsetzung
•
Applikation Tracking: IOS & Android native Apps umsetzen
Februar 2016
•
Missing Features & Details
•
Applikation Tracking: IOS & Android native Apps umsetzen
März 2016
•
Missing Features & Details
•
Probebetrieb
•
Testing, Bugfixing
April 2016
•
Testing, Bugfixing,
•
Probebetrieb
•
Abnahme-Phase
•
Version 1.0 laut Lastenheft
12 Zukunftsplan
Die folgenden Auswahl an Punkten (nicht vollständig), für eine zukünftige Umsetzung, müssen noch
geplant werden:
•
Einsatz von RFID Chips und Druckern für den Fahrer und für zukünftige Storage Center
•
Einsatz von digitalen Lieferscheinen
•
Weiterentwicklung der Hardware-Box (Mautdaten, Fahrtenschreiber, Dockingstation Handys
IOS/Android)
•
Erweiterte Kapazitätenplanung und erweiterte Fuhrparkverwaltung
•
Sammelaufträge
•
Eigene Storage Center (inklusive z.B. optimierte Anwendungen für Lagerristen)
•
Eigene optimierte Lageranwendung für die Storage Center (deutschlandweit bis zu 60 Storage
Center geplant)
•
Lückenlose Lieferkette z.B. durch Unterstützung von See- und Luftfracht
•
Erweitertes Mapping mit Geotracking (z.B. Staus und Live Lieferzeiten)
•
Alarmsystem im LKW (z.B. bei besonders teurer Ware, z.B. wenn vorgegebene Touren verlassen
werden)
Dr. Kay Hübner
Seite 11 von 12
17:14:23
Das aktuelle Pitchdeck sieht folgenden groben Zeit- und Ausbauplan vor:
•
Ausbau Deutschland 2-3 Jahre
•
Einführung von Storage Centern in 3-4 Jahren
•
Ab 4./5. Jahr Kapitalerhöhung und Europaweiter Ausbau (inkl. Osteuropa)
•
See- und Luftfracht ab dem 5. Jahr
Dr. Kay Hübner
Seite 12 von 12
17:14:23