Context Aware Frontend Architecture - opitz- · PDF fileWHITEPAPER „CONTEXT-AWARE FRONTEND ARCHITECTURE“ Motivation Mit zunehmendem Wettbewerbsdruck müssen Unternehmen ihre Geschäftsmodelle

Context-Aware Frontend Architecture

Beispielszenarien für eine kontextsensitive Applikationslandschaft

© OPITZ CONSULTING Deutschland GmbH

■■■ Überraschend mehr Möglichkeiten

Whitepaper

WHITEPAPER „CONTEXT-AWARE FRONTEND ARCHITECTURE“

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 dargestellten Verfahren, Showcases, Implementierungsbeispielen und

Source Codes liegt ausschließlich bei OPITZ CONSULTING.

Inhaltsübersicht

Vorwort

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

Organisatorische Implikationen

Chancen & Risiken

Zusammenfassung

Anmerkungen & Quellen

Über OPITZ CONSULTING

Context-Aware Frontend Architecture

Beispielszenarien für eine kontextsensitive Applikationslandschaft

Autoren:

Richard Attermeyer,

Stephan Rauh & Rolf Scheuch,

OPITZ CONSULTING

Deutschland GmbH

Vorwort

Mit der Zusammenstellung dieser aktuellen Fallstudien möch-

ten 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 Syste-

me auf eine flexible Applikationslandschaft dienen.

Die Referenzarchitektur basiert auf unseren Erfahrungen aus

unterschiedlichen Projekten. Alle vorgestellten Fallstudien set-

zen darauf, die bislang monolithischen (Legacy-)Systeme durch

neue flexible Applikationsarchitekturen zu ersetzen und ent-

koppeln dabei Frontend- und Backend-Dienste.

Treiber waren die Digitalisierung der bestehenden Geschäfts-

modelle sowie ein „Design for Change“-Ansatz zur schnellen

Implementierung neuartiger digitaler Geschäftsmodelle.

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 Implementierungs-

phase haben wir dagegen etwas kürzer gehalten.

Gerne klären wir offene Fragen mit Ihnen oder erläutern

tiefere Details aus den Projekten. Sprechen Sie uns an.

Kontakt: rolf.scheuch@

opitz-consulting.com

+49 2261 6001-1223

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 SEITE 2


Motivation

Mit zunehmendem Wettbewerbsdruck müssen Unternehmen

ihre Geschäftsmodelle und -prozesse in immer kürzer werden-

den Zyklen anpassen. Gleichzeitig wird die Interaktion mit exter-

nen Geschäftspartnern durch Globalisierung und digitale Ver-

netzung immer komplexer. Verlässlicher Informationsaustauch

mit qualitativ hochwertigen Daten entscheidet darüber, ob Pro-

zesse effizienter werden und Kundenbindung erhöht wird.

Gleichzeitig ermöglicht die rasante technologische Entwicklung

innovative Ansätze bei der Mensch-Maschine-Interaktion. Diese

Herausforderungen setzen die bislang gewachsenen Applikati-

onslandschaften unter Druck: Eine grundlegende Veränderung

erscheint unumgänglich.

Kein Wunder, dass das Thema der Modernisierung von beste-

henden Applikationen und Legacy-Systemen deutsche Unter-

nehmen 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 Mo-

nolithen genannt, erweisen sich als änderungsresistent. Zukünf-

tige Applikationsarchitekturen erfordern ein Umdenken in den

Unternehmen. Bei unseren Kunden sehen wir die folgenden

grundlegenden Treiber für den Umbau der Applikationsland-

schaften:

■ Sie möchten neue Möglichkeiten der Mensch-Maschine-

Interaktion nutzen.

■ Es geht ihnen um die Umstellung auf bedarfsgerechte

User-zentrische Omni-Channel-Oberflächen.

■ Sie sehen die Notwendigkeit, neue Chancen durch Digitali-

sierung zu nutzen.

■ Geschäftspartner sollen auf der eigenen Plattform einge-

bunden werden.

Für uns ergeben sich daraus diese grundlegenden, fast

schon rhetorisch anmutenden, Fragen:

■ 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 Kernprob-

lem 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 Differenzie-

rung bei den Systemen nutzen, statt sie zu bekämpfen?

Qualitätsmerkmale

Auf die genannten Treiber möchten wir im Folgenden ausführli-

cher eingehen, weil sich in diesen Herausforderungen implizit

auch Qualitätsmerkmale der zukünftigen

Applikationsarchitektur verbergen.

Verbesserung der Mensch-Maschine-Interaktion

Computergestützte Benutzerschnittstellen sind aktuell im Um-

bruch. Vor wenigen Jahren war die Oberflächenwelt noch über-

schaubar. Es gab Desktop-Anwendungen, Webbasierte Inter-

faces und native Oberflächen für spezielle Devices wie Smart-

phones. 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.

Die Leistungsfähigkeit der Rechnerwelten wie auch die

Rechenleistung der Endgeräte befeuert diese Entwicklung zu-

sä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.

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.

Untersuchungen zum Applikationslebenszyklus der unter-

schiedlichen logischen Schichten der Software bestätigen dies.

Generell hält das relationale Datenmodell etwa 10-12 Jahre, die

Geschäftslogik bleibt trotz Weiterentwicklung ca. 5-7 Jahre

stabil, aber die Möglichkeiten der Benutzeroberflächen ändern

sich alle 2-3 Jahre grundlegend.

Aus unserer Sicht kann eine flexible Nutzung unterschied-licher

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.



Die Lösung liegt in einer weitergehenden Entkopplung der Soft-

wareschichten von Frontend und Backend.

Bedarfsgerechte User-zentrische Oberflächen

Parallel zu den neuen Trends in der Computernutzung lassen

sich beim Aufbau von IT-Systemen grundsätzliche Entwicklun-

gen zur Komplexitätsreduktion bei Client- und Backend-

Systemen erkennen.

Frontend-Systeme

Unternehmen wie auch Anbieter von Standardsoftware

verändern den Oberflächenentwurf, von großen, mono-

lithischen Clients mit komplexen, beinahe allmächtigen Oberflä-

chen, die alle Anwendungsfälle abdecken, hin zu kleineren, spe-

zialisierten Clients für einzelne Anwendungsfälle oder Benutzer-

gruppen. Dies lässt sich recht gut mit den Apps aus der mobi-

len Welt vergleichen. Eng umrissene Aufgabenfelder werden

mit bedarfsgerechten und intuitiven Oberflächen versehen.

Im Clientumfeld ermutigen zusätzlich die verschiedenen Endge-

räte mit ihren stark unterschiedlichen Leistungen und Funktio-

nalitäten ein solches Umdenken. Smart Watches und Hololen-

ses4) können nur sehr wenige bzw. stark aggregierte Informatio-

nen anzeigen. Mobiltelefone und Tablets sind für die Eingabe

von langen Texten nicht geeignet, ermöglichen stattdessen die

Aufnahme von Sprachnachrichten oder Fotos. Generell eignen

sich alle mobilen Endgeräte mit ihren kleinen Displays nur für

überschaubare UIs mit verhältnis-mäßig wenigen Masken.

Backend-Systeme

Diese Komplexitätsreduktion ist nicht ausschließlich ein Trend

bei den Clientsystemen, sondern auch bei den

Backend-Systemen. Der Monolith im Backend, der die

erwähnte strukturelle Zukunftsunfähigkeit durch die hohe Kom-

plexität und die daraus resultierende geringe Flexibilität verur-

sacht, wird zunehmend als Architekturentwurf in Frage gestellt.

Der aktuelle Microservice-Architekturansatz5)

unterteilt komplette Systeme (Frontend und Backend) in

kleinere, anhand der Geschäftslogik abgegrenzte Services.

Ziel ist es dabei, Weiter- und ggf. auch Neuentwicklung

voneinander zu entkoppeln, Abhängigkeiten zu reduzieren und

so das Gesamtsystem flexibler zu halten. Ferner wird die klassi-

sche Kommunikation eines Clients mit genau einem Server-

Backend heute immer öfter durch die Kommunikation mit meh-

reren unabhängigen Services ersetzt.

Dabei handelt es sich um interne Systeme, z. T. durch die Auf-

teilung der Backendsysteme in Microservices hervorgerufen,

aber auch zunehmend Online-Schnittstellen externer Anbieter

oder Cloud-Systeme. Clients können durchaus auch Services

von unterschiedlichen Backend-Systemen, ggf. sogar von exter-

nen Unternehmen (z. B. Partner- oder Dienstleistungsunterneh-

men), nutzen. Ein Treiber dieser Entwicklung sind die zuneh-

mend eingesetzten Software-as-a-Service-(SaaS)-Lösungen, die

Implementation eigener Cloud-Lösungen wie auch die Anbin-

dung von Dingen beim Internet der Dinge (IoT) und in Digitali-

sierungsprojekten.

Aus unserer Sicht führen diese Überlegungen zur

Implementation von kleinen, bedarfsgerechten und an einer

spezifischen Aufgabe ausgerichteten Applikationen. Diese Viel-

zahl an kleinen Apps werden über ein Enterprise-Apps Store-

Konzept, ähnlich einem Mobile Device Management, verwaltet

und können auch hierüber ihren Kontext

austauschen6).

Neue Chance durch Digitalisierung nutzen

Seit einiger Zeit lassen sich zwei nicht ganz trennscharfe Trends

hinsichtlich der Nutzung von Computern beobachten, die auch

im Unternehmenskontext immer mehr an

Bedeutung gewinnen:

Ubiquitous Computing beschreibt den Trend zu einer

Arbeitswelt, bei der alles zu einem Computer wird und die Ar-

beit unterstützt. Smartphones und Tablets aber auch

Devices wie Armbänder oder 3D-Brillen sollen jederzeit bei der

Arbeit Verwendung finden und situativ unterstützen.

Feste Arbeitsstationen gehören der Vergangenheit an und Re-

chenleistung ist überall zu Diensten. Zu diesem Trend

gehören auch die Omni-Channel-Ansätze7) bei der Interaktion

mit Geschäftspartnern oder Endkunden.

Pervasive Computing bedeutet, dass die Welt vernetzter wird.

Sensoren, Gegenstände und menschliche Akteure agieren in

einem gemeinsamen Netzwerk. Bekanntester Treiber dieser

Entwicklung ist die deutsche „Industrie 4.0“-Initiative. Beim per-

vasive Computing beginnen computerbasierende Systeme, mithilfe

von Sensorik die Umwelt wahrzunehmen und diese Informatio-

nen mit dem Anwender zu teilen. Dabei kommen soziale Infor-

mationen aus pseudo-sozialen Netzwerken wie einer Fabrikhal-

le in den Austausch. Zum Netzwerk „Fabrikhalle“ gehören Arbei-

ter genauso wie Maschinen. Zusammen ergibt sich ein virtuel-

les Gesamtbild beim Betrachter, etwa mit Ansätzen der Aug-

mented Reality.

These 1: Zukünftige Oberflächen verändern sich unabhängig und

schneller als die Geschäftslogik im Backend.

These 2: Zukünftige Oberflächen passen sich in schnellen

Zyklen dem Bedarf und den Erfahrungen der Nutzer an.



Beide Trends befeuern sich gegenseitig. Denn: Je eher ich die

Dinge vernetzte, desto eher kann ich überall elektronische Hilfs-

mittel nutzen. Und je eher ich überall arbeiten möchte, desto

eher sind wir bestrebt, die verwendeten Geräte zu

vernetzen.

Aus unserer Sicht führt diese Entwicklung zu kontext-sensitiven

Applikationen, die neben einem gesicherten

Kontext im Rahmen einer Omni-Channel-Strategie auch den

Kontext der Umgebung auswerten und verstehen. Somit wird

die Applikation selbst zu einem Baustein im umfassenden Netz-

werk des Internet of Everything und kann auf die Umwelt rea-

gieren. Eine weitere Nutzung liegt im Machine Learing8). Gerade

durch die enorme Steigerung der Leistungsfähigkeit heutiger

Rechner, der Skalierung durch Cloud Computing und die sin-

kenden Kosten für CPU und Speicher lassen sich nun bereits

bestehende Ansätze des Machine Learnings

realisieren.

Geschäftspartner auf eigener Plattform einbinden

Durch die Digitalisierung verändern sich traditionelle Wert-

schöpfungsketten. Immer größere Chancen ergeben sich aus

der Einbindung von Geschäftspartnern; sei es, um Geschäfts-

prozesse 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:

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äftspart-

nern über Schnittstellen den Zugang zu den Business Capabili-

ties des Unternehmens anbieten. Die Analysten von Forrester

sprechen von einem „Ecosystem of value“9), das sich permanent

an die Kunden- und Marktgegebenheiten anpasst, Kostensen-

kungspotenziale ermöglicht und durch neuartige, überraschen-

de 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

Fähigkeit besitzen, in kürzester Zeit und unkompliziert neue

Anforderungen der sich verändernden Geschäftsmodelle zu

erfüllen. Voraussetzung hierzu ist die Möglichkeit, Geschäfts-

partnern (Dritten) die eigenen Business Capabilities über gesi-

cherte Schnittstellen anzubieten oder selbst Dienste

Dritter in den eigenen Prozessen zu konsumieren.

Der Trend des Cloud Computings mit den SaaS-Lösungen ver-

schärft noch einmal den Aspekt des Time-to-Market und erfor-

dert hybride Infrastrukturarchitekturen10) für die Applikations-

landschaft. Dafür braucht es eine modulare Architektur des

Backends und der Frontend-Komponenten. Die

Releasezyklen der einzelnen Komponenten dürfen nicht die

Plattform als Ganzes kompromittieren.

Blueprint Context-Aware Frontend Architecture

Wir präsentieren in der Folge den Blueprint einer zukunftswei-

senden Referenzarchitektur, die die geschilderten Treiber

adressiert und die nötigen Qualitätsmerkmale besitzt. Diese

Referenzarchitektur bezeichnen wir als Context-Aware

Front End Architecture (CAFA) und wird in der Abbildung 1 dar-

gestellt. CAFA erweitert die drei bislang etablierten

Deployment-Schichten der Architektur, um die sogenannte De-

livery-Schicht.

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 For-

rester12) in Analystenberichten aufgegriffen. Wir haben dieses

Konzept zu einem Blueprint der Context-Aware-Frontend-

Applikationsarchitektur weiterentwickelt und

nutzen es bei der Beratung unserer Kunden als Basis für die

Konzeption einer Zielarchitektur für zukunftsweisende

Applikationslandschaften.

Abbildung 1: Flexibilität und Unterstützung einer Omni-Channel

Strategie durch CAFA

These 3: Zukünftige Oberflächen fördern die Vernetzung bei der

Mensch-Maschine-Interaktion.

These 4: Die eigene Applikationslandschaft wird zukünftig

zu einer Plattform für ein „Ecosystem of value“.



Delivery-Tier: Warum eine eigene physikalische Schicht

einziehen?

Die Schwachstelle beim Deployment etablierter

logischer Drei-Schichten-Architekturen liegt in der mangelhaf-

ten und zu schwerfälligen Unterstützung der unterschiedlichen

mobilen Devices und deren eingebauter Sensorik

sowie einer fehlenden Erweiterung auf die Anforderungen des

Internet der Dinge (IoT).

Die etablierte Drei-Schichten-Architektur stellt eine Plattform

für Business Services zur Verfügung und abstrahiert somit die

Backend-Dienste von einer spezifischen Oberfläche. Grundsätz-

lich eine richtige Denkweise, sollte man meinen: Diese Services

sind in der Regel als Webservices auf einer SOA-artigen Infra-

struktur implementiert und nutzen einen Enterprise Service

Bus, der auf einer eigenen Service Tier implementiert ist.

Betrachtet man die Anforderungen allerdings aus der Sicht der

Frontends und bezieht die User Experience als entscheidenden

Faktor mit ein, so zeigt sich, dass diese Denkweise in die falsche

Richtung führt: Die unterschiedlichen Clients

benötigen Daten mit unterschiedlichen Aggregationsstufen,

verbinden Daten aus unterschiedlichen, auch externen,

Services zu neuen Informationsobjekten, nutzen Public API o-

der Device-spezifische Möglichkeiten, die den bestehenden

Business Services nicht bekannt sind. Bleibt man nun dem Kon-

zept der Drei-Schichten-Architektur treu, so müssen die Busi-

ness Services zeitnah auf die spezifischen Belange der

Devices angepasst werden, oder bestehende Services werden

über neue zusammengesetzte Composite Services13) zusam-

mengefasst. Wenn sich die Business Services in Richtung von

Client-spezifischen Schnittstellen entwickeln, wird dies das Pa-

radigma der SOA aushebeln. In der Folge bestimmt und bremst

die Bereitstellung der SOA-Dienste die Innovation bei den

Oberflächen.

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 permanent

zu verändern.

Mit steigender Anzahl und Möglichkeiten unterschiedlicher De-

vices, der rasanten Entwicklung von HTML5 bzw. den

Entwicklungsumgebungen für die Devices sind die Innova-

tionszyklen15) deutlich höher als bei der Veränderung von Busi-

ness Services für die Backend-Prozesse.

Ein weiteres Argument für die Einführung einer zusätzlichen

Schicht liegt in der Ermöglichung eines API-Managements16) für

die Skalierung und die Security der mobilen Lösungen. Gerade

in der mobilen Welt ist die Bandbreite noch immer ein Hemm-

schuh und die schwergewichtigen SOA-Protokolle können hier

zu Engpässen führen. Aktuell nutzen mobile Lösungen oft REST-

full-JSON-Dienste (REST), die auf http(S) Protokollen basieren.

Blickt man in die Zukunft des Internet der Dinge werden sich

noch leichtgewichtigere Protokolle, etwa CoAP17) or MQTT18)

durchsetzen. Ferner besteht nun die Chance, einen Teil der

Delivery Tier in einer DMZ auszulagern und somit die eigenen

Backend-Prozesse externen Dritten zur Verfügung zu stellen.

Hierdurch wird die eigene IT-Welt zu einer Applikationsplatt-

form für Geschäftspartner. Dieses Konzept werden wir in den

Fallstudien genauer beschreiben.

Die Entkopplung der Frontends von den Backend-Services er-

möglicht ferner eine „Applikationsstrategie der zwei

Geschwindigkeiten“. Die sich permanent verändernden, Outsi-

de-in-getriebenen Oberflächen einerseits und die bedarfsge-

rechten Oberflächen, die auf sicheren und robusten Business

Services beruhen, andererseits. Dieser organisatorische Aspekt

wird am Ende noch eingehender betrachtet.

FrontEnd Tier: Welche Arten von Oberflächen bzw. UIs

gibt es?

Momentan können wir fünf grundlegende Frontend-Kategorien

identifizieren, die auch in Abbildung 2 dargestellt sind. Diese

Klassen an Frontends sind im CAFA-Architekturmodell abbild-

bar und werden im Folgenden etwas näher erläutert.

Abbildung 2: Klassifikation von User-Interfaces



Klasse „Complex Apps“

Zu dieser Klasse gehören Systeme mit funktionsreichen und

komplexen Oberflächen, die oft als „Expertensysteme“ kategori-

siert 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 Sach-

verhalten, und weniger „Tabellenwüsten“.

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.

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 Ge-

sichtspunkten grafisch übersichtlich und aufgabengerecht dar-

zustellen. Ein gutes Beispiel dafür sind Anwendungen für Call-

center 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 Dar-

stellung des aktuellen Status über Leitstände

ermöglichen. Hierzu gehört auch die Möglichkeit Simulationser-

gebnisse grafisch mit den aktuellen Daten der Produktionsland-

schaft 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 aufgaben-spezifische Lö-

sungen an. Diese Lösungen haben einfachste, selbsterklärende

Oberflächen, die meist ohne eine explizite manuelle Datener-

fassung auskommen. Denn eine manuelle Dateneingabe ist auf

Smartphones nicht effizient möglich.

Insbesondere die Nutzung der Sensoren eines Smartphones,

etwa der Kamera mit Bilderkennung, GPS oder Sprach-

erfassung 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 ein-zubinden.

Die notwendige Datenpflege zur Verwaltung der Tätigkeiten

wird unabhängiger von den Arbeitsstationen und verlagert sich

an den Ort der manuellen Tätigkeit.

Klasse „Analytical Apps“

Die Klasse der analytischen Systeme umfasst die Oberflächen,

die Drill-Down, Data Mining oder Ad-hoc Reporting unterstüt-

zen. 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.

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 MapReduce-

Verfahren22) , um Daten zu filtern und die Ergebnisse weiterzu-

verwenden.

Klasse „IoT-based Apps“

Mit dieses Klasse an Systemen haben wir uns etwas schwerge-

tan. 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 ent-

scheidend, dass es APIs für die fachliche Logik aus dem Ba-

ckend gibt, die unabhängig von der Oberflächen-Darstellung

sind. So ist es möglich, über die Hardware-spezifischen 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ächen-interaktion er-

möglicht, benötigen eine technische API, die die App nutzen

kann, um Bewegungen an Befehle zu koppeln. Beide Geräte-

klassen können kombiniert hochmoderne Interaktionen ermög-

lichen, bedürfen jedoch eine iterative, eher am Lean-Startup

angelehnte Entwicklung, um noch unbekannte Technologien

effektiv einzusetzen und somit schnell Mehrwerte zu

generieren.



Leitlinien für Arbeitsweise und Oberfläche

Als Ergebnis lassen sich die folgenden Leitlinien bezüglich Ar-

beitsweise und Oberfläche formulieren:

■ Klassische sequentielle Geschäftsprozesse mit

Entscheidungsbäumen werden immer unwichtiger.

■ Die bedarfsgerechte Information zum richtigen Zeitpunkt

und „context-aware“ zum aktuellen Standort wird zu einem

entscheidenden Faktor, um eine ganzheitliche Sicht zu er-

möglichen und Entscheidungen zu treffen.

■ Rechtzeitige Information, zügige Entscheidungen und

operatives Handeln treten in Vordergrund.

■ Erfahrungsaustausch und Crowd Sourcing in Peergroup und

Kollaboration sollen möglich sein.

■ Der Arbeitsplatz ist zunehmend nicht mehr statisch work-

flowbasiert, sondern eher aufgaben- und eventorientiert.

■ „Everywhere“, also überall, muss das System als Arbeitsmittel

einsetzbar sein.

■ Nutzung von verteilten, aber auch externen, Daten-

beständen soll möglich sein.

■ Oberflächen sollen einfach, klar und aufgabengerecht sein

und nicht umfänglichen „Expertensystemen“ entsprechen.

FrontEnd Tier: Warum ein Ansatz für Context-Aware

Enterprise Apps?

Ziel der neuen Oberflächen sollte die Etablierung einer Omni-

Channel-fähigen Kommunikationsplattform24) mit einheitlichen

IT-Services sein. Hierbei ist „alles“ ein Desktop-Rechner, also

auch BYOD, Machinen etc. Beim Oberflächendesign

sollte eine „Mobile First“-Strategie25) verfolgt werden, um orts-

ungebundenes Arbeiten mit unterschiedlichen Devices zu er-

möglichen.

Ferner werden komplexe Prozesse nicht in der Software-

oberfläche selbst dargestellt, sondern es gibt vor allem

bedarfsgerechte Oberflächen für anstehende Aufgaben.

Dabei ist zu berücksichtigen, dass ein „Information-Worker“ an-

dere Oberflächen braucht. Gefragt sind hier nicht mehr die

klassischen Expertenoberflächen mit komplexen Personalisie-

rungsstrategien, die diese in aufgabengerechte Monolithen

verwandeln26). Informationen und Oberflächen sollen einfach

austauschbar sein, um neue Ansätze bei der Mensch-

Maschinen-Interaktion implementieren zu können. Das ist nur

möglich, wenn die Semantik der Geschäftsobjekte

bekannt ist und Geschäftslogik in den unterschiedlichsten Kon-

texten wiederverwendbar ist. Hier hilft die Trennung von Ge-

schäftslogik und Oberflächen, sodass Oberflächen eher als Bau-

teile im bzw. Aufbauten auf dem Backend zu sehen sind. Zu-

künftig werden alle Objekte eine „Intelligenz“ besitzen, und die

IT-Leistung wird zunehmend dezentralisiert.

Die Oberflächen werden neben den Services der Backends

auch Umwelt-Variablen der Maschinenwelt oder Cloud-

basierender Lösungen von dritten Parteien einbeziehen.

In einem klassischen Ansatz würde man jetzt versuchen, sämtli-

che Anwendungen als Dach-Lösung unter einem Enterprise

Portal zu implementieren. Das Portal übernimmt die Aufgaben

einer zentralisierten Authentifizierung und

Autorisierung der registrierten Anwendungen. Jedoch sind uns

aktuell keine Portallösungen bekannt, die eine große Anzahl

disjunkten Applikationen mit unterschiedlichen Plattformen

sinnvoll unterstützen würden. Gleichwohl benötigt man eine

ordnende Hand, gerade in einem potenziellen „Wildwuchs-

Szenario“ wie dem Internet der Dinge. Abbildung 3 beschreibt

die Interaktion der Devices mit dem Enterprise App Store. Die

Delivery Tier mit dem API Management übernimmt somit die

nichtfunktionalen Aufgaben des Enterprise-Portals in einer he-

terogenen Welt.

Analog zu den App-Ansätzen bei Smartphones, sei es im Kon-

text von Apple oder von Android, schlagen wir die Implementie-

rung einer CAFA vor. Jede Applikation, unabhängig von ihrer

Implementation, registriert sich in einer zentralen Registry. Die-

se Registry ermöglicht die Authentifizierung, auch über die indi-

viduellen Mechanismen der eingesetzten

Devices wie Fingerabdruck oder Retina-Scan und führt Buch

über die erlaubten Funktionalitäten der Benutzergruppen und

Benutzer (Autorisierung). Ferner kennt die Registry aus den

physikalischen Parameter des Devices auch die erlaubten De-

vices für eine Anwendung.

Jede App hat ferner erlaubte Input-Parameter, URL– und API-

Strukturen und auch die REST-Strukturen für die fachliche Lo-

gik. Diese Parameter werden im zentralen App Store über ein

Device Management verwaltet. Mit diesem Ansatz ist es dem

virtuellen Portal möglich, pro Device einen Home-Screen zu

erstellen, der auf die individuellen Parameter des Benutzers

eingeht.

Abbildung 3: Interaktion von Device und Enterprise App Store



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 be-

steht, 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 ver-

wendet27). Jede App schreibt den Kontext beim

Verlassen schemafrei in eine Clipboard History. Die

aufgerufene App nutzt daraufhin diese History, um sich

selbst zu positionieren.

Dieses App-Store-Konzept sichert, trotz der Vielfalt der Oberflä-

chen-Technologien, eine einheitliche Sicht durch ein

virtuelles Portal. Dieses manifestiert sich als Home-Anwendung

auf den unterschiedlichen Devices und beachtet die Parameter

des Device Managements im App Store. Als Folge werden etwa

JavaFX-basierende Applikationen auf dem Homescreen bei Tab-

lets nicht angeboten und umgekehrt werden auf dem Desktop

keine Apps angeboten, deren

Anwendung auf den Sensoren der spezifischen Devices

beruhen. Neue Applikationen, die die Sensorik der Devices nut-

zen, passen ebenfalls in das Schema, solange eine

Registrierung im App Store möglich ist. Dies schränkt die

Einbindung zukünftiger Technologien aus unserer Sicht

derzeit nicht ein.

Fallstudien – Überblick

Fallstudie 1: Wachstumssicherung mittels API Management

Diese Fallstudie beschreibt eine Applikationsmodernisierung,

die zum Ziel hatte, durch eine skalierbare Architektur den ge-

planten 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üh-

renden Anbieter von Bonusprogrammen. Über 500 Partnerun-

ternehmen übermitteln ihre Verkäufe an das Unternehmen

und die Verwaltung der Bonuspunkte erfolgt durch eine zentra-

le IT-Plattform.

Im Rahmen einer Wachstumsstrategie wollte man zum einen

durch intensivierten Vertrieb mehr Partnerunternehmen aus

den bestehenden Marktsegmenten für das Bonusprogramm

gewinnen. Zum anderen sollten durch neue Marktsegmente

Umsatzsteigerungen erzielt werden.

Die bestehende Lösung war den zukünftigen Anforderungen

nicht gewachsen, weder im Hinblick auf die notwendige Perfor-

mance des Volumens an zukünftig prognostizierte Transaktio-

nen, noch für die interne Verbesserung des recht aufwendigen

Onboardings für neue Partner und dem Service für bestehende

Partner. Durch den Einsatz geeigneter IT-System und Automati-

sierung, sollte versucht werden, die bestehende Mitarbeiteran-

zahl nur unwesentlich zu erhöhen.

Lösungsansatz

Der differenzierende Faktor bei Bonusprogrammen wird mehr

und mehr zum „ease -of-use“ für die beteiligten externen Partner.

Die eigentlichen Programme und die Angebote

beginnen sich anzugleichen und als Differenzierung treten nun

die geringeren Interaktionskosten in den Vordergrund.

Fall-studie

Branche Unternehmen Funk-tionalität

Treiber

FS1 Bonuspro-gramme

Inter-nationales Handelshaus

ERP Wachstum, Time-to- Market

FS2 Strecken-geschäft

Europäisches Handelshaus

CX Applica-tions

Wachstum, Digitalisie-rung

FS3 Diskrete Fertigung

Automotive, Konzern

MES Industrie 4.0, Prozess-effizienz

FS4 Call-center

Handel ERP Kunden-bindung, Prozess-effizienz

Steckbrief des Unternehmens

Gründung 1990

Tätigkeitsfeld Bonusprogramme

Branche Handel

Firmenstruktur Konzerntochter; GmbH

Umsatz n.a.

Mitarbeiter Ca. 300



Big-Data-Ansätze bzw. die Bon-Analyse spielten als Differenzie-

rung eine geringe Rolle, da diese Analysen durch die

Systeme des externen Partners oder durch dessen Cloud-

Lösungen erfolgen.

Die Leistungen des Bonusprogramms müssen transparent

durch die externen Partner in ihre IT-Welt implementierbar sein

und gleichzeitig den vollen Funktionsumfang besitzen. Diese

Entwicklung ließ sich auch im vorliegenden Fall

aufzeigen. Die Batch-Welt mit den SFTP-Ansätzen des Daten-

austausches nimmt kontinuierlich ab und die Online-

Verarbeitung mit REST-API wächst kontinuierlich.

Die Herausforderung für den Lösungsansatz war nun die Um-

stellung einer eher auf Batch-Verarbeitung aus-gerichteten Sys-

temarchitektur auf den zukünftigen Schwerpunkt desReal-time-

Zugriffs der externen Partner auf die Geschäfts-logik des Anbie-

ters des Bonusprogramms.

Abbildung 4 beschreibt die gewählte Zielarchitektur.

Abbildung 4: Zielarchitektur für eine extern nutzbare

API-Plattform

Der Plan war, die bestehende Kommunikations- und

Integrationsplattform grundlegend zu überarbeiten, um den

Anforderungen der zukünftigen Geschäftsentwicklung

begegnen zu können. Grundlegende Herausforderungen lagen

im Bereich der Sicherheitsanforderungen durch die Zugriffe

von externen Partnern sowie in der Flexibilität zukünftiger

neuer Partner, die schneller, kostengünstiger, aber auch

transparent, in einem Self-Service-Ansatz auf die Plattform

ziehen sollen. Hieraus folgt sofort die weitergehende

Anforderung der Prozesssicherheit und Skalierbarkeit für den

Durchsatz sowie der Verfügbarkeit des Systems bei einem

steigenden Online-Transaktionsaufkommen. Man erwartet eine

Verdopplung des Transaktionsaufkommens auf ca. 16 Mio. TX

pro Tag.

Seitens der IT-Architektur war die Herausforderung zum einen,

die QoS (Quality of Service) und die Stabilität zu sichern. Dabei

sollte gleichzeitig die Möglichkeit bestehen, Skaleneffekte zu

nutzen, um manuelle Interaktion weitestgehend zu vermeiden

bzw. diese nur auf den umfassenden, aber leichtgewichtigen

Onboarding-Prozess eines neuen Partners zu beschränken.

Herausheben lassen sich die folgenden Eigenschaften, die der

neuen Plattform ein Alleinstellungsmerkmal verschaffen sollten:

■ Zuverlässigkeit und Prozesssicherheit in der Skalierung bei

wachsendem Geschäftsmodell

■ Höchstmögliche Automatisierung zur Reduktion der

manuellen Interaktion

■ Schnelle, transparente Prozesse für das Onboarding neuer

Partner

■ Erweiterte Betrugsprävention und Revisionssicherheit

Der Lösungsansatz war, eine Delivery-Schicht in der DMZ, auf-

zubauen, welche die, oft individualisierten REST-Aufrufe der

Partner auf ein einheitliches kanonisches Datenmodell

transformiert, die Private-Key-Verschlüsselung unterstützt und

eine erste, sehr schnelle, Betrugsprävention durchführt (siehe

Abbildung 4).

Lessons Learned

BPEL versus Eventmanagement: Die Anforderungen an

Revisionssicherheit, Restart und Recovery und der Wunsch

nach einem Monitoring bzw. einer Near Real-time-

Statusverfolgung legten den Einsatz von BPEL oder einer allge-

meinen Process Engine nahe. Performancetests zeigten jedoch

sehr schnell, dass der Overhead einer Process Engine

zugunsten einer Event-getriebenen Lösung verändert werden

musste.

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.

Geschäftstreiber

Effizienz Früherkennung von Problemen bei Geschäfts-partnern

Compliance Erweiterte Betrugsprävention und Revisions-sicherheit

Flexibilität Automatisierung des Onboardings neuer Partner und der Serviceleistungen

Effektivität Schnellere Reaktionsfähigkeit auf Anforderungen neuer Marktsegmente



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.


Das Unternehmen ist einer der führenden Dienstleister zur

Sicherung der Logistik durch ein Streckengeschäft und

erweiterte Dienstleistungen.

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 wan-

delt sich derzeit erheblich, neue Wettbewerber drängen auf

den Markt und die Kunden verlangen nach erweiterten Angebo-

ten. Die Applikationslandschaft stand daher auf dem Prüfstand.

In einer Studie erhob man die bestehenden und neu geforder-

ten Business Capabilities und bewertete sie bezüglich der IT-

Unterstützung.

Hieraus ergab sich die Leitlinie „Design for Change“, und die

Flexibilität der neuen Architektur zeigte sich als wesentlicher

Treiber einer neuen Ausgestaltung.

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 Kun-

denzufriedenheit sollte das grundlegende Geschäftsmodell des

Streckengeschäfts absichern und die Dienste des Unterneh-

mens 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.

Lösungsansatz

Die bestehende Applikationslandschaft ist auf Batch

Processing ausgelegt. Die Analyse der Business Capabilities mit

den Fachbereichen zeigte jedoch die Notwendigkeit einer Near

Real-Interaktion mit den Kunden auf. Dies war letztlich der we-

sentliche Treiber und Ausgangspunkt für eine Applikationsmo-

dernisierung und die Entwicklung einer Strategie für die zukünf-

tige Applikationslandschaft. Die Aufgabe lag in der Transforma-

tion der Batch-Schnittstellen auf Webservices mit einer SOA-

Schicht im Enterprise Service Bus.

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

entsprechenden Erweiterung um GPS-und Sensor-Daten der

Fahrzeuge. Abbildung 5 beschreibt den Lösungsansatz für ein

Ecosystem of value.

Um die gewünschten Ziele zu erreichen, mussten im Frontend

sowohl mobile Endgeräte unterstützt als auch eine IoT-

Landschaft zur Datengewinnung in die Applikationsarchitektur

eingebracht werden. Dies entsprach im Wesentlichen der

Enterprise-App-Welt in der Frontend Tier.

Ein weiterer Aspekt war, dass die Nutzung an externen SaaS-

Lö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 Ge-

schäftsmodelle durch die Freischaltung eigener Abwicklungs-

prozesse für Dritte (meist Startups) verfolgen möchte, wurde

ein Teil der Delivery Tier als PaaS-Lösung in einer externen Pri-

vate Cloud implementiert.

Abbildung 5: Referenzarchitektur für ein „Ecosystem of value“


Gründung 1930

Tätigkeitsfeld Streckengeschäft

Branche Dienstleister

Firmenstruktur Konzern

Umsatz > 5 Milliarden EURO

Mitarbeiter 500-1.000

Geschäftstreiber

Effizienz Automatisierung von Prozesse, Omni-Channel Fähig-keit, Tine2Market

Compliance Prozesstransparenz für Kunden

Flexibilität „Design for Change“ und IoT (Telemetrie)

Effektivität Ecosystems of value, Cloud Computing



Zu Projektbeginn wurden im Unternehmen sehr viele Daten

erhoben, aber nicht verwendet. Um mit diesen Daten die neu-

en 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-Core-System sollte

um Fast Data29) und unstrukturierte Daten erweitert werden.

Diese werden in einem Data Lake abgelegt und dann über Ana-

lytics-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 abso-

lut 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 Ent-

wicklungen 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 Manufac-

turing Execution Systeme (MES) für den Shop Floor bei der Pro-

duktion 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.


Der Konzern ist einer der führenden Produzenten von Fahrzeu-

gen. Das Vorhaben zum Re-engineering und zur Harmonisie-

rung auf dem Shop Floor wurde von der Produktions-leitung

einer Sparte getrieben und von den weltweiten

Werken unterstützt.

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 indivi-

duellen Arbeitsweisen angepasst und die Unterschiede

minimiert werden.

Gleichzeitig veränderte sich die Arbeitswelt durch Industrie- 4.0

-Ansätze bereits jetzt. Maschinen, Roboter wie auch das End-

produkt 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, teil-

weise 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 Ro-

boter in der Produktion sind rasant und somit ergeben sich

permanent neue Nutzungsmöglichkeiten. Insbesondere wer-

den 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 un-

abhängig von den Release-Zyklen des eigentlichen Backends

verfolgt werden können.

Lösungsansatz

Die Frontend-Komponenten sollten durch eine spezifische

Frontend-Serviceschicht von der Geschäftslogik der MES-

Backend-Komponenten entkoppelt werden, um den unter-

schiedlichen Entwicklungsgeschwindigkeiten und Anforderun-

gen gerecht zu werden.

Das neue MES verfolgt in seiner Architektur eine Plattformstra-

tegie durch die Entkopplung der Benutzeroberflächen vom MES

Backend über eine API-Schicht, die auf REST-Services basiert.

Die grundlegende Geschäftslogik des MES wird über Business

Services mit der nötigen fachlichen Geschäftslogik und den

unterschiedlichen aufgabenbezogenen Oberflächenkomponen-

ten angeboten und ermöglicht die Wiederverwendung und ge-

sicherte Nutzung von Diensten.


Gründung Vor 1900

Tätigkeitsfeld Produktion

Branche Automotive

Firmenstruktur Konzernsparte

Umsatz > 5 Milliarden EURO

Mitarbeiter > 10.000



Abbildung 6 zeigt die Architektur des Lösungsansatzes.

Lose Kopplung von Frontend und Backend via

REST-Schnittstellen

Das neue MES kommuniziert mit den Frontend-Komponenten

in der Regel über eine REST-Protokoll-basierende API-Schicht.

Hierbei erfolgen CRUD-Operationen(Create, Read, Update und

Delete) ausschließlich über die implementierte Geschäftslogik

des MES, die durch die APIs veröffentlicht wird. Das heißt, es

erfolgt eine lose Kopplung der Frontend-Komponenten von der

eigentlichen Verarbeitungslogik. Das war eine Designanforde-

rung, um die unterschiedlichen Geschwindigkeiten der Verän-

derung zu synchronisieren. Ein weiterer Vorteil war, das auto-

matisierte Tests über die APIs nun für eine nahezu hundertpro-

zentige Abdeckung sorgen.

Die eigentliche Steuerung und Anzeige der Informationen er-

folgt jetzt durch die Frontend-Komponenten im Sinne einer

bedarfsgerechten und transparenten Informationsbereit-

stellung. Dies eröffnet die Möglichkeit, auch auf Daten aus an-

deren Systemen (auch verteilten, werksübergreifenden

Systemen) zuzugreifen oder spezifische optimierte Datenstruk-

turen für das Frontend zu verwenden.

Abbildung 6: Applikationsarchitektur für ein

Industrie-4.0-fähiges MES

Eine Ausnahme bilden teilweise Leitstände mit einer Real-time-

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 Datenbestand

des MES-Backends.

Aufgabenorientierte Apps statt unflexibler Monolithen Die

Frontend-Komponenten betrachteten wir als Apps und sahen

beim Design kleine aufgabenbezogene und bedarfs-gerechte

Applikationen vor. Diese werden, ähnlich den

bekannten Smartphone Apps, über einen werksübergreifenden

App Store verwaltet und in einem leichtgewichtigen

virtuellen Portal, je nach Rechten und Geräteart, angezeigt. Vorbild

waren die Anwendungslandschaften der App-Stores. Explizit

war hier keine Portal-Lösung im klassischen Sinne angedacht,

da dann eine Einschränkung bei der Darstellung erfolgt und das

Portal selbst zum Engpass bei der Funktio

nalität geworden wäre.

Events im Mittelpunkt mit Tasklisten und Anwendungskon-

text

Grundlegend verändert hat sich die Philosophie der Steuerung

durch den „Werker“. War diese in der Vergangenheit geprägt

durch starre Prozesse, so verändert sich die Arbeitsweise nun

in Richtung eines eventorientierten Ansatzes mit einer Taskliste

für Eskalationen und Meldungen und weg von einem Workflow-

Ansatz mit vordefinierten Aktivitäten.

Aus einem Eintrag der Taskliste öffnet das System durch Inter-

pretation des Kontextes automatisch die entsprechende App,

um die Aufgaben zu lösen. Das Konzept ähnelt der

Dateipräferenz von Betriebssystemen. Die App kennt die Mel-

dungstypen und die Apps, die diese verarbeiten können. Um-

fangreiche „Expertenoberflächen“ sind jetzt kaum mehr von

Nöten, sondern das Design der Oberflächen bietet vor allem

transparente, selbsterklärende Oberflächen für

bestimmte Arbeitsschritte.

Die Lösungsansätze wurden in konkreten User Journeys und

PoCs mit dem Kunden verifiziert und gegen die System-

architektur 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 Geschwindigkei-

ten“ zu erreichen. Das Ergebnis waren eine fehlerfreie, eher planba-

re und an der Robotik ausgerichtete Entwicklung des MES Ba-

ckends mit schnellen Releasezyklen und an den Bedarf ausge-

richteten Oberflächen für die Werker.

Lessons Learned

Data Streaming

Unser erster Ansatz vernachlässigte das Data Streaming der

Maschinen. Zum einen als Rohstoff für Analysen und

Predictive-Maintenance-Ansätze und zum anderen für die event

und Message-getriebene SPS-Steuerung des

Maschinenparks.

Geschäftstreiber

Effizienz Reduktion Prozesskosten, Eskalationsmgmt. verbes-sern Schwarmintelligenz auf Shop-Floor, Mobiles Arbeiten ermöglichen

Compliance –

Flexibilität Innovationsgeschwindigkeit erhöhen

Effektivität Chancen des Industrie 4.0 ergreifen, werksübergrei-fende Harmonisierung, Muster von Schwachstellen erkennen



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 ausrei-

chend 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 An-

satz zukünftig aufgreifen und mit den Ansätzen des

Impact-Mappings32) zusammenführen.

Fallstudie 4: Flexibilisierung der Standard-software

Diese Fallstudie betrachtet zwei sehr ähnliche Projekte, bei de-

nen es in zwei unterschiedlichen Unternehmen und

Branchen zu ähnlichen Lösungsansätzen bei der Applika-

tionsarchitektur gekommen ist.


Das erste Unternehmen befindet sich in einem hart umkämpf-

ten Marktumfeld, dass sich rapide ändert. Die

Bestandssoftware für sein Callcenter war in die Jahre gekom-

men, entsprach nicht mehr den Ansprüchen der User an

moderne Benutzeroberflächen und musste daher

modernisiert werden.

Die Herausforderung war dabei der Spagat zwischen der star-

ken 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 Sachbear-

beitung über eine attraktive Web-Anwendung auf den

Kunden zu verlagern. Beide Parteien sollten von dieser

Lösung profitieren: Der Kunde erhält einen 24/7-Service, wäh-

rend das Unternehmen Personal in der Sachbearbeitung ein-

sparen bzw. dieses für neue Geschäftsfelder einsetzen kann.

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 Mitar-

beitern 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.

Generell fiel uns auf, dass sich die Anforderungen an das Front-

end schneller änderten als die Anforderungen im Backend. Bei

der Benutzeroberfläche lohnt es sich, flexibel auf neue Anforde-

rungen und Ideen reagieren zu können. Die Kerngeschäftspro-

zesse hingegen sind unternehmenskritisch und jede Änderung

will gut überlegt sein.

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.

Ein klassisches Beispiel ist die Adressverwaltung in SAP.

Kontaktdaten wie Anschrift, Telefonnummer und E-Mail-

Adresse sind in den meisten Anwendungen einfache

Eingabefelder in einer Maske. Im Backend werden sie in

einer komplexen Datenstruktur gespeichert. Die entsprechen-

de Schnittstelle wurde dem Client-Projekt ursprünglich unver-

ändert als Webservice bereitgestellt. Das Ergebnis war, dass es

einige Wochen dauerte, das Laden und Speichern der Kontakt-

daten zu implementieren.

Steckbrief der Unternehmen

Gründung 1912 bzw. 1949

Tätigkeitsfeld Callcenter bzw. Internetauftritt

Branche Energieversorgung / Finanzdienstleistun-gen

Firmenstruktur GmbH

Umsatz n. a.

Mitarbeiter Ca. 1.200-2.500



Nach dieser Erfahrung änderte das Projektteam seine

Strategie. Zum einen wurden auf der Backend-Seite

dedizierte Services für die jeweilige Aufgabe angefordert.

Das hatte mehrere Vorteile:

■ Das fachliche und technische Know-how über die

Besonderheiten des Backend-Systems ist auf Backend-Seite

vorhanden, während es auf Frontendseite erst

aufgebaut werden muss.

■ Es besteht die Chance, Daten bereits an der Quelle zu

aggregieren. Dadurch verbessert sich die Performance, und

die Angriffsfläche für Hacker wird kleiner.

■ Die Erfahrung zeigte, dass es in vielen Fällen einfacher und

billiger ist, SAP Services in wenigen Zeilen ABAP-Code zu

komponieren, als dies auf der Client-Seite zu versuchen. Das

gilt insbesondere dann, wenn Webservices verwendet wer-

den. Webservices erzeugen eine große Menge Boilerplate-

Code33), und die meisten Webservice Tools erzeugen unter-

schiedliche Klassen für identische SAP-Datenstrukturen. Das

Wissen, dass es sich um ein und dieselbe Datenstruktur

handelt, geht im Webservice verloren. Das Ergebnis sind

arbeitsintensive und fehlerträchtige Konsolidierungsmaß-

nahmen der Entwickler.

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 Stan-

dardsoftwareprodukte gibt, die eine individuelle Anpassung der

Schnittstelle nicht vorsehen. Um dem Client in diesem Fall trotz-

dem 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 Men-

ge Flexibilität. Auch Änderungen der Schnittstelle auf dem Ba-

ckend 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.

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. Beispiels-

weise aus organisatorischen Gründen: Niemand kennt das Ba-

ckend 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.

Lessons Learned

Starre BPM-Prozesse nicht immer hilfreich

Aus strategischen Überlegungen heraus wurden die Prozesse

in beiden Fällen mit BPM modelliert und ausgeführt. Rück-

blickend betrachtet hatte dieser Ansatz nicht nur Vorteile. Eine

der Gefahren war es, BPM für alles einsetzen zu wollen. Es gibt

aber in jedem Unternehmen auch Abläufe, die nicht standardi-

siert werden können, deren Modellierung vergessen wurde

oder die nicht modelliert werden konnten, weil die entspre-

chenden Anforderungen erst später entstehen. In diesen Fällen

ist es wichtig, dass die Software auch ohne

einen starren, vordefinierten BPM-Prozess verwendet werden

kann oder dass die Prozesse flexibel genug sind, auch unvor-

hergesehene Abläufe abbilden zu können34).

Bei der Toolauswahl gilt es zu beachten, dass es leicht-

gewichtige und schwergewichtige BPM-Engines gibt. Hier kann

man keine generelle Empfehlung aussprechen: Beide Engines

haben in unterschiedlichen Einsatzszenarien ihre Existenzbe-

rechtigung. Es lohnt sich, zu Projektbeginn eine Evaluierungs-

phase einzuplanen, um die passende BPM-Engine auszuwäh-

len. Oder zu prüfen, ob überhaupt eine BPM-Engine benötigt

wird. Die Einführung eines BPM-Systems ist eine weitere Abs-

traktionsebene. In den meisten Fällen führt das dazu, dass sich

Mitarbeiter auf das BPM-System spezialisieren. Das wird auch

im Architekturmodell deutlich: BPM ist eine weitere Schicht.

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 Prozessmo-

dells. In der Praxis kristallisieren sich bei diesem Ansatz wieder

Prozesse heraus – aber diese Prozesse können jederzeit flexi-

bel geändert werden.

Projektlaufzeit: Eines der beiden Projekte dauerte mehr als

fünf Jahre. Damit wurde ein Problem deutlich, dass sonst ei-

gentlich erst in der Wartungsphase auffällt: Die Architektur

muss flexibel sein. Die Anforderungen, die wir heute um-setzen,

fallen in fünf Jahren möglicherweise weg, werden durch andere

Anforderungen ersetzt oder sie werden im Laufe der Zeit aus-

differenziert. Ihre Anwendungsentwickler müssen mit dieser

Situation umgehen können. Dafür 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 veral-

tet 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 ver-

stehen sind und unabhängig voneinander gewartet und weiter-

entwickelt werden können. Die Kunst dabei ist es, die Microser-

vices trotzdem so zu verzahnen, dass sie aus Anwendersicht

eine zusammenhängende Anwendung bilden. Eine Herausfor-

derung des Microservice-Ansatzes ist die Vermehrung der

Schnittstellen und deren Governance.

Ganzheitliches Denken der Fachbereiche

Eine der wichtigsten Erkenntnisse aus diesen Projekten war,

dass die Auftraggeber selbst keine Modularisierung wollten,

dies war allein der Wunsch der IT. Der Fachbereich hingegen

dachte ganzheitlich: Er will seine Aufgabe möglichst einfach und

effizient lösen. Idealerweise braucht er dafür nur ein Werkzeug.

Das beißt sich natürlich mit dem Wunsch der IT, durch kleine

und handliche Microservices Flexibilität und Wartungsfreund-

lichkeit herzustellen. Die Herausforderung beim Entwurf einer

flexiblen, zukunftssicheren Architektur ist es also, ein aus Mo-

dulen bestehendes System zu bauen, das die ganzheitliche

Denk- und Arbeitsweise der Anwender unterstützt. Im Laufe

der Projekte haben wir dafür das Konzept der Enterprise App

mit einem Enterprise App Store und der

Kontextübergabe zwischen verschiedenen Apps entwickelt, wie

oben beschrieben.

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. Grundla-

ge beim Zukauf einer Standardlösung muss allerdings sein,

dass durch eine Veränderung35) des Standardprodukts Proble-

me, wie diese ausgeschlossen sind:

■ Die Releasefähigkeit wird in keiner Weise eingeschränkt.

■ Es entstehen keine risikoreichen Migrationsprojekte.

■ Die Releasefähigkeit anderer Systeme wird nicht

beeinträchtigt.

Wir sehen drei sinnvolle Ansätze, um externe Kaufsysteme in

die Applikationslandschaft einzubeziehen. Abbildung 7 stellt

diese dar.

Alternative 1: Buy als Self-Contained Application

Aus Deployment-Sicht stellt die Einbindung von Self-Contained

Applications36) eine sinnvollen Alternative dar, da das erworbe-

ne System weitestgehend unabhängig von der bestehenden

Applikationslandschaft verändert werden kann. Die verwende-

ten Interfaces sind das sogenannte „Nadelöhr“. Sollten sich die

Abbildung 7: Make-and-Buy-Entscheidungen bei CAFA

Interfaces verändern müssen, so müssen die Business Services

der Service Tier verändert werden. Diese Entscheidung liegt

jedoch in der Hand des jeweiligen Unternehmens. Schwieriger

in Bezug auf Governance und Terminplanung ist der Impact

einer notwendigen Veränderung der Serviceschicht, die das

Standardprodukt nachvollziehen sollte. Hier hängt viel von den

Verträgen mit dem System-lieferanten ab.

Ein weiterer Nachteil liegt in der Schwierigkeit, die Funktionalität

des Standardprodukts über die Business-Service-Schicht mögli-

chen Frontend-Komponenten über die APIs anzubieten.

Alternative 2: Buy als Plattformkomponente

Bei dieser Variante, die im Grunde der Spezialfall einer

Einschränkung von Alternative 1 ist, stellt sich die Standard-

Lö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 Front-

end-Systeme und Business Services konsumiert werden kön-

nen. Diese aufgesetzten Lösungen sollten wiederum

Self-Contained Applications sein.

Der Vorteil dieses Ansatzes liegt in der Möglichkeit, das

System flexibel in die Frontend-Entwicklung einzubinden.

Alternative 3: Buy einer Oberflächenkomponente

In diesem Fall erwirbt man eine Oberflächenkomponente, die

durch Nutzung der eigenen Business Services oder API

Interfaces eine kundenspezifische und somit erweiterte Ober-

flächenfunktionalität bereitstellen kann.

Diese Variante ist eine gute Grundlage für die Nutzung der ei-

genen Applikationsplattform durch Dritte.



Organisatorische Implikationen

Die vorgestellte agile Applikationsarchitektur unterstützt

Ansätze zur Implementierung einer „IT der zwei Geschwindig-

keiten“, auch Bimodale-IT37) genannt. Die Entkopplung der Front-

ends ermöglicht Lean-Startup-Ansätze für Innovationen oder

die Verwendung von agilen Methoden wie Scrum, um mit Fach-

bereichen gemeinsam bedarfsgerechte Lösungen zu erstellen.

Die Entkopplung und die weitestgehende

Unabhängigkeit der Oberflächenkomponenten, die wir als

Enterprise Apps bezeichnet haben, ermöglicht unabhängige

und schnelle Releasezyklen für eine schnelles Time-to-Market

von neuen Ideen.

Der Backend-Bereich einschließlich der robusten und

gesicherten Business Services, (in Abbildung 8 unterhalb der

gestrichelten gelben Linie dargestellt) wird sich in wohl-

definierten, planbaren Zyklen verändern. Hier steht die

Business Continuity im Vordergrund und der Slogan

„Make no mistakes“ soll das hier durchaus angebrachte

Sicherheitsstreben unterstreichen.

Abbildung 8: Implizite Unterstützung von Ansätzen

einer bimodalen IT

Die gewählte Architektur ist auf Veränderung ausgelegt und

unterstützt unterschiedliche Geschwindigkeiten beim Deploy-

ment von neuen Versionen. Darüber hinaus gibt es im klassi-

schen Sinne keinen einheitlichen Releasestand mehr. Fast alle

Komponenten sind unabhängig voneinander

veränderbar. Die Oberflächen mit den Apps sind individuell

releasefähig und eine Absprache ist nur notwendig, wenn APIs

und somit implizit Geschäftslogik verändert werden muss. Die

Oberflächen werden sich erfahrungsgemäß

permanent verändern und können über agile Ansätze in

engerer Zusammenarbeit mit den Stakeholdern optimiert wer-

den.

Der Rechenkern des Backends wird sich langsam und kontrol-

liert verändern. Da jeder Störfall teuer ist, steht hier das Motto

„Make no mistakes“ im Vordergrund. Fehler beim Frontend

wirken sich nicht auf das Backend aus, da die all-gemeingültige

Geschäftslogik, die von den APIs aufgerufen wird, die Fehler

abfängt.

Governance

Der vielleicht wichtigste organisatorische Punkt ist die Imple-

mentierung einer leichtgewichtigen Governance für die Platt-

form selbst. Die IT-Organisation muss sich auf eine solche

Governance einstellen und das gesamte Frontend einschließ-

lich Backend als „eine“ Plattform verwalten und nicht als

Projekte oder eine Sammlung von Systemen. Andernfalls

besteht die Gefahr, dass die Organisation das agile Gebilde der

Enterprise Apps über das Portfoliomanagement

schleichend wieder als eine Einheit sieht und somit der

Langsamste gewinnt.

Eine solche Governance muss die Technologievielfalt einschrän-

ken, ohne die Vorteile von neuen Technologien für den Anwen-

der aus den Augen zu verlieren. Ferner muss die Governance

nun als neue Facette erreichen, dass Aspekte wie die Geschwin-

digkeit der Oberflächenveränderung und Veränderungen durch

den Zukauf von Standard-komponenten die Plattform selbst

nicht kompromittieren.

Chancen & Risiken

Bisher sind wir mehr auf die Vorteile der flexiblen Enterprise-

Apps-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

auf möglichen Risiken aber auch auf Benefits und Chancen der

vorgestellten „Designed for Change“-basierenden CAFA zu spre-

chen kommen.

Chancen

Unabhängigkeit: Durch die Architektur können

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.

Standardkomponenten: Die Chance besteht darin,

passende Standardsoftware und Standardkomponenten zu

nutzen, falls diese die API-Schicht als Client oder als Server

unterstützen.



Aufgabenspezifische Apps: Bedarfsgerechte und

aufgabenspezifische Apps steigern die Effizienz der Benutzer

und unterstützen eine kundenzentrische Sichtweise.

Einfachheit: Die Frontends der Apps sind bedarfs- und

aufgabengerecht und müssen somit selbsterklärend sein.

Akzeptanz: Hohe Akzeptanz der Anwender durch

Outside-in-Design und spezifische Oberflächen, die

zur Problemlösung bei einer bestimmten Aufgabe entwickelt

wurden.

Innovation: Die Unabhängigkeit der Releasezyklen wirkt sich

positiv auf Innovationen aus, da Änderungen und auch neue

Apps das Verhalten der bestehenden Apps nicht berühren.

Risiken

Neben den typischen Projektrisiken liegt die wesentliche

Gefahr in einem schleichenden Kompromittieren der

Architekturmuster des CAFA. Die Governance muss in der Lage

sein, das Muster des „Designed for Change“ in ihren

Entscheidungsprozessen zu übernehmen und hierbei die un-

terschiedlichen Geschwindigkeiten, Vorgehensmodelle und

Methoden einzubeziehen.

Steigende Wartungskosten: Das Konzept ermöglicht einen

Wildwuchs an (spannenden) Technologien. In der Folge können

sich die Wartungskosten negativ entwickeln38).

Governance: Eine Governance muss implementiert werden, um

den möglichen technologischen Wildwuchs auf ein sinnvolles

Maß einzuschränken.

Zu enge Kopplung: Durch eine zu enge Kopplung der API-

Schicht inklusive der fachlichen Logik des Backends mit den

benötigten Funktionalitäten der unterschiedlichen Apps be-

steht das Risiko, dass die API-Schicht zu einem Nadelöhr wird.

Hier muss man aus den Erfahrungen der umfassenden SOA-

Factory-Ansätze lernen und den Apps einen Freiraum bieten.

Governance: Designvorgaben/Patterns müssen entwickelt werden,

um Leitlinien und Ansatzpunkte für Entscheidungen zu bekom-

men. 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

wie möglich“ auf „so wenig wie nötig“.

Fehlschlagrisiko

Das Enterprise-App-Store-Konzept wie auch die CAFA sind neu-

artig und erst jetzt entstehen punktuell Lösungen, die diese

Konzepte aufgreifen. Bestehende Forschungsansätze und Best

Practices zum Common Plattform Development sollten hier

einbezogen werden.

Machbarkeit: Über PoCs und produktive Pilot-Installationen soll-

te man die neuen Konzepte in eingeschränkten

operativen Umgebungen eingehend prüfen.

Zusammenfassung

Viele aktuelle Anfragen unserer Kunden beziehen sich auf inno-

vative Ansätze zur Modernisierung ihrer Applikationslandschaft

und gleichzeitig auf die Fragestellung, wie man die notwendige

Flexibilität für die Anforderungen der Digitalisierung erreichen

kann.

Mit der vorgestellten Referenzarchitektur CAFA haben wir Ihnen

einen Ansatz präsentiert, den wir aktuell bei unseren Architek-

turberatungen zur Applikationsstrategie empfehlen. Die vorge-

stellten Fallstudien haben gezeigt, dass die Verwendung des

Blueprint nicht 1:1 erfolgt, aber die Kernidee des Designed for

Change und somit die konsequente Entkopplung der Frontends

vom Backend spiegeln sich letztendlich in

allen Lösungen wider.

Insbesondere bei der Entwicklung einer Roadmap für ein Trans-

formationsvorhaben von einer Legacy-Landschaft auf eine fle-

xible Applikationslandschaft dient der vorgestellte Blueprint als

Zielarchitektur.

Die grundlegenden Vorteile entstehen durch die konse-quente

Entkopplung der Frontends mit einer hohen

Änderungsrate von den nach Stabilität strebenden Backend-

Systemen. Jedoch besteht die Lösung nicht aus zwei separaten

Frontend– und Backend-Monolithen, sondern angestrebt sind

kleinere und in sich releasefähige Systeme in Front– und Ba-

ckend. Hier sollten auch die aktuellen Ansätze ROCA und

Microservice-Architekturen einbezogen werden.

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 Anwen-

der, an Bedeutung zu gewinnen.



Ein weiterer Vorteil der vorgestellten CAFA ist die Möglichkeit,

eine Enterprise-App-zentrische Architektur zu implemen-tieren.

Gerade bei den aktuellen Fragestellungen der Digitalisierung

und des Internet der Dinge bietet sich der

vorgestellte CAFA-Ansatz an.

Aktuell beschäftigen wir uns in diesem Zusammenhang

zum einen intensiv mit der Optimierung der Delivery Tier mit-

tels Backend-for-Frontend-Konzepten40), um die Frontends opti-

mal mit Objekten zu versorgen und zum anderen mit der An-

passung von methodischen Ansätzen aus dem Enterprise Ar-

chitecture Management, um die funktionalen Anforderungen,

auch für die Bedürfnisse der Endanwender, über

Business Capabilities41) zu erfassen.

„One size fits all“ oder rigide Harmonisierungs- und Standardisie-

rungsinitiativen torpedieren den „Designed for Change“-Ansatz

des CAFA. Andererseits sind Lean-Startup-Ansätze und teilweil-

weise agile Methoden nicht unbedingt ziel-führend bei der Ent-

wicklung stabiler Backend-Systeme. Wie so oft sind Ausgewo-

genheit und bedarfsgerechtes

Vorgehen entscheidend. Hier greift die geschilderte

Governance für die Plattform ein.

Insbesondere die weitere Differenzierung der Endgeräte in den

kommenden Jahren erfordert eine flexible Architektur, um die

neuen Gerätetypen zu unterstützen und einen multi-modalen

Zugriff auf die Backend-Systeme zu ermöglichen. Einen Vor-

schlag, 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 brei-

te kontextabhängige Gerätenutzung auf Frontend-

Architekturen haben wird. Wie unsere Fallstudien zeigen, waren

unsere ersten Erfahrungen bislang durchweg positiv.

Der Druck zur Digitalisierung der bestehenden Geschäfts-

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ähigkeit

der IT zu erhöhen und somit implizit auch die

Wettbewerbsfähigkeit der Unternehmen zu sichern.

Anmerkungen & Quellen

1) Lünendonk Whitepaper „Software-Modernisierung“, Lü-

nendonk, 2015

2) http://android-developers.blogspot.de/2016/05/android-

instant-apps-evolving-apps.html

3) http://smallbusiness.chron.com/microsoft-pwa-

33554.html

4) https://www.microsoft.com/microsoft-hololens/en-us

5) Bernhardt, Sven: “Microservices architecture – thoughts

from a SOA perspective”, SOA Magazine, 2014

6) 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 Be-

lieben 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.

7) Omni Channel bedeutet die Verallgemeinerung der Multi

-Channel-Ansätze bei der Benutzerinteraktion und for-

dert, dass alle verfügbaren und genutzten Interaktions-

möglichkeiten auch im Geschäftsmodell beachtet wer-

den.

8) TDWI Europe (Hg.): „Big Data – Ein Überblick“, dpunkt-

Verlag, 2016

9) http://blogs.forrester.com/nigel_fenwick/14-03-20-

the_future_of_business_is_digital

10) https://www.mulesoft.com/resources/esb/hybrid-cloud-

integration-solutions

11) 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

12) http://blogs.forrester.com/ted_schadler/13-11-20-

mobile_needs_a_four_tier_engagement_platform

13) https://docs.oracle.com/cd/E18727_01/doc.121/e12064/

T291171T509870.htm

14) http://www.sigs-datacom.de/fachzeitschriften/

objektspektrum/archiv/artikelansicht/artikel-titel/

frontend-architekturen-fuer-microservice-basierte-

systeme.html

15) Ein weiterer Aspekt ist die Möglichkeit Digital Labs oder

Lean-Startup-Ansätze bei der Entwicklung bzw. Verpro-

bung von Ideen einzuführen, etwa im Rahmen einer

digitalen IT-Strategie.

16) http://searchcloudapplications.techtarget.com/

definition/API-management

17) Constrained Application Protocol,

http://coap.technology/

18) Message Queue Telemetry Transport

http://mqtt.org/

19) http://www.theaugmentedreality.de/

20) http://www.trading212.com/

21) http://dbs.uni-leipzig.de/html/seminararbeiten/

semSS98/arbeit5/dwdm-vortrag5-11.html

22) https://www-01.ibm.com/software/data/infosphere/

hadoop/mapreduce/

23) https://www.myo.com/



24) http://www.e-commerce-magazin.de/effizient-durch-

omni-channel

25) Aus heutiger Sicht könnte man auch von einem Tablet-

First Approach sprechen (http://

blog.springstudio.com/2015/04/09/tabletfirst/)

26) Adaptive Case Management (bpmpractice.de/wp-

content/uploads/2013/10/ACM-V4.06.pdf)

27) https://developer.android.com/reference/android/

content/Intent.html

28) https://www.mulesoft.com/resources/cloudhub/ipaas-

integration-platform-as-a-service

29) http://www.oracle.com/us/solutions/fastdata/index.html

30) https://www.bosch-si.com/ads/iot-technology-de/

index.html?gclid=CPSyi8SemswCFY4y0wodE7oOJQ

31) http://www.businessmodelcreativity.net/user-customer-

journey-mapping/

32) https://www.impactmapping.org/

33) https://en.wikipedia.org/wiki/Boilerplate_code

34) 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-Oracle-ebook/dp/

B00ZPJWBL2/ref=sr_1_1?

ie=UTF8&qid=1465491270&sr=8-

1&keywords=winterberg+design.

35) 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.

36) http://scs-architecture.org/

37) http://www.gartner.com/it-glossary/bimodal/

38) An dieser Stelle können wir von der Open-Source-

Gemeinde des Github lernen und unternehmens-intern

bereichsübergreifende eigene Open Source und Social

Coding Communities aufbauen!

39) http://roca-style.org/

40) https://www.thoughtworks.com/de/radar/techniques/bff-

backend-for-frontends

41) http://searchsoa.techtarget.com/definition/business-

capability

Ü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 Deutsch-

land und die OPITZ CONSULTING Polska Sp. z.o.o. drei Standor-

te 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 Unterneh-

men 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.


https://www.amazon.de/Design-Principles-Process-driven-Architectures-Oracle-ebook/dp/B00ZPJWBL2/ref=sr_1_1?ie=UTF8&qid=1465491270&sr=8-1&keywords=winterberg+design





http://scs-architecture.org/

Documents

Context Aware Frontend Architecture - opitz- · PDF fileWHITEPAPER „CONTEXT-AWARE FRONTEND ARCHITECTURE“ Motivation Mit zunehmendem Wettbewerbsdruck müssen Unternehmen ihre Geschäftsmodelle