WHITEPAPER
Context-Aware Frontend Architecture
Beispielszenarien für eine kontextsensitive Applikationslandschaft
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Context-Aware Frontend Architecture
Beispielszenarien für eine kontextsensitive Applikationslandschaft
AUTOREN:
Richard Attermeyer,
Stephan Rauh & Rolf Scheuch,
OPITZ CONSULTING
Deutschland GmbH
KONTAKT:
rolf.scheuch@
opitz-consulting.com
+49 2261 6001-1223
Inhaltsübersicht
Vorwort
VORWORT
Mit der Zusammenstellung dieser aktuellen Fallstudien
möchten wir Ihnen einen Ansatz für eine zukunftsfähige
Applikationslandschaft zur Unterstützung der digitalen
Transformation vorstellen. Eine flexible und auf alle Kanäle
und Geräte (Omni Channel) ausgerichtete Context-Aware
Frontend Architecture (CAFA) kann Ihnen als Blueprint bei
der Modernisierung und Transformation Ihrer bestehenden
Systeme auf eine flexible Applikationslandschaft dienen.
Die Referenzarchitektur basiert auf unseren Erfahrungen aus
unterschiedlichen Projekten. Alle vorgestellten Fallstudien
setzen darauf, die bislang monolithischen (Legacy-)Systeme
durch neue flexible Applikationsarchitekturen zu ersetzen
und entkoppeln dabei Frontend- und Backend-Dienste.
Treiber waren die Digitalisierung der bestehenden Geschäftsmodelle sowie ein „Design for Change“-Ansatz zur schnellen
Implementierung neuartiger digitaler Geschäftsmodelle.
MOTIVATION
QUALITÄTSMERKMALE
GESCHÄFTSPARTNER AUF EIGENER PLATTFORM EINBINDEN
BLUEPRINT CONTEXT-AWARE FRONTEND ARCHITECTURE
FALLSTUDIEN – ÜBERBLICK
FS 1: WACHSTUMSSICHERUNG MITTELS API MANAGEMENT
FS 2: HÖHERE KUNDENBINDUNG DURCH DIGITALISIERUNG
FS 3: INDUSTRIE 4.0 AUF DEM SHOP FLOOR
FS 4: FLEXIBILISIERUNG DER STANDARDSOFTWARE
WAHLFREIHEIT: MAKE & BUY
Bei unseren Fallstudien haben wir unseren Fokus auf die
Architektur und ihre Motivation gerichtet. Wichtig war es uns
außerdem, die Lessons Learned aus den Retrospektiven
festzuhalten. Andere Themen wie z. B. die Implementierungsphase haben wir dagegen etwas kürzer gehalten.
ORGANISATORISCHE IMPLIKATIONEN
CHANCEN & RISIKEN
Gerne klären wir offene Fragen mit Ihnen oder erläutern
tiefere Details aus den Projekten. Sprechen Sie uns an.
ZUSAMMENFASSUNG
ANMERKUNGEN & QUELLEN
ÜBER OPITZ CONSULTING
Texte und Abbildungen wurden mit größter Sorgfalt erarbeitet. OPITZ CONSULTING kann jedoch für eventuell fehlerhafte Angaben und deren Folgen weder eine
juristische Verantwortung noch irgendeine Haftung übernehmen. Das Recht an dar-gestellten Verfahren, Showcases, Implementierungsbeispielen und
Source Codes liegt ausschließlich bei OPITZ CONSULTING.
© OPITZ CONSULTING GMBH 2016
SEITE 2
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Motivation
Qualitätsmerkmale
Mit zunehmendem Wettbewerbsdruck müssen Unternehmen ihre Geschäftsmodelle und -prozesse in immer kürzer
werdenden Zyklen anpassen. Gleichzeitig wird die Interaktion
mit externen Geschäftspartnern durch Globalisierung und
digitale Vernetzung immer komplexer. Verlässlicher Informationsaustauch mit qualitativ hochwertigen Daten entscheidet
darüber, ob Prozesse effizienter werden und Kundenbindung
erhöht wird. Gleichzeitig ermöglicht die rasante technologische Entwicklung innovative Ansätze bei der MenschMaschine-Interaktion. Diese Herausforderungen setzen die
bislang gewachsenen Applikationslandschaften unter Druck:
Eine grundlegende Veränderung erscheint unumgänglich.
Auf die genannten Treiber möchten wir im Folgenden ausführlicher eingehen, weil sich in diesen Herausforderungen
implizit
auch
Qualitätsmerkmale
der
zukünftigen
Applikationsarchitektur verbergen.
Kein Wunder, dass das Thema der Modernisierung von bestehenden Applikationen und Legacy-Systemen deutsche
Unternehmen momentan beschäftigt wie kein anderes. Viele
dieser Alt-Systeme bewirken eine „strukturelle Zukunftsunfähigkeit“1), wenn es um die Weiterentwicklung der Applikationslandschaft geht. Diese integrierten und umfänglichen
Systeme, auch Monolithen genannt, erweisen sich als änderungsresistent. Zukünftige Applikationsarchitekturen erfordern ein Umdenken in den Unternehmen. Bei unseren Kunden sehen wir die folgenden grundlegenden Treiber für den
Umbau der Applikationslandschaften:
■
VERBESSERUNG DER MENSCH-MASCHINE-INTERAKTION
Computergestützte Benutzerschnittstellen sind aktuell im
Umbruch. Vor wenigen Jahren war die Oberflächenwelt noch
überschaubar. Es gab Desktop-Anwendungen, Webbasierte
Interfaces und native Oberflächen für spezielle Devices wie
Smartphones. Nun aber verschwimmen diese Grenzen durch
den Industriestandard HTML5 und neue Trends wie den Instant Apps2) oder den Universal-Apps bei Microsoft3).
Hinzu kommt, dass sich die traditionelle explizite Bedienung
von Oberflächen mittels Maus, Tastatur und Touchscreens zu
einer eher impliziten Bedienung durch Gesten, Sprache,
Augen- und Körperbewegung hin verändert. Dies geht einher
mit den momentan vielleicht noch futuristisch anmutenden
Trends der 3D-Technologie für eine möglichst realitätsnahe
Objektdarstellung. All dies lässt sich nur durch die Nutzung
der gerätespezifischen APIs erreichen. Die Nutzung etwa von
ASP.NET oder von JSP ist bei einer Apple Watch oder bei
Wearables aktuell nicht vorstellbar.
Sie möchten neue Möglichkeiten der Mensch-MaschineInteraktion nutzen.
Es geht ihnen um die Umstellung auf bedarfsgerechte
User-zentrische Omni-Channel-Oberflächen.
Sie sehen die Notwendigkeit, neue Chancen durch Digitalisierung zu nutzen.
Geschäftspartner sollen auf der eigenen Plattform eingebunden werden.
Die Leistungsfähigkeit der Rechnerwelten wie auch die
Rechenleistung der Endgeräte befeuert diese Entwicklung
zusätzlich. Interaktive 3D-Brillen werden bei steigender
Leistungsfähigkeit immer kleiner. Somit werden wir in den
nächsten fünf bis sieben Jahren eine grundlegende
Veränderung der Mensch-Maschine-Interaktion erleben.
Für uns ergeben sich daraus diese grundlegenden, fast
schon rhetorisch anmutenden, Fragen:
Damit bestehende Systeme diese neuen Möglichkeiten
nutzen können, bedarf es einer flexiblen Architektur. Nur so
ist es möglich, auch in Zukunft mit der rasanten Entwicklung
der Client-Technologien mitzuhalten.
■
■
■
■
■
■
■
■
■
Macht es weiterhin Sinn, ein sogenanntes integriertes
Gesamtsystem, durch einen neuen Monolithen mit moderner Technologie zu ersetzen?
Liegt in der Denkweise des „Big is beautiful“ das Kernproblem der aktuellen Misere der Applikationsarchitektur?
Ist eine alleinige Konzentration auf Standardsoftware und
deren Customizing alleine nicht bereits ein Hemmschuh
der Differenzierung und Digitalisierung?
Sollte man die Frontends mit der sich verändernden User
Experience von den Backend-Systemen entkoppeln?
Was können wir aus erfolgreichen Plattformansätzen
lernen? (z. B. Apple‘s App-Store-Ansatz)
Wie können wir die Vorteile von Diversität und Differenzierung bei den Systemen nutzen, anstatt diese zu
bekämpfen?
© OPITZ CONSULTING GMBH 2016
Untersuchungen zum Applikationslebenszyklus der unterschiedlichen logischen Schichten der Software bestätigen
dies. Generell hält das relationale Datenmodell etwa 10-12
Jahre, die Geschäftslogik bleibt trotz Weiterentwicklung ca. 57 Jahre stabil, aber die Möglichkeiten der Benutzeroberflächen ändern sich alle 2-3 Jahre grundlegend.
Aus unserer Sicht kann eine flexible Nutzung unterschiedlicher und neuartiger Mensch-Maschine-Interaktion nur
erreicht werden über eine striktere Trennung der Funktionalität und Steuerung der computergestützten Benutzerschnittstelle von der grundlegenden Geschäftslogik der Backends.
SEITE 3
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Die Lösung liegt in einer weitergehenden Entkopplung der Dabei handelt es sich um interne Systeme, z. T. durch die
Softwareschichten von Frontend und Backend.
Aufteilung der Backendsysteme in Microservices hervorgerufen, aber auch zunehmend Online-Schnittstellen externer
These 1: Zukünftige Oberflächen verändern sich unabhängig Anbieter oder Cloud-Systeme. Clients können durchaus auch
und schneller als die Geschäftslogik im Backend.
Services von unterschiedlichen Backend-Systemen, ggf. sogar
von externen Unternehmen (z. B. Partner- oder Dienstleistungsunternehmen), nutzen. Ein Treiber dieser Entwicklung
BEDARFSGERECHTE USER-ZENTRISCHE OBERFLÄCHEN
sind die zunehmend eingesetzten Software-as-a-Service(SaaS)-Lösungen, die Implementation eigener CloudParallel zu den neuen Trends in der Computernutzung lassen Lösungen wie auch die Anbindung von Dingen beim Internet
sich beim Aufbau von IT-Systemen grundsätzliche Entwick- der Dinge (IoT) und in Digitalisierungsprojekten.
lungen zur Komplexitätsreduktion bei Client- und BackendSystemen erkennen.
Aus unserer Sicht führen diese Überlegungen zur
Implementation von kleinen, bedarfsgerechten und an einer
Frontend-Systeme
spezifischen Aufgabe ausgerichteten Applikationen. Diese
Unternehmen wie auch Anbieter von Standardsoftware Vielzahl an kleinen Apps werden über ein Enterprise-Apps
verändern den Oberflächenentwurf, von großen, mono- Store-Konzept, ähnlich einem Mobile Device Management,
lithischen Clients mit komplexen, beinahe allmächtigen Ober- verwaltet und können auch hierüber ihren Kontext
flächen, die alle Anwendungsfälle abdecken, hin zu kleineren, austauschen6).
spezialisierten Clients für einzelne Anwendungsfälle oder
Benutzergruppen. Dies lässt sich recht gut mit den Apps aus These 2: Zukünftige Oberflächen passen sich in schnellen
der mobilen Welt vergleichen. Eng umrissene Aufgabenfelder Zyklen dem Bedarf und den Erfahrungen der Nutzer an.
werden mit bedarfsgerechten und intuitiven Oberflächen
versehen.
NEUE CHANCE DURCH DIGITALISIERUNG NUTZEN
Im Clientumfeld ermutigen zusätzlich die verschiedenen Endgeräte mit ihren stark unterschiedlichen Leistungen und Seit einiger Zeit lassen sich zwei nicht ganz trennscharfe
Funktionalitäten ein solches Umdenken. Smart Watches und Trends hinsichtlich der Nutzung von Computern beobachten,
Hololenses4) können nur sehr wenige bzw. stark aggregierte die auch im Unternehmenskontext immer mehr an
Informationen anzeigen. Mobiltelefone und Tablets sind für Bedeutung gewinnen:
die Eingabe von langen Texten nicht geeignet, ermöglichen
stattdessen die Aufnahme von Sprachnachrichten oder Fo- Ubiquitous Computing beschreibt den Trend zu einer
tos. Generell eignen sich alle mobilen Endgeräte mit ihren Arbeitswelt, bei der alles zu einem Computer wird und die
kleinen Displays nur für überschaubare UIs mit verhältnis- Arbeit unterstützt. Smartphones und Tablets aber auch
mäßig wenigen Masken.
Devices wie Armbänder oder 3D-Brillen sollen jederzeit bei
der Arbeit Verwendung finden und situativ unterstützen.
Backend-Systeme
Feste Arbeitsstationen gehören der Vergangenheit an und
Diese Komplexitätsreduktion ist nicht ausschließlich ein Rechenleistung ist überall zu Diensten. Zu diesem Trend
Trend bei den Clientsystemen, sondern auch bei den gehören auch die Omni-Channel-Ansätze7) bei der Interaktion
Backend-Systemen. Der Monolith im Backend, der die mit Geschäftspartnern oder Endkunden.
erwähnte strukturelle Zukunftsunfähigkeit durch die hohe
Komplexität und die daraus resultierende geringe Flexibilität Pervasive Computing bedeutet, dass die Welt vernetzter
verursacht, wird zunehmend als Architekturentwurf in Frage wird. Sensoren, Gegenstände und menschliche Akteure agiegestellt.
Der
aktuelle
Microservice-Architekturansatz5) ren in einem gemeinsamen Netzwerk. Bekanntester Treiber
unterteilt komplette Systeme (Frontend und Backend) in dieser Entwicklung ist die deutsche „Industrie 4.0“-Initiative.
kleinere, anhand der Geschäftslogik abgegrenzte Services.
Beim pervasive Computing beginnen computerbasierende
Systeme, mithilfe von Sensorik die Umwelt wahrzunehmen
Ziel ist es dabei, Weiter- und ggf. auch Neuentwicklung und diese Informationen mit dem Anwender zu teilen. Dabei
voneinander zu entkoppeln, Abhängigkeiten zu reduzieren kommen soziale Informationen aus pseudo-sozialen Netzund so das Gesamtsystem flexibler zu halten. Ferner wird die werken wie einer Fabrikhalle in den Austausch. Zum Netzklassische Kommunikation eines Clients mit genau einem werk „Fabrikhalle“ gehören Arbeiter genauso wie Maschinen.
Server-Backend heute immer öfter durch die Kommunikation Zusammen ergibt sich ein virtuelles Gesamtbild beim Bemit mehreren unabhängigen Services ersetzt.
trachter, etwa mit Ansätzen der Augmented Reality.
© OPITZ CONSULTING GMBH 2016
SEITE 4
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Beide Trends befeuern sich gegenseitig. Denn: Je eher ich die
Dinge vernetzte, desto eher kann ich überall elektronische
Hilfsmittel nutzen. Und je eher ich überall arbeiten möchte,
desto eher sind wir bestrebt, die verwendeten Geräte zu
vernetzen.
Der Trend des Cloud Computings mit den SaaS-Lösungen
verschärft noch einmal den Aspekt des Time-to-Market und
erfordert hybride Infrastrukturarchitekturen10) für die Applikationslandschaft. Dafür braucht es eine modulare Architektur des Backends und der Frontend-Komponenten. Die
Releasezyklen der einzelnen Komponenten dürfen nicht die
Aus unserer Sicht führt diese Entwicklung zu kontext- Plattform als Ganzes kompromittieren.
sensitiven Applikationen, die neben einem gesicherten
Kontext im Rahmen einer Omni-Channel-Strategie auch den These 4: Die eigene Applikationslandschaft wird zukünftig
Kontext der Umgebung auswerten und verstehen. Somit wird zu einer Plattform für ein „Ecosystem of value“.
die Applikation selbst zu einem Baustein im umfassenden
Netzwerk des Internet of Everything und kann auf die Umwelt
reagieren. Eine weitere Nutzung liegt im Machine Learing8).
Gerade durch die enorme Steigerung der Leistungsfähigkeit
heutiger Rechner, der Skalierung durch Cloud Computing
und die sinkenden Kosten für CPU und Speicher lassen sich Wir präsentieren in der Folge den Blueprint einer zukunftsnun bereits bestehende Ansätze des Machine Learnings weisenden Referenzarchitektur, die die geschilderten Treiber
adressiert und die nötigen Qualitätsmerkmale besitzt. Diese
realisieren.
Referenzarchitektur bezeichnen wir als Context-Aware
These 3: Zukünftige Oberflächen fördern die Vernetzung bei der Front End Architecture (CAFA) und wird in der Abbildung 1
Mensch-Maschine-Interaktion.
dargestellt. CAFA erweitert die drei bislang etablierten
Deployment-Schichten der Architektur, um die sogenannte
Delivery-Schicht.
Blueprint Context-Aware
Frontend Architecture
Geschäftspartner auf eigener
Plattform einbinden
Durch die Digitalisierung verändern sich traditionelle Wertschöpfungsketten. Immer größere Chancen ergeben sich aus
der Einbindung von Geschäftspartnern; sei es, um Geschäftsprozesse zu optimieren oder um die eigene Fertigungstiefe
an die Marktgegebenheiten anzupassen. Hierfür muss die
IT-Plattform des Unternehmens die Geschäftspartner in
beide Richtungen einbinden:
Hierdurch entsteht seitens der Deployment-Architektur eine
Vier-Schichten-Architektur mit einer eigenen ausgestaltbaren
physikalischen Schicht für die mobile und digitale Welt. Dieses Konzept der Vier-Schichten-Architektur11) wurde 2015 von
Forrester12) in Analystenberichten aufgegriffen. Wir haben
dieses Konzept zu einem Blueprint der Context-AwareFrontend-Applikationsarchitektur
weiterentwickelt
und
nutzen es bei der Beratung unserer Kunden als Basis für die
Konzeption einer Zielarchitektur für zukunftsweisende
Applikationslandschaften.
Zum einen geht es dabei um die Einbeziehung und Integration von Diensten Dritter. Zum anderen kann das Unternehmen selbst als Lieferant auftreten und „Dritten“ als Geschäftspartnern über Schnittstellen den Zugang zu den Business Capabilities des Unternehmens anbieten. Die Analysten
von Forrester sprechen von einem „Ecosystem of value“9),
das sich permanent an die Kunden- und Marktgegebenheiten
anpasst, Kostensenkungspotenziale ermöglicht und durch
neuartige, überraschende Dienste von Dritten auch die
Kundenbindung erhöht. Diese Ansätze sollen einfach, schnell
und transparent implementierbar sein.
Aus unserer Sicht muss die Applikationslandschaft die Abbildung 1: Flexibilität und Unterstützung einer Omni-Channel
Fähigkeit besitzen, in kürzester Zeit und unkompliziert neue Strategie durch CAFA
Anforderungen der sich verändernden Geschäftsmodelle zu
erfüllen. Voraussetzung hierzu ist die Möglichkeit, Geschäftspartnern (Dritten) die eigenen Business Capabilities über
gesicherte Schnittstellen anzubieten oder selbst Dienste
Dritter in den eigenen Prozessen zu konsumieren.
© OPITZ CONSULTING GMBH 2016
SEITE 5
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
DELIVERY-TIER: WARUM EINE EIGENE PHYSIKALISCHE
SCHICHT EINZIEHEN?
Mit steigender Anzahl und Möglichkeiten unterschiedlicher
Devices, der rasanten Entwicklung von HTML5 bzw. den
Entwicklungsumgebungen für die Devices sind die InnovaDie
Schwachstelle
beim
Deployment
etablierter tionszyklen15) deutlich höher als bei der Veränderung von
logischer Drei-Schichten-Architekturen liegt in der mangel- Business Services für die Backend-Prozesse.
haften und zu schwerfälligen Unterstützung der unterschiedlichen mobilen Devices und deren eingebauter Sensorik Ein weiteres Argument für die Einführung einer zusätzlichen
sowie einer fehlenden Erweiterung auf die Anforderungen Schicht liegt in der Ermöglichung eines API-Managements16)
für die Skalierung und die Security der mobilen Lösungen.
des Internet der Dinge (IoT).
Gerade in der mobilen Welt ist die Bandbreite noch immer
Die etablierte Drei-Schichten-Architektur stellt eine Plattform ein Hemmschuh und die schwergewichtigen SOA-Protokolle
für Business Services zur Verfügung und abstrahiert somit können hier zu Engpässen führen. Aktuell nutzen mobile Lödie Backend-Dienste von einer spezifischen Oberfläche. sungen oft RESTfull-JSON-Dienste (REST), die auf http(S) ProGrundsätzlich eine richtige Denkweise, sollte man meinen: tokollen basieren. Blickt man in die Zukunft des Internet der
Diese Services sind in der Regel als Webservices auf einer Dinge werden sich noch leichtgewichtigere Protokolle, etwa
SOA-artigen Infrastruktur implementiert und nutzen einen CoAP17) or MQTT18) durchsetzen. Ferner besteht nun die
Enterprise Service Bus, der auf einer eigenen Service Tier Chance, einen Teil der Delivery Tier in einer DMZ auszulagern
und somit die eigenen Backend-Prozesse externen Dritten
implementiert ist.
zur Verfügung zu stellen. Hierdurch wird die eigene IT-Welt
Betrachtet man die Anforderungen allerdings aus der Sicht zu einer Applikationsplattform für Geschäftspartner. Dieses
der Frontends und bezieht die User Experience als entschei- Konzept werden wir in den Fallstudien genauer beschreiben.
denden Faktor mit ein, so zeigt sich, dass diese Denkweise in
die falsche Richtung führt: Die unterschiedlichen Clients Die Entkopplung der Frontends von den Backend-Services
benötigen Daten mit unterschiedlichen Aggregationsstufen, ermöglicht ferner eine „Applikationsstrategie der zwei
verbinden Daten aus unterschiedlichen, auch externen, Geschwindigkeiten“. Die sich permanent verändernden,
Services zu neuen Informationsobjekten, nutzen Public API Outside-in-getriebenen Oberflächen einerseits und die beoder Device-spezifische Möglichkeiten, die den bestehenden darfsgerechten Oberflächen, die auf sicheren und robusten
Business Services nicht bekannt sind. Bleibt man nun dem Business Services beruhen, andererseits. Dieser organisaKonzept der Drei-Schichten-Architektur treu, so müssen die torische Aspekt wird am Ende noch eingehender betrachtet.
Business Services zeitnah auf die spezifischen Belange der
Devices angepasst werden, oder bestehende Services wer- FRONTEND TIER: WELCHE ARTEN VON OBERFLÄCHEN
den über neue zusammengesetzte Composite Services13) BZW. UIS GIBT ES?
zusammengefasst. Wenn sich die Business Services in Richtung von Client-spezifischen Schnittstellen entwickeln, wird Momentan können wir fünf grundlegende Frontenddies das Paradigma der SOA aushebeln. In der Folge be- Kategorien identifizieren, die auch in Abbildung 2 dargestellt
stimmt und bremst die Bereitstellung der SOA-Dienste die sind. Diese Klassen an Frontends sind im CAFAInnovation bei den Oberflächen.
Architekturmodell abbildbar und werden im Folgenden etwas
näher erläutert.
Aktuell wird diese Herausforderung auf der Frontend-Seite
zu häufig umgangen, indem die fehlende Logik einfach in die
Frontends implementiert wird. Dies führt zu komplexen und
auch aufwendigen Lösungen für einfache Frontends und oft
zu Widersprüchen durch die redundante Implementierung
der Geschäftslogik.
Aus architektonischer Sicht benötigen wir deshalb eine
eigene physikalische Schicht – die Delivery Tier14). Oberflächen und Funktionalitäten können durch die Entwicklung auf
das gewünschte Device optimal aufeinander abgestimmt
werden, ohne die unterlagerten stabilen Business Services Abbildung 2: Klassifikation von User-Interfaces
permanent zu verändern.
© OPITZ CONSULTING GMBH 2016
SEITE 6
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Klasse „Complex Apps“
Zu dieser Klasse gehören Systeme mit funktionsreichen und
komplexen Oberflächen, die oft als „Expertensysteme“ kategorisiert werden. Dies sind die klassischen schwergewichtigen
Oberflächen, die bekannten Rich-GUI-Oberflächen von
Desktop-Anwendungen – jedoch zukünftig mit einem
verstärkten Augenmerk auf grafische Darstellungen von
Sachverhalten, und weniger „Tabellenwüsten“.
Insbesondere die Nutzung der Sensoren eines Smartphones,
etwa der Kamera mit Bilderkennung, GPS oder Spracherfassung bis hin zu einer NFC- oder Blue-Tooth–Kopplung
an Maschinen und Geräte, bieten neue Möglichkeiten, diese
Geräte in den Arbeitsalltag und in Geschäftsprozesse einzubinden. Die notwendige Datenpflege zur Verwaltung der
Tätigkeiten wird unabhängiger von den Arbeitsstationen und
verlagert sich an den Ort der manuellen Tätigkeit.
Zu dieser Klasse gehören auch Planungssysteme mit
Features zur (grafischen) Simulation sowie UIs für die Pflege
komplexere Datenstrukturen und Oberflächen, die den
Anwender, etwa über modale Dialoge, bei der Bearbeitung
von prozessorientierten Tasks unterstützen.
Klasse „Analytical Apps“
Die Klasse der analytischen Systeme umfasst die Oberflächen, die Drill-Down, Data Mining oder Ad-hoc Reporting unterstützen. Diese Systeme sind seitens der Datenstrukturen
und der -zugriffe meist generisch. Hier bietet der Markt
etablierte, leistungsstarke Standardlösungen an. Da große
Datenmengen verarbeitet werden und die Zugriffspfade,
etwa SQL-Befehle, über Parameter aus der Aufgabenstellung
heraus generiert werden, bietet es sich an, erprobte BI-/
Big-Data-Architekturen und deren Systeme zu verwenden.
Die Komplexität der Darstellung, die Vielfalt an Funktionalität
und die Menge an Informationen, die der Anwender zur
Bearbeitung dieser Tasks benötigt, erfordern einen größeren
Bildschirm. Die Rechenleistung der dezentralen Einheit ist
dabei nicht unbedingt entscheidend, sondern eher die
Notwendigkeit, viele Informationen aus unterschiedlichen
Gesichtspunkten grafisch übersichtlich und aufgabengerecht
darzustellen. Ein gutes Beispiel dafür sind Anwendungen für
Callcenter mit einem 360-Grad-Blick auf den Anrufer.
Klasse „Realtime Apps“
Eine weitere Klasse sind die Near Real-time-Systeme, die ein
technisches oder auch fachliches Monitoring wie etwa die
Darstellung des aktuellen Status über Leitstände
ermöglichen. Hierzu gehört auch die Möglichkeit Simulationsergebnisse grafisch mit den aktuellen Daten der Produktionslandschaft zu verbinden, um geplante Änderungen zu sehen.
Die Darstellung dieser Leitstände oder Monitoring-Systeme
sind komplex, sie verändert sich im Sekundentakt. Mehr und
mehr wird die physikalische Welt in den Oberflächen
„augmented“19) bzw. Veränderungen werden simuliert.
Ansätze aus dem Bereich der Gamefication finden hier
Einzug. Sie vermitteln den Anwendern ein Abbild der Realität
und machen es gleichzeitig möglich, spielerisch mit der Oberfläche zu interagieren20).
Klasse „Mobile Apps“
Die Klasse der mobilen Lösungen stellt, obwohl diese schonseit Jahren intensiv privat genutzt werden, die eigentliche
Neuerung für Business Applikationen dar. Über mobile
Geräte, die im Sinne des „Bring your own Device“ (BYOD) auch
persönliche Tablets oder Smartphones sein können, bietet
die flexible Applikationslandschaft kleine aufgabenspezifische Lösungen an. Diese Lösungen haben einfachste,
selbsterklärende Oberflächen, die meist ohne eine explizite
manuelle Datenerfassung auskommen. Denn eine manuelle
Dateneingabe ist auf Smartphones nicht effizient möglich.
© OPITZ CONSULTING GMBH 2016
Diese Systeme benötigen meist eigene Datenstrukturen21),
um die Abfragen generieren und ausführen zu können.
Oder Sie nutzen im Big-Data-Bereich iterative MapReduceVerfahren22) , um Daten zu filtern und die Ergebnisse weiterzuverwenden.
Klasse „IoT-based Apps“
Mit dieses Klasse an Systemen haben wir uns etwas schwergetan. Gleichwohl möchten wir diese eigentlich noch nicht
klar definierbare Klasse der IoT-basierenden Applikationen
hier mit aufnehmen, da die Applikationsarchitektur gerade
aufgrund der Neuartigkeit dieser Klasse ein „Design for
Change“ benötigen wird.
Wie entwickelt man Anwendungen für Hololenses? Und mit
welcher technologischen Basis erfolgt die Entwicklung?
Nimmt man als Beispiel Google Glasses, so ist für die Entwicklung entscheidend, dass es APIs für die fachliche Logik
aus dem Backend gibt, die unabhängig von der OberflächenDarstellung sind. So ist es möglich, über die Hardwarespezifischen APIs der Google Glasses eben diese APIs zu
nutzen und mit Daten anderer Quellen anzureichern.
Geräte wie das Myo Armband23), das Armbewegungen erkennt und somit Befehle ohne grafische Oberflächeninteraktion ermöglicht, benötigen eine technische API, die die
App nutzen kann, um Bewegungen an Befehle zu koppeln.
Beide Geräteklassen können kombiniert hochmoderne Interaktionen ermöglichen, bedürfen jedoch eine iterative, eher
am Lean-Startup angelehnte Entwicklung, um noch unbekannte Technologien effektiv einzusetzen und somit schnell
Mehrwerte zu generieren.
SEITE 7
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
LEITLINIEN FÜR ARBEITSWEISE UND OBERFLÄCHE
Die Oberflächen werden neben den Services der Backends
auch Umwelt-Variablen der Maschinenwelt oder CloudAls Ergebnis lassen sich die folgenden Leitlinien bezüglich basierender Lösungen von dritten Parteien einbeziehen.
Arbeitsweise und Oberfläche formulieren:
In einem klassischen Ansatz würde man jetzt versuchen,
■ Klassische
sequentielle
Geschäftsprozesse
mit sämtliche Anwendungen als Dach-Lösung unter einem EnterEntscheidungsbäumen werden immer unwichtiger.
prise Portal zu implementieren. Das Portal übernimmt die
■ Die bedarfsgerechte Information zum richtigen Zeitpunkt Aufgaben einer zentralisierten Authentifizierung und
und „context-aware“ zum aktuellen Standort wird zu einem Autorisierung der registrierten Anwendungen. Jedoch sind
entscheidenden Faktor, um eine ganzheitliche Sicht zu uns aktuell keine Portallösungen bekannt, die eine große
ermöglichen und Entscheidungen zu treffen.
Anzahl disjunkten Applikationen mit unterschiedlichen Platt■ Rechtzeitige Information, zügige Entscheidungen und formen sinnvoll unterstützen würden. Gleichwohl benötigt
operatives Handeln treten in Vordergrund.
man eine ordnende Hand, gerade in einem potenziellen
■ Erfahrungsaustausch und Crowd Sourcing in Peergroup „Wildwuchs-Szenario“ wie dem Internet der Dinge. Abbildung
und Kollaboration sollen möglich sein.
3 beschreibt die Interaktion der Devices mit dem Enterprise
■ Der Arbeitsplatz ist zunehmend nicht mehr statisch work- App Store. Die Delivery Tier mit dem API Management überflowbasiert, sondern eher aufgaben- und eventorientiert.
nimmt somit die nichtfunktionalen Aufgaben des Enterprise■ „Everywhere“, also überall, muss das System als Arbeits- Portals in einer heterogenen Welt.
mittel einsetzbar sein.
■ Nutzung von verteilten, aber auch externen, Daten- Analog zu den App-Ansätzen bei Smartphones, sei es im Konbeständen soll möglich sein.
text von Apple oder von Android, schlagen wir die Implemen■ Oberflächen sollen einfach, klar und aufgabengerecht sein tierung einer CAFA vor. Jede Applikation, unabhängig von
und nicht umfänglichen „Expertensystemen“ entsprechen.
ihrer Implementation, registriert sich in einer zentralen Registry. Diese Registry ermöglicht die Authentifizierung, auch
FRONTEND TIER: WARUM EIN ANSATZ FÜR CONTEXTüber die individuellen Mechanismen der eingesetzten
AWARE ENTERPRISE APPS?
Devices wie Fingerabdruck oder Retina-Scan und führt Buch
über die erlaubten Funktionalitäten der Benutzergruppen
Ziel der neuen Oberflächen sollte die Etablierung einer Omni- und Benutzer (Autorisierung). Ferner kennt die Registry aus
Channel-fähigen Kommunikationsplattform24) mit einheitli- den physikalischen Parameter des Devices auch die erlaubchen IT-Services sein. Hierbei ist „alles“ ein Desktop-Rechner, ten Devices für eine Anwendung.
also auch BYOD, Machinen etc. Beim Oberflächendesign
sollte eine „Mobile First“-Strategie25) verfolgt werden, um orts- Jede App hat ferner erlaubte Input-Parameter, URL– und APIungebundenes Arbeiten mit unterschiedlichen Devices zu Strukturen und auch die REST-Strukturen für die fachliche
ermöglichen.
Logik. Diese Parameter werden im zentralen App Store über
ein Device Management verwaltet. Mit diesem Ansatz ist es
Ferner werden komplexe Prozesse nicht in der Software- dem virtuellen Portal möglich, pro Device einen Homeoberfläche selbst dargestellt, sondern es gibt vor allem Screen zu erstellen, der auf die individuellen Parameter des
bedarfsgerechte Oberflächen für anstehende Aufgaben. Benutzers eingeht.
Dabei ist zu berücksichtigen, dass ein „Information-Worker“
andere Oberflächen braucht. Gefragt sind hier nicht mehr die
klassischen Expertenoberflächen mit komplexen Personalisierungsstrategien, die diese in aufgabengerechte Monolithen
verwandeln26). Informationen und Oberflächen sollen einfach
austauschbar sein, um neue Ansätze bei der MenschMaschinen-Interaktion implementieren zu können. Das ist
nur möglich, wenn die Semantik der Geschäftsobjekte
bekannt ist und Geschäftslogik in den unterschiedlichsten
Kontexten wiederverwendbar ist. Hier hilft die Trennung von
Geschäftslogik und Oberflächen, sodass Oberflächen eher als
Bauteile im bzw. Aufbauten auf dem Backend zu sehen sind. Abbildung 3: Interaktion von Device und Enterprise App Store
Zukünftig werden alle Objekte eine „Intelligenz“ besitzen, und
die IT-Leistung wird zunehmend dezentralisiert.
© OPITZ CONSULTING GMBH 2016
SEITE 8
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Da die App-Landschaft, im Gegensatz zu den umfassenden
Expertensystemen auf dem Desktop, nun aus einer großen
Anzahl von aufgabenspezifischen, disjunkten, kleinen Lösungen besteht, muss es möglich sein, aus einer App heraus eine
andere App aufzurufen und hierbei den Kontext zu behalten.
Generell wird die App selbst die Transaktionsgrenze
ziehen. Andernfalls müssten im Fehlerfall extrem komplexe
Compensation-Handler für den Rollback erstellt werden, um
Transaktionen über App-Grenzen hinweg zurückzurollen.
Dies schränkt natürlich das Design ein: Transaktionen sind
nur auf der Ebene einer App möglich. Die Übergabe eines
Kontexts erfolgt in einer ähnlichen Technologie, die Android
selbst verwendet27). Jede App schreibt den Kontext beim
Verlassen schemafrei in eine Clipboard History. Die
aufgerufene App nutzt daraufhin diese History, um sich
selbst zu positionieren.
Fallstudie 1: Wachstumssicherung
mittels API Management
Diese Fallstudie beschreibt eine Applikationsmodernisierung,
die zum Ziel hatte, durch eine skalierbare Architektur den
geplanten Wachstum und den Ausbau des Geschäfts in neue
Marktsegmente zu sichern. Das Unternehmen ist ein
internationales Handelshaus mit weltweiten Partnern in
seinen Bonusprogrammen.
UNTERNEHMEN UND GESCHÄFTSTREIBER
Das Unternehmen agiert am Markt als einer der weltweit
führenden Anbieter von Bonusprogrammen. Über 500 Partnerunternehmen übermitteln ihre Verkäufe an das Unternehmen und die Verwaltung der Bonuspunkte erfolgt durch
Dieses App-Store-Konzept sichert, trotz der Vielfalt der Ober- eine zentrale IT-Plattform.
flächen-Technologien, eine einheitliche Sicht durch ein
virtuelles Portal. Dieses manifestiert sich als Home- Im Rahmen einer Wachstumsstrategie wollte man zum einen
Anwendung auf den unterschiedlichen Devices und beachtet durch intensivierten Vertrieb mehr Partnerunternehmen aus
die Parameter des Device Managements im App Store. Als den bestehenden Marktsegmenten für das Bonusprogramm
Folge werden etwa JavaFX-basierende Applikationen auf dem gewinnen. Zum anderen sollten durch neue Marktsegmente
Homescreen bei Tablets nicht angeboten und umgekehrt Umsatzsteigerungen erzielt werden.
werden auf dem Desktop keine Apps angeboten, deren
Anwendung auf den Sensoren der spezifischen Devices Die bestehende Lösung war den zukünftigen Anforderungen
beruhen. Neue Applikationen, die die Sensorik der Devices nicht gewachsen, weder im Hinblick auf die notwendige Pernutzen, passen ebenfalls in das Schema, solange eine formance des Volumens an zukünftig prognostizierte TransRegistrierung im App Store möglich ist. Dies schränkt die aktionen, noch für die interne Verbesserung des recht aufEinbindung zukünftiger Technologien aus unserer Sicht wendigen Onboardings für neue Partner und dem Service für
derzeit nicht ein.
bestehende Partner. Durch den Einsatz geeigneter IT-System
und Automatisierung, sollte versucht werden, die bestehende Mitarbeiteranzahl nur unwesentlich zu erhöhen.
Fallstudien – Überblick
Steckbrief des Unternehmens
Fallstudie
Branche
Unternehmen
Funktionalität
Treiber
FS1
Bonusprogram
me
Internationales
Handelshaus
ERP
Wachstum,
Time-toMarket
Streckengeschäft
Europäisches
Handelshaus
CX
Applications
Wachstum,
Digitalisierung
FS3
Diskrete
Fertigung
Automotive,
Konzern
MES
Industrie
4.0,
Prozesseffizienz
FS4
Callcenter
Handel
ERP
Kundenbindung,
Prozess-
FS2
© OPITZ CONSULTING GMBH 2016
Gründung
1990
Tätigkeitsfeld
Bonusprogramme
Branche
Handel
Firmenstruktur
Konzerntochter; GmbH
Umsatz
n.a.
Mitarbeiter
Ca. 300
SEITE 9
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Der Plan war, die bestehende Kommunikations- und
Integrationsplattform grundlegend zu überarbeiten, um den
Anforderungen der zukünftigen Geschäftsentwicklung
Effizienz
Früherkennung von Problemen bei Geschäftspartnern
begegnen zu können. Grundlegende Herausforderungen
lagen im Bereich der Sicherheitsanforderungen durch die
Compliance
Erweiterte Betrugsprävention und Revisionssicherheit
Zugriffe von externen Partnern sowie in der Flexibilität
zukünftiger neuer Partner, die schneller, kostengünstiger,
Flexibilität
Automatisierung des Onboardings neuer Partner
und der Serviceleistungen
aber auch transparent, in einem Self-Service-Ansatz auf die
Plattform ziehen sollen. Hieraus folgt sofort die
Effektivität
Schnellere Reaktionsfähigkeit auf Anforderungen
weitergehende Anforderung der Prozesssicherheit und
Skalierbarkeit für den Durchsatz sowie der Verfügbarkeit des
LÖSUNGSANSATZ
Systems
bei
einem
steigenden
OnlineTransaktionsaufkommen. Man erwartet eine Verdopplung
Der differenzierende Faktor bei Bonusprogrammen wird des Transaktionsaufkommens auf ca. 16 Mio. TX pro Tag.
mehr und mehr zum „ease-of-use“ für die beteiligten externen
Partner. Die eigentlichen Programme und die Angebote Seitens der IT-Architektur war die Herausforderung zum
beginnen sich anzugleichen und als Differenzierung treten einen, die QoS (Quality of Service) und die Stabilität zu
nun die geringeren Interaktionskosten in den Vordergrund.
sichern. Dabei sollte gleichzeitig die Möglichkeit bestehen,
Skaleneffekte zu nutzen, um manuelle Interaktion
Big-Data-Ansätze bzw. die Bon-Analyse spielten als Differen- weitestgehend zu vermeiden bzw. diese nur auf den
zierung eine geringe Rolle, da diese Analysen durch die umfassenden, aber leichtgewichtigen Onboarding-Prozess
Systeme des externen Partners oder durch dessen Cloud- eines neuen Partners zu beschränken.
Lösungen erfolgen.
Herausheben lassen sich die folgenden Eigenschaften, die
Die Leistungen des Bonusprogramms müssen transparent der neuen Plattform ein Alleinstellungsmerkmal verschaffen
durch die externen Partner in ihre IT-Welt implementierbar sollten:
sein und gleichzeitig den vollen Funktionsumfang besitzen.
Diese Entwicklung ließ sich auch im vorliegenden Fall ■ Zuverlässigkeit und Prozesssicherheit in der Skalierung bei
wachsendem Geschäftsmodell
aufzeigen. Die Batch-Welt mit den SFTP-Ansätzen des Datenaustausches nimmt kontinuierlich ab und die Online- ■ Höchstmögliche Automatisierung zur Reduktion der
manuellen Interaktion
Verarbeitung mit REST-API wächst kontinuierlich.
■ Schnelle, transparente Prozesse für das Onboarding neuer
Partner
Die Herausforderung für den Lösungsansatz war nun die
Umstellung einer eher auf Batch-Verarbeitung aus- ■ Erweiterte Betrugsprävention und Revisionssicherheit
gerichteten Systemarchitektur auf den zukünftigen Schwerpunkt desReal-time-Zugriffs der externen Partner auf die Der Lösungsansatz war, eine Delivery-Schicht in der DMZ,
Geschäfts-logik des Anbieters des Bonusprogramms. aufzubauen, welche die, oft individualisierten REST-Aufrufe
der Partner auf ein einheitliches kanonisches Datenmodell
Abbildung 4 beschreibt die gewählte Zielarchitektur.
transformiert, die Private-Key-Verschlüsselung unterstützt
und eine erste, sehr schnelle, Betrugsprävention durchführt
(siehe Abbildung 4).
Geschäftstreiber
LESSONS LEARNED
Abbildung 4:
API-Plattform
Zielarchitektur
für
© OPITZ CONSULTING GMBH 2016
eine
extern
BPEL versus Eventmanagement: Die Anforderungen an
Revisionssicherheit, Restart und Recovery und der Wunsch
nach einem Monitoring bzw. einer Near Real-timeStatusverfolgung legten den Einsatz von BPEL oder einer allgemeinen Process Engine nahe. Performancetests zeigten
jedoch sehr schnell, dass der Overhead einer Process Engine
zugunsten einer Event-getriebenen Lösung verändert werden
nutzbare musste.
SEITE 10
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Stabiles Backend: In diesem Fall war das Vorliegen eines
stabilen Backends hilfreich. Der maximale Funktionsumgang
war durch die Business Services (und deren Operations)
eindeutig definiert. Eine Empfehlung unserseits wäre, so
möglich, zuerst eine Stabilisierung des Backends
durchzuführen.
Fallstudie 2: Höhere Kundenbindung
durch Digitalisierung
Diese Fallstudie bezieht sich auf die Konzeption einer
zukunftsweisenden Applikationslandschaft für eine stärkere
Einbindung von Geschäftspartnern (Ecosystems of value) und
um Möglichkeiten der Digitalisierung zu nutzen.
UNTERNEHMEN UND GESCHÄFTSTREIBER
Das Unternehmen ist einer der führenden Dienstleister zur
Sicherung der Logistik durch ein Streckengeschäft und
erweiterte Dienstleistungen.
Steckbrief des Unternehmens
Gründung
1930
Tätigkeitsfeld
Streckengeschäft
Branche
Dienstleister
Firmenstruktur
Konzern
Umsatz
> 5 Milliarden EURO
Mitarbeiter
500-1.000
Geschäftstreiber
Effizienz
Automatisierung von
Fähigkeit, Tine2Market
Prozesse,
Omni-Channel
Compliance
Prozesstransparenz für Kunden
Flexibilität
„Design for Change“ und IoT (Telemetrie)
Effektivität
Ecosystems of value, Cloud Computing
Die aktuelle Systemwelt, die größtenteils auf veralteten und
extrem veränderten Version von SAP beruhte, erfüllte nicht
mehr die Bedürfnisse des zukünftigen Geschäfts. Dieses
wandelt sich derzeit erheblich, neue Wettbewerber drängen
auf den Markt und die Kunden verlangen nach erweiterten
Angeboten. Die Applikationslandschaft stand daher auf dem
Prüfstand. In einer Studie erhob man die bestehenden und
neu geforderten Business Capabilities und bewertete sie
bezüglich der IT-Unterstützung.
Dies war letztlich der wesentliche Treiber und Ausgangspunkt für eine Applikationsmodernisierung und die Entwicklung einer Strategie für die zukünftige Applikationslandschaft. Die Aufgabe lag in der Transformation der BatchSchnittstellen auf Webservices mit einer SOA-Schicht im
Enterprise Service Bus.
Weiterhin erfordern viele der neuen Business Capabilities
den Einsatz von digitalen Daten der Kunden, um Angebote
Near Real-time anbieten zu können. Die so erstrebte steigende Kundenzufriedenheit sollte das grundlegende Geschäftsmodell des Streckengeschäfts absichern und die Dienste des
Unternehmens als Single Source Provider ausbauen. Hierzu
gehörte auch der Ausbau der eigene IT-Plattform für ein
„Ecosystems of value“, über das Dritte Dienstleistungen für
den Markt anbieten und so das Service-Angebot erweitern
können.
Um die gewünschten Ziele zu erreichen, mussten im Frontend sowohl mobile Endgeräte unterstützt als auch eine IoTLandschaft zur Datengewinnung in die Applikationsarchitektur eingebracht werden. Dies entsprach im Wesentlichen der
Enterprise-App-Welt in der Frontend Tier.
Viele der gewünschten Funktionalitäten für eine Erweiterung
des Geschäftsmodells basierten auf der bestehenden
Geschäftslogik der Alt-Systeme, jedoch mit einer entspreHieraus ergab sich die Leitlinie „Design for Change“, und die chenden Erweiterung um GPS-und Sensor-Daten der
Flexibilität der neuen Architektur zeigte sich als wesentlicher Fahrzeuge. Abbildung 5 beschreibt den Lösungsansatz für
Treiber einer neuen Ausgestaltung.
ein Ecosystem of value.
Ein weiterer Aspekt war, dass die Nutzung an externen SaaSLösungen zunahm. Hierdurch verschob sich die Integration
von
On-Premise
in
die
Cloud,
sodass
eine
eigene externe Service Tier für die Cloud based Integration28)
physikalisch geplant wurde. Da das Unternehmen zukünftig
selbst SaaS-Lösungen anbieten wollte bzw. ganz neue GeLÖSUNGSANSATZ
schäftsmodelle durch die Freischaltung eigener AbwicklungsDie bestehende Applikationslandschaft ist auf Batch prozesse für Dritte (meist Startups) verfolgen möchte, wurde
Processing ausgelegt. Die Analyse der Business Capabilities ein Teil der Delivery Tier als PaaS-Lösung in einer externen
mit den Fachbereichen zeigte jedoch die Notwendigkeit einer Private Cloud implementiert.
Near Real-Interaktion mit den Kunden auf.
Abbildung 5: Referenzarchitektur für ein „Ecosystem of value“
© OPITZ CONSULTING GMBH 2016
SEITE 11
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
UNTERNEHMEN UND GESCHÄFTSTREIBER
Der Konzern ist einer der führenden Produzenten von Fahrzeugen. Das Vorhaben zum Re-engineering und zur Harmonisierung auf dem Shop Floor wurde von der Produktionsleitung einer Sparte getrieben und von den weltweiten
Werken unterstützt.
Abbildung 5: Referenzarchitektur für ein „Ecosystem of value“
Zu Projektbeginn wurden im Unternehmen sehr viele Daten
erhoben, aber nicht verwendet. Um mit diesen Daten die
neuen Geschäftsmodelle zu unterstützen bzw. über explorative Ansätze des Data Mining neues Wissen zu generieren,
wurde eine BI-Welt geplant. Das bestehende DWH-CoreSystem sollte um Fast Data29) und unstrukturierte Daten erweitert werden. Diese werden in einem Data Lake abgelegt
und dann über Analytics-Ansätze in einem Batch-Mode analysiert, um belastbare Modelle zu entwickeln, die anschließend
aus dem Data Stream der IoT-Cloud30) ablaufen und Near
Real-time Informationen an den Kunden bringen.
LESSONS LEARNED
Batch2Realtime: Der Teufel steckt im Detail! Die Konzeption
und die Umstellung der Batch-Interfaces war aufwendiger als
geplant. Im Laufe des Vorhabens haben wir somit nur die
absolut notwendigen Interfaces „re-engineered“, damit die
neuen Frontends entwickelt werden konnten.
Business Capabilities: Im Vorfeld über Business Capablities
die notwendigen Anforderungen an die IT-Unterstützung zu
erheben, ist empfehlenswert. Die Fachbereiche werden
damit gezwungen, sich über ihre Geschäftsmodelle und ihr
Angebot Gedanken zu machen und auch die zukünftigen
Entwicklungen ihres Portfolios zu betrachten. Die IT hatte
damit ein gutes Fundament, um seine Strategie aufzusetzen.
Fallstudie 3: Industrie 4.0 auf dem
Shop Floor
Diese Fallstudie bezieht sich auf das Re-Engineering und die
Harmonisierung der bestehenden, unterschiedlichen Manufacturing Execution Systeme (MES) für den Shop Floor bei der
Produktion bzw. Montage im Automotive-Umfeld. Die
zukünftige Lösung sollte eine stabile Basis für die nächsten
12-15 Jahren bilden, aber Innovationen aus dem
Industrie-4.0-Umfeld ermöglichen.
© OPITZ CONSULTING GMBH 2016
Die aktuellen MES-Lösungen bestehen aus unterschiedlichen
individuellen Applikationen, die umfangreich auf die Spezifika
der unterschiedlichen Werke des Unternehmens eingehen.
Im Zuge einer umfassenden Plattform-Strategie, sollen die
individuellen Arbeitsweisen angepasst und die Unterschiede
minimiert werden.
Gleichzeitig veränderte sich die Arbeitswelt durch Industrie4.0-Ansätze bereits jetzt. Maschinen, Roboter wie auch das
Endprodukt selbst besaßen bereits intelligente, selbststeuernde Einheiten. Viele der Produktionsprozesse waren weitestgehend automatisiert. Der Werker selbst trat zunehmend
nur noch als „Eskalationsmanager“ bei Störungen auf. Sein
Arbeitsplatz war bereits mobiler und verlagerte sich mehr
und mehr auf den Shop Floor. Der Vorteil: Neben der
Ersparnis von Laufzeiten in den riesigen Hallen, erfolgt die
Problemlösung vor Ort und auch zunehmend kollaborativ,
teilweise sogar online werksübergreifend mit anderen
Technikern.
Die Möglichkeiten der Frontend-Technologien erweitern sich
alle 2-3 Jahre und schaffen somit neue Möglichkeiten in der
Produktion. Die Innovationen im Bereich der mobilen Endgeräte mit neuen Formen der Informationsdarstellung und der
Roboter in der Produktion sind rasant und somit ergeben
sich permanent neue Nutzungsmöglichkeiten. Insbesondere
werden sich Oberflächen beziehungsweise Anforderungen
an die Unterstützung durch ein Frontend in rascheren Zyklen
als die zugrunde liegende Geschäftslogik verändern. Diese
Chancen der verbesserten Arbeitsweisen sollten daher
schnell und unabhängig von den Release-Zyklen des eigentlichen Backends verfolgt werden können.
Steckbrief des Unternehmens
Gründung
Vor 1900
Tätigkeitsfeld
Produktion
Branche
Automotive
Firmenstruktur
Konzernsparte
Umsatz
> 5 Milliarden EURO
Mitarbeiter
> 10.000
SEITE 12
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Geschäftstreiber
Effizienz Reduktion Prozesskosten, Eskalationsmgmt. verbessern Schwarmintelligenz auf Shop-Floor, Mobiles
Arbeiten ermöglichen
Compliance –
Flexibilität Innovationsgeschwindigkeit erhöhen
Effektivität Chancen des Industrie 4.0 ergreifen, werksübergreifende Harmonisierung, Muster von Schwachstellen
erkennen
LÖSUNGSANSATZ
Abbildung 6: Applikationsarchitektur für ein
Industrie-4.0-fähiges MES
Die Frontend-Komponenten sollten durch eine spezifische
Frontend-Serviceschicht von der Geschäftslogik der MESBackend-Komponenten entkoppelt werden, um den unterschiedlichen Entwicklungsgeschwindigkeiten und Anforderungen gerecht zu werden.
Eine Ausnahme bilden teilweise Leitstände mit einer Realtime-Anzeige von Daten und spezifischen Bildschirmen
(Boards, große Monitore, Ansätze zur Simulation der
Produktion) sowie die Analysesysteme mit dynamischen,
aber nur lesenden Datenzugriffen auf den zentralen DatenDas neue MES verfolgt in seiner Architektur eine Plattform- bestand des MES-Backends.
strategie durch die Entkopplung der Benutzeroberflächen
vom MES Backend über eine API-Schicht, die auf REST- Aufgabenorientierte Apps statt unflexibler Monolithen
Services basiert. Die grundlegende Geschäftslogik des MES Die Frontend-Komponenten betrachteten wir als Apps und
wird über Business Services mit der nötigen fachlichen Ge- sahen beim Design kleine aufgabenbezogene und bedarfsschäftslogik und den unterschiedlichen aufgabenbezogenen gerechte Applikationen vor. Diese werden, ähnlich den
Oberflächenkomponenten angeboten und ermöglicht die bekannten Smartphone Apps, über einen werksübergreifenWiederverwendung und gesicherte Nutzung von Diensten. den App Store verwaltet und in einem leichtgewichtigen
Abbildung 6 zeigt die Architektur des Lösungsansatzes.
virtuellen Portal, je nach Rechten und Geräteart, angezeigt.
Vorbild waren die Anwendungslandschaften der App-Stores.
Lose Kopplung von Frontend und Backend via
Explizit war hier keine Portal-Lösung im klassischen Sinne
REST-Schnittstellen
angedacht, da dann eine Einschränkung bei der Darstellung
Das neue MES kommuniziert mit den Frontend- erfolgt und das Portal selbst zum Engpass bei der Funktio
Komponenten in der Regel über eine REST-Protokoll- nalität geworden wäre.
basierende API-Schicht. Hierbei erfolgen CRUD-Operationen
(Create, Read, Update und Delete) ausschließlich über die Events im Mittelpunkt mit Tasklisten und Anwendungsimplementierte Geschäftslogik des MES, die durch die APIs kontext
veröffentlicht wird. Das heißt, es erfolgt eine lose Kopplung Grundlegend verändert hat sich die Philosophie der Steueder Frontend-Komponenten von der eigentlichen Verarbei- rung durch den „Werker“. War diese in der Vergangenheit
tungslogik. Das war eine Designanforderung, um die unter- geprägt durch starre Prozesse, so verändert sich die Arbeitsschiedlichen Geschwindigkeiten der Veränderung zu syn- weise nun in Richtung eines eventorientierten Ansatzes mit
chronisieren. Ein weiterer Vorteil war, das automatisierte einer Taskliste für Eskalationen und Meldungen und weg von
Tests über die APIs nun für eine nahezu hundertprozentige einem Workflow-Ansatz mit vordefinierten Aktivitäten.
Abdeckung sorgen.
Aus einem Eintrag der Taskliste öffnet das System durch InDie eigentliche Steuerung und Anzeige der Informationen terpretation des Kontextes automatisch die entsprechende
erfolgt jetzt durch die Frontend-Komponenten im Sinne einer App, um die Aufgaben zu lösen. Das Konzept ähnelt der
bedarfsgerechten und transparenten Informationsbereit- Dateipräferenz von Betriebssystemen. Die App kennt die
stellung. Dies eröffnet die Möglichkeit, auch auf Daten aus Meldungstypen und die Apps, die diese verarbeiten können.
anderen Systemen (auch verteilten, werksübergreifenden Umfangreiche „Expertenoberflächen“ sind jetzt kaum mehr
Systemen) zuzugreifen oder spezifische optimierte Daten- von Nöten, sondern das Design der Oberflächen bietet vor
strukturen für das Frontend zu verwenden.
allem transparente, selbsterklärende Oberflächen für
bestimmte Arbeitsschritte.
© OPITZ CONSULTING GMBH 2016
SEITE 13
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Die Lösungsansätze wurden in konkreten User Journeys und
PoCs mit dem Kunden verifiziert und gegen die Systemarchitektur des geplanten MES gespiegelt. Das aktuelle
Architekturkonzept konnte die dokumentierten User
Journeys vollständig abdecken. Ein weiterer Gesichtspunkt
der konsequenten Entkopplung von Oberfläche und Backend
ist die Chance, eine Governance für die „IT der zwei Geschwindigkeiten“ zu erreichen. Das Ergebnis waren eine fehlerfreie,
eher planbare und an der Robotik ausgerichtete Entwicklung
des MES Backends mit schnellen Releasezyklen und an den
Bedarf ausgerichteten Oberflächen für die Werker.
Die Herausforderung war dabei der Spagat zwischen der
starken Standardisierung der Prozesse, die in einem Callcenter notwendig und sinnvoll sind, und der Flexibilität, die notwendig ist, um sich den Veränderungen des Marktes, insbesondere der Kundenbindung, anzupassen.
Das zweite Unternehmen ist Monopolist in seinem
Geschäftsfeld. Da die Branche aber seit etlichen Jahren
schrumpft, besteht dennoch ein starker Druck, die Kosten zu
reduzieren. Einer der Ansätze war es, die Arbeit der Sachbearbeitung über eine attraktive Web-Anwendung auf den
Kunden zu verlagern. Beide Parteien sollten von dieser
LESSONS LEARNED
Lösung profitieren: Der Kunde erhält einen 24/7-Service,
während das Unternehmen Personal in der Sachbearbeitung
Data Streaming
einsparen bzw. dieses für neue Geschäftsfelder einsetzen
Unser erster Ansatz vernachlässigte das Data Streaming der kann.
Maschinen. Zum einen als Rohstoff für Analysen und
Steckbriefe der Unternehmen
Predictive-Maintenance-Ansätze und zum anderen für die
event- und Message-getriebene SPS-Steuerung des
Maschinenparks. Im abschließenden Blueprint sind wir auf
die physikalischen Tiers der Middleware, auch in Bezug auf
Security-Aspekte, näher eingegangen.
Security
Die Projektgruppe hat das Security-Thema anfangs nicht ausreichend betrachtet. Da der Shop Floor über die Mobile
Devices sozusagen „öffentlich“ wurde, waren verschärfte
Sicherheitsvorkehrungen angebracht.
User Journeys
Der Ansatz des Kunden, mit den Beteiligten die Arbeitswelt
über User Journeys31) zu erleben, hat bei der Konzeption
neuer Oberflächen deutlich geholfen. Wir werden diesen
Ansatz zukünftig aufgreifen und mit den Ansätzen des
Impact-Mappings32) zusammenführen.
Fallstudie 4: Flexibilisierung der
Standardsoftware
Diese Fallstudie betrachtet zwei sehr ähnliche Projekte, bei
denen es in zwei unterschiedlichen Unternehmen und
Branchen zu ähnlichen Lösungsansätzen bei der Applikationsarchitektur gekommen ist.
Gründung
1912 bzw. 1949
Tätigkeitsfeld
Callcenter bzw. Internetauftritt
Branche
Energieversorgung / Finanzdienstleistungen
Firmenstruktur
GmbH
Umsatz
n. a.
Mitarbeiter
Ca. 1.200-2.500
LÖSUNGSANSATZ
In beiden Fällen entschieden sich die Unternehmen beim
Backend für etablierte und bewährte Standardsoftware.
Neben SAP kamen weitere Standardprodukte zum Einsatz.
Für das Frontend hatten sich die Unternehmen für ein
innovatives, modernes Produkt entschieden, mit dem sie sich
von den Mitbewerbern absetzen und ihre Kunden und Mitarbeitern besser unterstützen können.
Einführung des Delivery Tiers für die Frontends
Die Projekte für Backend und Frontend wurden gleichzeitig,
aber unabhängig voneinander durchgeführt. Auf der
Backend-Seite wurde versucht, die Anzahl der Schnittstellen
gering zu halten und Wiederverwendung zu fördern.
UNTERNEHMEN UND GESCHÄFTSTREIBER
Das erste Unternehmen befindet sich in einem hart umkämpften Marktumfeld, dass sich rapide ändert. Die
Bestandssoftware für sein Callcenter war in die Jahre gekommen, entsprach nicht mehr den Ansprüchen der User an
moderne
Benutzeroberflächen
und
musste
daher
modernisiert werden.
© OPITZ CONSULTING GMBH 2016
Generell fiel uns auf, dass sich die Anforderungen an das
Frontend schneller änderten als die Anforderungen im Backend. Bei der Benutzeroberfläche lohnt es sich, flexibel auf
neue Anforderungen und Ideen reagieren zu können. Die
Kerngeschäftsprozesse hingegen sind unternehmenskritisch
und jede Änderung will gut überlegt sein.
SEITE 14
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Diese unterschiedlichen Voraussetzung führten dazu, dass
die Schnittstellen des Backends nicht recht zu den Anforderungen des Frontends passen wollten. Je mehr sich die
Backend-Prozesse am Standard orientieren, desto stärker
fällt diese Diskrepanz ins Gewicht.
Die Projekte fuhren also eine zweigleisige Strategie: Die neu
eingeführte Schicht in der Delivery Tier war hilfreich, um die
unterschiedlichen Entwicklungsgeschwindigkeiten von Client
und Server zu ermöglichen. Aber es lohnte sich in vielen Fällen, komplexe Services im Backend zu implementieren. Beispielsweise aus organisatorischen Gründen: Niemand kennt
das Backend besser als der Backend-Entwickler. Wenn
Standardservices in der Middleware oder im Frontend
orchestriert werden sollen, müsste dort das Know-how in der
Regel erst aufbaut werden.
Ein klassisches Beispiel ist die Adressverwaltung in SAP.
Kontaktdaten wie Anschrift, Telefonnummer und E-MailAdresse sind in den meisten Anwendungen einfache
Eingabefelder in einer Maske. Im Backend werden sie in
einer komplexen Datenstruktur gespeichert. Die entsprechende Schnittstelle wurde dem Client-Projekt ursprünglich LESSONS LEARNED
unverändert als Webservice bereitgestellt. Das Ergebnis war,
dass es einige Wochen dauerte, das Laden und Speichern der Starre BPM-Prozesse nicht immer hilfreich
Kontaktdaten zu implementieren.
Aus strategischen Überlegungen heraus wurden die Prozesse
in beiden Fällen mit BPM modelliert und ausgeführt. RückNach dieser Erfahrung änderte das Projektteam seine blickend betrachtet hatte dieser Ansatz nicht nur Vorteile.
Strategie. Zum einen wurden auf der Backend-Seite Eine der Gefahren war es, BPM für alles einsetzen zu wollen.
dedizierte Services für die jeweilige Aufgabe angefordert. Es gibt aber in jedem Unternehmen auch Abläufe, die nicht
Das hatte mehrere Vorteile:
standardisiert werden können, deren Modellierung vergessen wurde oder die nicht modelliert werden konnten, weil die
■ Das fachliche und technische Know-how über die entsprechenden Anforderungen erst später entstehen. In
Besonderheiten des Backend-Systems ist auf Backend- diesen Fällen ist es wichtig, dass die Software auch ohne
Seite vorhanden, während es auf Frontendseite erst einen starren, vordefinierten BPM-Prozess verwendet werden
aufgebaut werden muss.
kann oder dass die Prozesse flexibel genug sind, auch unvor■ Es besteht die Chance, Daten bereits an der Quelle zu hergesehene Abläufe abbilden zu können34).
aggregieren. Dadurch verbessert sich die Performance,
Bei der Toolauswahl gilt es zu beachten, dass es leichtund die Angriffsfläche für Hacker wird kleiner.
■ Die Erfahrung zeigte, dass es in vielen Fällen einfacher und gewichtige und schwergewichtige BPM-Engines gibt. Hier
billiger ist, SAP Services in wenigen Zeilen ABAP-Code zu kann man keine generelle Empfehlung aussprechen: Beide
komponieren, als dies auf der Client-Seite zu versuchen. Engines haben in unterschiedlichen Einsatzszenarien ihre
Das gilt insbesondere dann, wenn Webservices verwendet Existenzberechtigung. Es lohnt sich, zu Projektbeginn eine
werden. Webservices erzeugen eine große Menge Boiler- Evaluierungsphase einzuplanen, um die passende BPMplate-Code33), und die meisten Webservice Tools erzeugen Engine auszuwählen. Oder zu prüfen, ob überhaupt eine
unterschiedliche
Klassen
für
identische
SAP- BPM-Engine benötigt wird. Die Einführung eines BPMDatenstrukturen. Das Wissen, dass es sich um ein und Systems ist eine weitere Abstraktionsebene. In den meisten
dieselbe Datenstruktur handelt, geht im Webservice Fällen führt das dazu, dass sich Mitarbeiter auf das BPMverloren. Das Ergebnis sind arbeitsintensive und fehler- System spezialisieren. Das wird auch im Architekturmodell
trächtige Konsolidierungsmaßnahmen der Entwickler.
deutlich: BPM ist eine weitere Schicht.
Nicht in allen Fällen ist es möglich oder sinnvoll, für jeden
Client spezielle Schnittstellen bereitzustellen. Dafür kann es
viele Gründe geben – nicht zuletzt den Grund, dass es viele
Standardsoftwareprodukte gibt, die eine individuelle Anpassung der Schnittstelle nicht vorsehen. Um dem Client in diesem Fall trotzdem maßgeschneiderte Schnittstellen bieten zu
können, haben wir Backend und Frontend durch eine weitere
Serviceschicht entkoppelt. Im Laufe der Projekte wurden die
Vorteile dieser zusätzlichen Schicht deutlich. Die Clientseite
gewinnt eine Menge Flexibilität. Auch Änderungen der
Schnittstelle auf dem Backend verlieren ihren Schrecken: Es
müssen nur einige wenige Schnittstellen in der Delivery Tier
angepasst werden, aber nicht die vielen Stellen, an denen die
Client-Anwendungen diese Schnittstellen verwenden.
© OPITZ CONSULTING GMBH 2016
Eine denkbare Alternative ist es, auf den intelligenten
Mitarbeiter zu setzen. Wie bereits weiter oben beschrieben,
zeichnet sich im Allgemeinen die Tendenz ab, dass der
„Arbeitsplatz“ eher aufgaben- und eventorientierter wird,
und nicht mehr auf einem statischen Workflow basiert. Geben Sie Ihren Mitarbeitern also die Werkzeuge an die Hand,
die sie für ihre Arbeit benötigen. Wie die Aufgaben gelöst
werden können, wissen Ihre Mitarbeiter auch ohne die Hilfe
eines Prozessmodells. In der Praxis kristallisieren sich bei
diesem Ansatz wieder Prozesse heraus – aber diese Prozesse
können jederzeit flexibel geändert werden.
SEITE 15
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Projektlaufzeit: Eines der beiden Projekte dauerte mehr als ■ Die Releasefähigkeit wird in keiner Weise eingeschränkt.
fünf Jahre. Damit wurde ein Problem deutlich, dass sonst ■ Es entstehen keine risikoreichen Migrationsprojekte.
eigentlich erst in der Wartungsphase auffällt: Die Architektur ■ Die Releasefähigkeit anderer Systeme wird nicht
beeinträchtigt.
muss flexibel sein. Die Anforderungen, die wir heute umsetzen, fallen in fünf Jahren möglicherweise weg, werden
durch andere Anforderungen ersetzt oder sie werden im Wir sehen drei sinnvolle Ansätze, um externe Kaufsysteme in
Laufe der Zeit ausdifferenziert. Ihre Anwendungsentwickler die Applikationslandschaft einzubeziehen. Abbildung 7 stellt
müssen mit dieser Situation umgehen können. Dafür diese dar.
brauchen sie eine flexible Architektur, die mit den
Anforderungen mitwachsen kann. Das gilt in besonderem
Maße für den Client, bei dem die rasante Entwicklung der
Technik hinzukommt. Auch eine Technologie, die heute up to
date ist, ist in fünf Jahren möglicherweise veraltet und muss
durch eine andere Technologie abgelöst werden.
Modularisierung
Um das Problem der fehlenden Flexibilität zu lösen, hatten
wir die Anwendung in kleinere Module aufgeteilt nach der
Idee der Microservices: Wir bauen kleinere Einheiten, die
leichter zu verstehen sind und unabhängig voneinander gewartet und weiterentwickelt werden können. Die Kunst dabei Abbildung 7: Make-and-Buy-Entscheidungen bei CAFA
ist es, die Microservices trotzdem so zu verzahnen, dass sie
aus Anwendersicht eine zusammenhängende Anwendung ALTERNATIVE 1: BUY ALS SELF-CONTAINED APPLICATION
bilden. Eine Herausforderung des Microservice-Ansatzes ist
Aus Deployment-Sicht stellt die Einbindung von Selfdie Vermehrung der Schnittstellen und deren Governance.
Contained Applications36) eine sinnvollen Alternative dar, da
das erworbene System weitestgehend unabhängig von der
Ganzheitliches Denken der Fachbereiche
Eine der wichtigsten Erkenntnisse aus diesen Projekten war, bestehenden Applikationslandschaft verändert werden kann.
dass die Auftraggeber selbst keine Modularisierung wollten, Die verwendeten Interfaces sind das sogenannte „Nadelöhr“.
dies war allein der Wunsch der IT. Der Fachbereich hingegen Sollten sich die Interfaces verändern müssen, so müssen die
dachte ganzheitlich: Er will seine Aufgabe möglichst einfach Business Services der Service Tier verändert werden. Diese
und effizient lösen. Idealerweise braucht er dafür nur ein Entscheidung liegt jedoch in der Hand des jeweiligen UnterWerkzeug. Das beißt sich natürlich mit dem Wunsch der IT, nehmens. Schwieriger in Bezug auf Governance und Termindurch kleine und handliche Microservices Flexibilität und planung ist der Impact einer notwendigen Veränderung der
Wartungsfreundlichkeit herzustellen. Die Herausforderung Serviceschicht, die das Standardprodukt nachvollziehen sollbeim Entwurf einer flexiblen, zukunftssicheren Architektur ist te. Hier hängt viel von den Verträgen mit dem Systemes also, ein aus Modulen bestehendes System zu bauen, das lieferanten ab.
die ganzheitliche Denk- und Arbeitsweise der Anwender unterstützt. Im Laufe der Projekte haben wir dafür das Konzept Ein weiterer Nachteil liegt in der Schwierigkeit, die Funktionader Enterprise App mit einem Enterprise App Store und der lität des Standardprodukts über die Business-Service-Schicht
Kontextübergabe zwischen verschiedenen Apps entwickelt, möglichen Frontend-Komponenten über die APIs anzubieten.
wie oben beschrieben.
ALTERNATIVE 2: BUY ALS PLATTFORMKOMPONENTE
Wahlfreiheit: Make & Buy
Die Flexibilität des App-Store-Ansatzes zeigt sich auch in den
Alternativen zur Einbeziehung von Standard-Komponenten in
die
Enterprise-App-zentrische
Applikationsarchitektur.
Grundlage beim Zukauf einer Standardlösung muss allerdings sein, dass durch eine Veränderung35) des Standardprodukts Probleme, wie diese ausgeschlossen sind:
© OPITZ CONSULTING GMBH 2016
Bei dieser Variante, die im Grunde der Spezialfall einer
Einschränkung von Alternative 1 ist, stellt sich die StandardLösung als eine Plattformkomponente dar. Lediglich mit
einer Basis-Oberfläche oder gar mit einem Expertensystem
ausgerüstet, bringt die Komponente einen API-Layer oder
einen Business Service Layer (logische Schicht) mit, die durch
Frontend-Systeme und Business Services konsumiert werden
können. Diese aufgesetzten Lösungen sollten wiederum
Self-Contained Applications sein.
SEITE 16
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Der Vorteil dieses Ansatzes liegt in der Möglichkeit, das Die gewählte Architektur ist auf Veränderung ausgelegt und
System flexibel in die Frontend-Entwicklung einzubinden.
unterstützt
unterschiedliche
Geschwindigkeiten
beim
Deployment von neuen Versionen. Darüber hinaus gibt es im
ALTERNATIVE 3: BUY EINER OBERFLÄCHENKOMPONENTE klassischen Sinne keinen einheitlichen Releasestand mehr.
Fast alle Komponenten sind unabhängig voneinander
In diesem Fall erwirbt man eine Oberflächenkomponente, die veränderbar. Die Oberflächen mit den Apps sind individuell
durch Nutzung der eigenen Business Services oder API releasefähig und eine Absprache ist nur notwendig, wenn
Interfaces eine kundenspezifische und somit erweiterte Ober APIs und somit implizit Geschäftslogik verändert werden
-flächenfunktionalität bereitstellen kann.
muss. Die Oberflächen werden sich erfahrungsgemäß
permanent verändern und können über agile Ansätze in
Diese Variante ist eine gute Grundlage für die Nutzung der engerer Zusammenarbeit mit den Stakeholdern optimiert
eigenen Applikationsplattform durch Dritte.
werden.
Der Rechenkern des Backends wird sich langsam und kontrolliert verändern. Da jeder Störfall teuer ist, steht hier das
Motto „Make no mistakes“ im Vordergrund. Fehler beim
Die vorgestellte agile Applikationsarchitektur unterstützt Frontend wirken sich nicht auf das Backend aus, da die allAnsätze zur Implementierung einer „IT der zwei Geschwindig- gemeingültige Geschäftslogik, die von den APIs aufgerufen
keiten“, auch Bimodale-IT37) genannt. Die Entkopplung der wird, die Fehler abfängt.
Frontends ermöglicht Lean-Startup-Ansätze für Innovationen
oder die Verwendung von agilen Methoden wie Scrum, um GOVERNANCE
mit Fachbereichen gemeinsam bedarfsgerechte Lösungen zu
erstellen. Die Entkopplung und die weitestgehende Der vielleicht wichtigste organisatorische Punkt ist die ImpleUnabhängigkeit der Oberflächenkomponenten, die wir als mentierung einer leichtgewichtigen Governance für die PlattEnterprise Apps bezeichnet haben, ermöglicht unabhängige form selbst. Die IT-Organisation muss sich auf eine solche
und schnelle Releasezyklen für eine schnelles Time-to-Market Governance einstellen und das gesamte Frontend einschließvon neuen Ideen.
lich Backend als „eine“ Plattform verwalten und nicht als
Projekte oder eine Sammlung von Systemen. Andernfalls
Der Backend-Bereich einschließlich der robusten und besteht die Gefahr, dass die Organisation das agile Gebilde
gesicherten Business Services, (in Abbildung 8 unterhalb der der Enterprise Apps über das Portfoliomanagement
gestrichelten gelben Linie dargestellt) wird sich in wohl- schleichend wieder als eine Einheit sieht und somit der
definierten, planbaren Zyklen verändern. Hier steht die Langsamste gewinnt.
Business Continuity im Vordergrund und der Slogan
„Make no mistakes“ soll das hier durchaus angebrachte Eine solche Governance muss die Technologievielfalt einSicherheitsstreben unterstreichen.
schränken, ohne die Vorteile von neuen Technologien für
den Anwender aus den Augen zu verlieren. Ferner muss die
Governance nun als neue Facette erreichen, dass Aspekte
wie die Geschwindigkeit der Oberflächenveränderung und
Veränderungen durch den Zukauf von Standardkomponenten die Plattform selbst nicht kompromittieren.
Organisatorische Implikationen
Chancen & Risiken
Abbildung
8:
Implizite
einer bimodalen IT
Unterstützung
© OPITZ CONSULTING GMBH 2016
von
Bisher sind wir mehr auf die Vorteile der flexiblen EnterpriseApps-zentrischen Applikationsarchitektur eingegangen, die
das CAFA zu bieten hat, und weniger auf die möglichen
organisatorischen Schwierigkeiten. Deshalb möchten wir im
Folgenden im Sinne eines Benefits- und Risikomanagements
Ansätzen auf möglichen Risiken aber auch auf Benefits und Chancen
der vorgestellten „Designed for Change“-basierenden CAFA
zu sprechen kommen.
SEITE 17
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
CHANCEN
Hier muss man aus den Erfahrungen der umfassenden SOAFactory-Ansätze lernen und den Apps einen Freiraum bieten.
die
Architektur
können
Unabhängigkeit: Durch
unabhängige Frontend Enterprise Apps wie auch BackendSysteme mittels Microservice-Architekturen implementiert
werden, die unabhängig voneinander sind und somit unterschiedlichen Application-Lifecycle-Ansätzen folgen.
Governance: Designvorgaben/Patterns müssen entwickelt
werden, um Leitlinien und Ansatzpunkte für Entscheidungen
zu bekommen. Eine leichtgewichtige Governance muss die
Einfachheit und Stabilität der API-Interfaces verteidigen.
Hierzu gehört auch die Umkehrung der SOA-Sicht von „so viel
Standardkomponenten: Die Chance besteht darin, wie möglich“ auf „so wenig wie nötig“.
passende Standardsoftware und Standardkomponenten zu
nutzen, falls diese die API-Schicht als Client oder als Server Fehlschlagrisiko
Das Enterprise-App-Store-Konzept wie auch die CAFA sind
unterstützen.
neuartig und erst jetzt entstehen punktuell Lösungen, die
Aufgabenspezifische Apps: Bedarfsgerechte und aufgaben- diese Konzepte aufgreifen. Bestehende Forschungsansätze
spezifische Apps steigern die Effizienz der Benutzer und und Best Practices zum Common Plattform Development
unterstützen eine kundenzentrische Sichtweise.
sollten hier einbezogen werden.
Einfachheit: Die Frontends der Apps sind bedarfs- und Machbarkeit: Über PoCs und produktive Pilot-Installationen
aufgabengerecht und müssen somit selbsterklärend sein. sollte man die neuen Konzepte in eingeschränkten
operativen Umgebungen eingehend prüfen.
Akzeptanz: Hohe Akzeptanz der Anwender durch
Outside-in-Design und spezifische Oberflächen, die
zur Problemlösung bei einer bestimmten Aufgabe entwickelt
wurden. Viele aktuelle Anfragen unserer Kunden beziehen sich auf
Innovation: Die Unabhängigkeit der Releasezyklen wirkt sich innovative Ansätze zur Modernisierung ihrer Applikationspositiv auf Innovationen aus, da Änderungen und auch neue landschaft und gleichzeitig auf die Fragestellung, wie man die
Apps das Verhalten der bestehenden Apps nicht berühren. notwendige Flexibilität für die Anforderungen der Digitalisie rung erreichen kann.
RISIKEN
Mit der vorgestellten Referenzarchitektur CAFA haben wir
Neben den typischen Projektrisiken liegt die wesentliche Ihnen einen Ansatz präsentiert, den wir aktuell bei unseren
Gefahr in einem schleichenden Kompromittieren der Architekturberatungen zur Applikationsstrategie empfehlen.
Architekturmuster des CAFA. Die Governance muss in der Die vorgestellten Fallstudien haben gezeigt, dass die VerwenLage sein, das Muster des „Designed for Change“ in ihren dung des Blueprint nicht 1:1 erfolgt, aber die Kernidee des
Entscheidungsprozessen zu übernehmen und hierbei die Designed for Change und somit die konsequente Entkopplung
unterschiedlichen Geschwindigkeiten, Vorgehensmodelle der Frontends vom Backend spiegeln sich letztendlich in
allen Lösungen wider.
und Methoden einzubeziehen.
Zusammenfassung
Steigende Wartungskosten
Das Konzept ermöglicht einen Wildwuchs an (spannenden)
Technologien. In der Folge können sich die Wartungskosten
negativ entwickeln38).
Insbesondere bei der Entwicklung einer Roadmap für ein
Transformationsvorhaben von einer Legacy-Landschaft auf
eine flexible Applikationslandschaft dient der vorgestellte
Blueprint als Zielarchitektur.
Governance: Eine Governance muss implementiert werden, Die grundlegenden Vorteile entstehen durch die konseum den möglichen technologischen Wildwuchs auf ein sinn- quente Entkopplung der Frontends mit einer hohen
volles Maß einzuschränken.
Änderungsrate von den nach Stabilität strebenden BackendSystemen. Jedoch besteht die Lösung nicht aus zwei separaZu enge Kopplung
ten Frontend– und Backend-Monolithen, sondern angestrebt
Durch eine zu enge Kopplung der API-Schicht inklusive der sind kleinere und in sich releasefähige Systeme in Front– und
fachlichen Logik des Backends mit den benötigten Funktiona- Backend. Hier sollten auch die aktuellen Ansätze ROCA und
litäten der unterschiedlichen Apps besteht das Risiko, dass Microservice-Architekturen einbezogen werden.
die API-Schicht zu einem Nadelöhr wird.
© OPITZ CONSULTING GMBH 2016
SEITE 18
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
Anmerkungen & Quellen
An dieser Stelle beginnt die Outside-in-Betrachtung von
Softwarelösungen, und somit die konsequente Ausrichtung
der Mensch-Maschine-Interaktion an den Bedürfnissen der 1)
Anwender, an Bedeutung zu gewinnen.
2)
Ein weiterer Vorteil der vorgestellten CAFA ist die Möglichkeit,
eine Enterprise-App-zentrische Architektur zu implemen- 3)
tieren. Gerade bei den aktuellen Fragestellungen der Digitalisierung und des Internet der Dinge bietet sich der 4)
5)
vorgestellte CAFA-Ansatz an.
Aktuell beschäftigen wir uns in diesem Zusammenhang
zum einen intensiv mit der Optimierung der Delivery Tier 6)
mittels Backend-for-Frontend-Konzepten40), um die Frontends
optimal mit Objekten zu versorgen und zum anderen mit der
Anpassung von methodischen Ansätzen aus dem Enterprise
Architecture Management, um die funktionalen Anforderungen, auch für die Bedürfnisse der Endanwender, über
Business Capabilities41) zu erfassen.
7)
„One size fits all“ oder rigide Harmonisierungs- und Standardisierungsinitiativen torpedieren den „Designed for Change“Ansatz des CAFA. Andererseits sind Lean-Startup-Ansätze
und teilweilweise agile Methoden nicht unbedingt ziel- 8)
führend bei der Entwicklung stabiler Backend-Systeme. Wie
so oft sind Ausgewogenheit und bedarfsgerechtes 9)
Vorgehen entscheidend. Hier greift die geschilderte
Governance für die Plattform ein.
10)
Insbesondere die weitere Differenzierung der Endgeräte in 11)
den kommenden Jahren erfordert eine flexible Architektur,
um die neuen Gerätetypen zu unterstützen und einen multimodalen Zugriff auf die Backend-Systeme zu ermöglichen.
Einen Vorschlag, der diese multi-modale Nutzung unterstützt,
haben wir mit dem Stil der Context-Aware Frontend
Architecture (CAFA) vorgestellt. Die nächsten Jahre werden
zeigen, ob sich dieser Architektur-Stil trägt und welchen Einfluss eine breite kontextabhängige Gerätenutzung auf Front- 12)
end-Architekturen haben wird. Wie unsere Fallstudien zeigen,
waren unsere ersten Erfahrungen bislang durchweg positiv.
13)
Der Druck zur Digitalisierung der bestehenden Geschäfts- 14)
modelle wächst und somit auch der Druck auf die zentrale IT,
innovative und vor allem flexible Lösungen zu liefern. Neue
Ansätze der Applikationslandschaft, wie auch der beschriebene CAFA-Ansatz müssen verfolgt werden, um die Lieferfähig- 15)
keit der IT zu erhöhen und somit implizit auch die
Wettbewerbsfähigkeit der Unternehmen zu sichern.
16)
17)
© OPITZ CONSULTING GMBH 2016
Lünendonk Whitepaper „Software-Modernisierung“,
Lünendonk, 2015
http://android-developers.blogspot.de/2016/05/
android-instant-apps-evolving-apps.html
http://smallbusiness.chron.com/microsoft-pwa33554.html
https://www.microsoft.com/microsoft-hololens/en-us
Bernhardt, Sven: “Microservices architecture –
thoughts from a SOA perspective”, SOA Magazine,
2014
Dies fühlt sich wie bei Netflix an: Die unterschiedlichen
Endgeräte führen stets den aktuelle Benutzerkontext
mit, sodass der Anwender die Ausgabegeräte nach
Belieben wechseln kann, aber seinen Kontext stets
behält. Jedes Endgerät hat Stärken und Schwächen
und der Benutzer kann sein Endgerät frei wählen.
Omni Channel bedeutet die Verallgemeinerung der
Multi-Channel-Ansätze bei der Benutzerinteraktion
und fordert, dass alle verfügbaren und genutzten Interaktionsmöglichkeiten auch im Geschäftsmodell
beachtet werden.
TDWI Europe (Hg.): „Big Data – Ein Überblick“, dpunktVerlag, 2016
http://blogs.forrester.com/nigel_fenwick/14-03-20the_future_of_business_is_digital
https://www.mulesoft.com/resources/esb/hybridcloud-integration-solutions
Im Deutschen werden „Layer“ und „Tier“ homonym
mit dem Wort „Schicht“ übersetzt. Wir betrachten in
diesem Fall nicht die logische Architektur („Layers“)
betrachten, sondern die notwendigen physikalischen
Schichten („Tiers“). „Tiers are the physical deployment
of layers”, siehe Rockford Lhotka, http://
www.lhotka.net/weblog/ShouldAllAppsBeNtier.aspx,
2005
http://blogs.forrester.com/ted_schadler/13-11-20mobile_needs_a_four_tier_engagement_platform
https://docs.oracle.com/cd/E18727_01/doc.121/
e12064/T291171T509870.htm
http://www.sigs-datacom.de/fachzeitschriften/
objektspektrum/archiv/artikelansicht/artikel-titel/
frontend-architekturen-fuer-microservice-basiertesysteme.html
Ein weiterer Aspekt ist die Möglichkeit Digital Labs
oder Lean-Startup-Ansätze bei der Entwicklung bzw.
Verprobung von Ideen einzuführen, etwa im Rahmen
einer digitalen IT-Strategie.
http://searchcloudapplications.techtarget.com/
definition/API-management
Constrained Application Protocol,
http://coap.technology/
SEITE 19
WHITEPAPER
„CONTEXT-AWARE FRONTEND ARCHITECTURE“
18)
19)
20)
21)
22)
23)
24)
25)
26)
27)
28)
29)
30)
31)
32)
33)
34)
35)
36)
37)
38)
39)
40)
41)
Message Queue Telemetry Transport
http://mqtt.org/
http://www.theaugmentedreality.de/
http://www.trading212.com/
http://dbs.uni-leipzig.de/html/seminararbeiten/
semSS98/arbeit5/dwdm-vortrag5-11.html
https://www-01.ibm.com/software/data/infosphere/
hadoop/mapreduce/
https://www.myo.com/
http://www.e-commerce-magazin.de/effizient-durchomni-channel
Aus heutiger Sicht könnte man auch von einem TabletFirst Approach sprechen (http://
blog.springstudio.com/2015/04/09/tabletfirst/)
Adaptive Case Management (bpmpractice.de/wpcontent/uploads/2013/10/ACM-V4.06.pdf)
https://developer.android.com/reference/android/
content/Intent.html
https://www.mulesoft.com/resources/cloudhub/ipaasintegration-platform-as-a-service
http://www.oracle.com/us/solutions/fastdata/
index.html
https://www.bosch-si.com/ads/iot-technology-de/
index.html?gclid=CPSyi8SemswCFY4y0wodE7oOJQ
http://www.businessmodelcreativity.net/usercustomer-journey-mapping/
https://www.impactmapping.org/
https://en.wikipedia.org/wiki/Boilerplate_code
Näheres zum Thema Adaptive Case Management
(ACM) findet man in Kapitel 9 vom Buch “Design Principles for Process-driven Architectures Using Oracle
BPM and SOA Suite 12c”; https://www.amazon.de/
Design-Principles-Process-driven-Architectures-Oracleebook/dp/B00ZPJWBL2/ref=sr_1_1?
ie=UTF8&qid=1465491270&sr=81&keywords=winterberg+design.
Aus unserer Sicht sollte so wenig wie möglich
programmiert werden, sondern wirklich nur im
klassischen Sinn customized werden: Nur Anpassung
von Standardeinstellungen, möglichst ohne
Programmierung.
http://scs-architecture.org/
http://www.gartner.com/it-glossary/bimodal/
An dieser Stelle können wir von der Open-SourceGemeinde des Github lernen und unternehmensintern bereichsübergreifende eigene Open Source und
Social Coding Communities aufbauen!
http://roca-style.org/
https://www.thoughtworks.com/de/radar/techniques/
bff-backend-for-frontends
http://searchsoa.techtarget.com/definition/businesscapability
© OPITZ CONSULTING GMBH 2016
Über OPITZ CONSULTING
Das IT-Beratungshaus OPITZ CONSULTING wurde 1990 von
Peter Dix, Bernhard Opitz und Rolf Scheuch in Bensberg bei
Köln gegründet – mit dem Ziel, Organisationsberatung und
IT-Projektabwicklung in einem Unternehmen zu vereinen.
Die erfolgreiche Zusammenarbeit mit unseren Kunden führte
zur überregionalen Expansion. Unter dem Dach der OPITZ
CONSULTING Unternehmensgruppe führen heute die OPITZ
CONSULTING Deutschland GmbH acht Standorte in Deutschland und die OPITZ CONSULTING Polska Sp. z.o.o. drei Standorte im benachbarten Polen.
WAS WIR MACHEN. EIN EINBLICK.
OPITZ CONSULTING trägt als führender Projektspezialist für
ganzheitliche IT-Lösungen zur Wertsteigerung von Unternehmen bei und bringt IT und Business in Einklang. Wir sind
Berater, Lösungsarchitekt und Projektspezialist und helfen
Ihnen, den richtigen Weg zu finden. Wir bieten Leistungen in
den Bereichen:
■
■
■
■
■
■
■
BI & Big Data
Cloud & Infrastruktur
Digitalisierung
Software Development
Managed Services
BPM & Systemintegration
Lizenzmangement
WAS WIR WOLLEN. EIN AUSBLICK.
Wir wollen gemeinsam mit allen Branchen Lösungen
entwickeln, die dazu führen, dass sich diese Organisationen
besser entwickeln als ihr Wettbewerb. Unsere Dienstleistung
erfolgt partnerschaftlich und ist auf eine langjährige
Zusammenarbeit angelegt.
SEITE 20

CA-INVIT Management-Summary (PDF 0,10 MB)

Webentwickler (m/w) in den Bereichen Backend und/oder Frontend

JUNIOR-ENTWICKLER Frontend

Joomla CMS-Prinzip

Senior Frontend Developer

Lebenslauf André Abt.pages

Frontend Software Engineer Werkstudent (m/f)

Managing Consultant (m/w)

developer (m/w) – frontend

CODIAC Stellenausschreibung