Björn Müller, CaptainCasa, Business Application Forum

CaptainCasa Enterprise Client
CaptainCasa

Der „Wert“ von
Benutzeroberflächen

CaptainCasa

Szenario 1

• Back Office Anwendung, Mainframe
– Financials, Controlling, Materials Management
– 8 Entwickler, 1 Administrator
• UI Technologie
– 3270 Terminals
• ...versucht von 3270 Terminals wegzukommen.
• Gescheiterte Versuche
– HTML
– AJAX
– Zur Zeit: Evaluation von Adobe/Macromedia

CaptainCasa

Szenario 2

• Mittelständischer Softwarehersteller
– Logistik (Warehouse, Delivery Management)
– 30 Entwickler
• UI Technologie
– Fat Client
• ...sucht nach Nachfolger seines „Cash Cow
Produktes“..
• Gescheiterte Versuche
– AJAX
– ...ist nun „zurück“ mit Java-Swing-basiertem Richt Client
Framework

CaptainCasa

Gesamtsituation

• Hohe „Volatilität“ im Bereich von Technologien und
Hypes im UI Markt
• Hohe Evaluationskosten
• Hohes Risiko von Fehlentscheidungen
– Hohe Anzahl an Technologien
– Entscheidungsträger haben „emotionale Bindung“ zu
Technologie verloren
• Entwicklungseffizienz vieler Rich Client Frameworks
ist dramatisch schlecht
• Hohe Kosten durch „Warten auf Nachfolge-Cash-
Cows“

CaptainCasa

Land of Confusion

HTML/ Adobe Java
HTML Silverlight
AJAX Macromedia JavaFX

Java, J2EE,
Server Side
Hibernate, Spring
Application
WebServices, ...

Relational DBs
Database

CaptainCasa

Land of Confusion

HTML/ Adobe Java
HTML Silverlight
Dojo Swing
RichFaces Eclipse
Qooxdoo FX
GWT
RAP
Java, J2EE,
... Server Side
Hibernate, Spring
Application
... WebServices, ...

Relational DBs
Database

CaptainCasa

Land of Confusion

HTML/ Adobe Java
HTML Silverlight Hype gibt’s heute?
Welchen
Dojo Swing
RichFaces Eclipse
Qooxdoo FX
GWT Java ME
Ich bin Architekt. Mit UI
RAP
habe ich nichts zu tun.
Java, J2EE,
... Server Side
Hibernate, Spring
Application
... WebServices, ...

Relational DBs
Database

CaptainCasa

Hauptkostenersparnis

• Technologie- und Architekturfindung!

• Attribute
– langfristig
– effizient
– angemessen für Benutzer
– Hype-resistent

• Offen für „Apps“, aber klar ausgerichtet an Ihrer
„Application“

CaptainCasa

Scope = Reachability first!

• Beispiele: B2C, social networks, ...

• Frontend Technologie
– HTML/AJAX – no way 'round

• Aber
– Performance Probleme
– Cross Browser Probleme
– AJAX Framework Abhängigkeit
– Entwicklungsaufwand

CaptainCasa

Scope = WOW first!

• Beispiele: Configurators, Animations, ...
– ...wenige, aber „perfekte“ Seiten

• Frontend Technologie
– Adobe/Macromedia
– MS Silverlight
– (Java FX still verrrry young)

• Aber
– Client Entwicklungsaufwand

CaptainCasa

Scope = Enterprise Application

• Beispiele: Financials, Logistics, ... applications
– Viele Screens, komplexe Regeln, Dateneingabe

• Frontend Technologie:
– Java
– MS Silverlight
– (Adobe/Macromedia)

• Aber
– RIA Architektur ist entscheidend
für Effizienz

CaptainCasa

One UI Technology fits ALL!

• AJAX!
• Macromedia!
• HTML 5!
• Java!

CaptainCasa


• Ist es wirklich die „ONE“ Technologie?
– Macromedia „light“ <=> „heavy“ edition
– HTML-AJAX-full blown <=> HTML-plain
• Wer steht gerade, wenn es doch nicht ordentlich
läuft?
– Unter Mozilla sieht es ein wenig anders aus...
• Deckt diese wirklich Geräte-spezifische
Gegebenheiten ab?
– iPhone native <=> iPhone-HTML

CaptainCasa


• Ist die UI Technologie wirklich die adäquate für das
Herzstück Ihrer Anwendung?
– Interaktivität, Benutzerkomfort
– Entwicklungseffizienz
– Lanfristigkeit
– Möglichkeit der Kontrolle / Einflussnahme
• Zielarchitektur: Application <=> „App“
– Stabile Application Architektur
– Möglichkeit - „Apps“ mit vertretbarem Aufwand
anzudocken

CaptainCasa

ONE UI Technology fits ALL!

• Mischformen sind realistisch(er)

Rich Client UI iPhone
Java Swing Based Shop
Thin
Apps

Logic
Rules
...

Data

CaptainCasa

What typically happens...

Explicitly coded
Frontend
Program

Web Services, „BAPI“s

Server Logic

CaptainCasa

Folge

• Hohe Kosten im Bereich von
Enterprise Applications
– Sowohl Frontend als auch Backend
Expertise
– Viiiiiiele Interfaces (Pflege, Security,
Explicitly coded
Roundtrips)
Frontend
Program – Frontend Entwicklungs ist „weit weg“
von Backend Entwicklung
Web Services, „BAPI“s
– Roundtripverhalten ist kritisch
Server Logic
– Immer „dickere“ Clients; hohe
Frequenz der Auslieferung der Clients

CaptainCasa

Thin Client Architecture

Rendering HTML
Engine Terminal
Browser

character http/
stream HTML

Server Side App Server Side App

Interaction Interaction
Application Processing Processing
Server
Application Application
Logic Logic

CaptainCasa


Rendering HTML
Engine Terminal
Thin & Poor Thin & Poor
Browser

character http/
stream HTML

Server Side App Server Side App

Interaction Interaction
Application Processing Processing
Server
Application Application
Logic Logic

CaptainCasa


Rendering Generic
HTML Frontend
Engine Terminal
Thin & Poor Thin & Poor
Browser Client

character http/ http/
stream HTML XML

Server Side App Server Side App Server Side App

Interaction Interaction Interaction
Application Processing Processing Processing
Server
Application Application Application
Logic Logic Logic

CaptainCasa


Rendering Generic
HTML Frontend
Engine Terminal
Thin & Poor Thin & Poor Thin & Rich
Browser Client

stream HTML XML


Interaction Interaction Interaction
Application Processing Processing Processing
Server
Logic Logic Logic

CaptainCasa

Folge

• Geringere Kosten im Bereich von
Enterprise Applications
– Nur Backend Expertise
– EIN Interface
– Frontend Entwicklung ist „nah dran“
Terminal
Thin & Poor
HTML
Thin & Poor
Browser
Generic
Frontend
Thin & Rich
Client
an Backend Entwicklung
– Roundtripverhalten ist klar geregelt
stream HTML XML
– Stabiler Client, kein permanenter

Interaction Interaction Interaction Rollout
Processing Processing Processing

Logic Logic Logic

CaptainCasa

Thin <=> Fat Client

• Fat Client == Client driven UI Architecture
• Thin Client == Server driven UI Architecture

• Für den Herzteil einer „Enterprise Application“ ist
die Thin Client Architektur die bessere,
kostengünstigere Wahl.

• Aber
– Einflussnahme auf Framework ist wichtig!
– Widerstand von „eingefleischten UI Entwicklern“ ist oft
zu erwarten!

CaptainCasa

FAT <> THIN

FAT
DOS Windows

HTML
Terminal Browser

THIN

CaptainCasa

FAT <> THIN

FAT
DOS Windows

Software
driven
Architecture
Hardware
driven HTML
Terminal Browser

THIN

CaptainCasa

FAT <> THIN

FAT
Fat <> Thin
DOS Windows
vs.
Rich <> Poor

Take the
Exit
To HTML
Terminal
THIN!
Browser

THIN

CaptainCasa

UI Generierung

• Von 100% Bildschirmen verdienen es nur 20%,
explizit „durchdesigned“ zu werden
• Beispiel:
– Verarbeitungsdialoge - ja!
– Stamm/Steuerdatendialoge - nein!?
– Reportingdialoge - nein!
• Für den Rest gilt:
– Bilden Sie Klassen von Dialogen
– Definieren Sie eine Meta-Beschreibung für diese Dialoge
und deren Verarbeitung
– Schaffen/Nutzen Sie eine Generierungsumgebung zur
Erstellung der Dialoge und deren Verarbeitung

CaptainCasa

UI Generierung

• Generierung <=> Generisch
– pro Generierung
● Schaffung verständlicher Programmstrukturen
● „Keine“ Laufzeitfehler
● Debug-Fähigkeit
● Einfacheres Entkoppeln in spezifische
Weiterimplementierung
– pro Generisch
● flexibleres Deployment (?)

CaptainCasa

UI Generierung

• Generierung auf Basis von
– UML
– relationalem Tabellenmodell
– XSD
– ...und (immer!): Zusatzinformationen

CaptainCasa

UI Generierung

• Generierung darf kein Blockierer für einzelne
Dialoge sein
– In diesem Fall: abkoppeln!
– Kein Einbau von „Sonderlocken“ mit einmaliger Nutzung
in das Generierungsframework.
• Generierungsframework muss beeinflussbar sein
– Es erstreckt sich typischerweise über UI und
Verarbeitungsebene.
– Aktive Community <=> Eigenerstellung

CaptainCasa

Résumée

• UI Architektur ist zentraler Teil der
Gesamtarchitektur
– Überlassen Sie UI Architekturentscheidungen nicht dem
Zufall
– Tappen Sie nicht in die Fat Client Falle
– Wählen Sie eine Thin Client Architektur im Bereich von
Enterprise Anwendungen
• Enorme Kosten entstehen durch Wahl der nicht
passenden Technologie und Architektur

CaptainCasa

Résumée

• Glauben Sie nicht an Wunder-Frameworks, die alles
können
– Wählen Sie eines aus, das den Kernteil Ihrer Anwendung
glaubwürdig abdeckt. - Beachten Sie dabei die Frage,
welchen Einfluss Sie auf das Framework haben
– Reiten Sie auf Hypes, wenn es um „Apps“ geht.
Ignorieren Sie Hypes, wenn es um Ihre „Application“
geht.
• Generieren Sie Ihre „80%“ Bildschirme und widmen
Sie sich Ihren „20%“ Bildschirmen

Björn Müller, CaptainCasa, Business Application Forum

Recommended

Recommended

More Related Content

Similar to Björn Müller, CaptainCasa, Business Application Forum

Similar to Björn Müller, CaptainCasa, Business Application Forum (20)

More from Aberla

More from Aberla (20)

Björn Müller, CaptainCasa, Business Application Forum