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 Datum Author Inhalt 0.1 9.4.2015 Dr. Kay Hübner Erstellung des Dokumentes und Struktur 0.11 14.4.2015 Dr. Kay Hübner Weitere Ausarbeitung, Projektplanung 0.12 15.4.2015 Dr. Kay Hübner Weitere Ausarbeitung erste Kapitel 0.2 16.4.2015 Dr. Kay Hübner Ausformulierung alle Kapitel, Projektplanung und Zukunftsplan 0.21 17.4.2015 Dr. Kay Hübner Rechtschreib und Grammatik Korrekturen 0.22 10.06.15 Dr. Kay Hübner Update Projektstatus 0.23 02.09.2015 Dr. Kay Hübner 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 Fernbereich. Dies wird erreicht durch den Betrieb des AtoBCarry welches die Transportdienstleistungen direkt und hochgradig automatisiert zwischen dem Auftraggeber und Transportunternehmer vermittelt. 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 80%, Kapazitätsplanung, Operator-Workflows, Onboarding/Tracking Receiver Applikation Frontend: Kapazitätsplanung, Operator-Workflows, Onboarding/Tracking Receiver 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