Super. Ja, vielen Dank. Ich schalte mal gerade
um. Zack. Wasser. Ja, läuft. Super
. Stehe ich im Bild? Ach, du drehst super
. Ja, vielen Dank. Schön, dass so viele
da sind. Meine Anreise war auch ein Abenteuer.
Ich möchte heute ein bisschen über Apps reden,
die man sich im besten Unternehmen einsetzt. Hintergrund ist,
bei uns, bei der Accando haben wir ein Team dafür,
die sich nicht nur, aber hauptsächlich mit Mobile Enterprise beschäftigt.
Und da würde ich gerne ein bisschen was erzählen,
wie da so unsere Erfahrungen sind und weitergeben.
Zum Hintergrund. Eigentlich ist der Vortrag so für fünf Minuten ausgelegt,
dessen habe ich einfach überlegt, ich rede doppelt so schnell,
dann passt das schon.
Nee. Also es wird zügig gehen,
aber ich habe an manchen Stellen drastisch gekürzt.
Ich hoffe, ich treffe zum Teil die richtigen Punkte,
die ich nicht gekürzt habe für das Interesse.
Bei anderen Punkten kommt dann eher so ein bisschen Buzzword Bingo,
wem das zu wenig ist.
Aufgrund der katastrophalen Anreise werde ich noch im Hotel heute bleiben
und deswegen auch noch länger hier ein Bierchen trinken.
Wer da fachsimpel möchte,
gerne eingeladen,
mich anzusprechen
So, zu meiner Person. Zusammengefasst,
wir haben ja keine Zeit, leidenschaftlicher Softwareentwicklung. Alles,
was vor dem Bereich rede, habe ich auch wirklich angefasst.
Deswegen ist viel persönliche Note mit dabei. Teilweise mit Vorsicht
zu genießen, aber es ist Erfahrung alles.
Ja, worüber möchte ich reden? Erstmal so einladen,
ein bisschen zur Strategie. Wie geht man dieses Thema westen im Unternehmen an?
Dann, wie holt man sich die IT-Abteilung als Freund ins Boot,
weil die auch mal sehr groß davon betroffen ist.
Das sind so die beiden Kapitel. Da geht es eher
so ein bisschen Buzzword-Bingo, wo es dann richtig spannend wird,
denke ich mal, das ist so das größere Interesse,
ist dann,
wie setzt man diese Apps wirklich rum
Ja, wie liegt man los? Mobile-Enterprise-Strategie.
Erstmal geht es darum, dass man so einen technischen,
organisatorischen und rechtlichen Rahmen für einen mobile Infrastruktur schafft.
Wie macht man das anschaulich? Da habe ich ein Anti-Beispiel,
was wirklich passiert ist. Kam ein IT-Leiter auf uns zu und fragte,
hey, er hatte ganz dringend Bedarf für eine Mobile-App,
hätten wir nicht irgendeine Idee für ihn.
Es war total verwundert, ja, wie irgendwas jetzt ausdenken. Ja,
Hintergrund war, er hatte, wollte besonders innovativ sein,
hat 2000 iPads angeschafft und dann festgestellt, hey,
per se können die ja erst mal gar nicht hier.
Also großen Vorteil haben die nicht. Ja,
Dringlichkeit kam ein bisschen daher,
weil Geschäftsführung sich da darüber die Rechnung gewundert hat,
dann war das dann alles so ein bisschen,
er braucht jetzt eine Rechtfertigung dafür.
Superspannend an der Sache. Mobile, was man daran merkt
, total emotionales Thema. Manchmal kommen da Entscheidungen her,
wo man sich fragt, wieso? Einfach nur aus diesen
Begehrlichkeiten. Zum anderen, was man daran sieht.
Also da wurde natürlich nicht von Anfang ein richtiges Stakeholder reingeholt.
Das Thema wurde eigentlich falsch angegangen. Wie macht man es besser?
Eigentlich fängt man erstmal damit an, schauen wir uns,
was können wir denn wirklich für Prozesse oder wirklich Walkflows in dem Unternehmen westen damit unterstützen?
Macht viel mehr Sinn. Dann überlegt man sich,
So eine, wie kann man am besten welche Mobility-Organisationsstrich dienen,
kann man am besten festlegen?
Also da gibt es verschiedene Strategien, die man fahren kann.
Lieblings-Buzzword, bring you all device. Da erlaubt man dann,
dass jeder sein Device mit ins Netz mitnehmen kann.
Enterprise only, da sagt man, nee,
nur wirklich Firmengeräte oder man fährt so eine Hybrid-Sache,
je nachdem, kann ja verschiedene Prozesse haben,
wo das jeweilige Sinn macht oder nicht.
Hat alles Vor- und Nachteile. Das wollte ich jetzt
in diesem Vortrag aber nicht als Hauptthema machen.
Ganz wichtig, so die Geräteauswahl dann zu treffen.
Das unterscheidet sich auch wieder, wie man das so privat macht.
Viele sagen dann, ja, es ist doch eh Apple
gesetzt,
doch mal iPhones
Macht nicht immer Sinn. Zum Beispiel ist so dieses nicht
wechselbare Akku auch häufig ein Thema. Es gibt viele Prozesse,
die, da nutzt man das Smartphone viel intensiver,
als man das vielleicht im privaten Gebrauch hat.
Und ja, es ist schon ein wichtigeres Kriterium.
Da kann man sagen, okay, Arquake Stander,
Ex-Sterness Peck dran, wunderbar, was man dadurch beachten muss.
So ein Akku ist eigentlich das Verschleißteil Nummer eins.
Wenn man das super intensiv nutzt, dann ist das Gerät
auch dementsprechend nach einem Jahr fast nicht mehr brauchbar.
Also man hat nicht nur die hohen Anschaffungskosten,
das Ding hält auch noch viel weniger.
Also das sind so Sachen, die man hauptsächlich in
diesem Thema eigentlich so betrachtet
So Beispiele. Ich finde das immer anschaulich,
wenn man so ein paar Beispiele gibt.
Da kann sich jeder so irgendwas drunter vorstellen. Der absolute
Klassiker ist BI-Dashboard. Super beliebt beim Management. Man ständig
überall Zugriff auf das, was so wichtig ist an Kennzahlen.
Ein Kunde meinte mal, für ihn wäre das,
war das super, weil da kam es oft vor,
in Meetings, dass irgendwelche Leute irgendwas behauptet haben.
Und für ihn war das dann super interessant,
dass er direkt einen Zugriff hatte und das validieren konnte.
Stimmt das überhaupt, was da behauptet wird? Super beliebt,
CRMRP-Apps für den Vertrieb Außendienst, die sind unterwegs,
alles, was für die wichtig ist, Kundeninformationen,
Produktinformationen, Kontrakt sehen,
was ist wie verfügbar,
können direkt bestellen
Super klassisches Thema. Feel Force, also Leute, die irgendwo unterwegs sind.
Zum Beispiel mobile Datenerfassung, hier so eine Knöllchenlösung,
wird auch immer mehr Städte, nutzen da Smartphones.
Häufig dann auch mit externen Geräten, die angebunden werden,
zum Beispiel Bluetooth-Drucker. Kennt vielleicht jeder schon mal,
das Knöllchen, hängt dann direkt unter der Scheibe.
Andere Sache, auch wenn Feel Force, Firma Pamster,
die kennt jeder, die mal eine Gartenparty gemacht hat.
Die haben so Shop- und Shop-Systeme und die müsst ihr selbst bewirtschaften. Das heißt,
sind Mitarbeiter, die fahren wirklich raus und gucken in den Regalen,
was wir nachgestellt werden und die nehmen dann einfach so einen
externen Scanner und gehen durch und klicken kurz die Bar kurz an,
was fehlt
Das gibt man kurz und zack, geht direkt RAP-Anbindung ins System.
Stellung geht draußen. So, jetzt haben wir vielleicht so eine Idee.
Wissen wir, vorgehen. Wir haben vielleicht eine Idee für eine App.
Welchen Prozess wollen wir umsetzen? Dann rennt man damit zur IT-Abteilung,
weil die müssen das ja erst mal gerade Geräte anschaffen,
einbinden, erst mal hinkriegen.
Und da gibt es den ersten Aufschrei,
de facto sind Mobile Devices erst mal nur im Internet.
Und dann kritische Daten aus dem Internet zugreifen, ja,
das gibt erst mal Schreikrämpfe.
Zum Glück gibt es da Lösungen,
also Mobile Device Management Systeme nennt man die
Die leisten alles das, was so die Herausforderungen sind,
die die IT in der Stelle hat.
Zum Beispiel diese versichere Verbindung im Unternehmen. Also Autorisierung,
Authentifizierung gegen Eldar, Exchange und so weiter.
Dann sicherstellen von Policies und Compliance. Also diese nervigen Passwortrichtlinien,
dass man jeden Monat ein Passwort ändern muss,
was aber nicht zu den letzten zwölf passt,
kann man auch auf die Smartphones übertragen.
Oder halt zum Beispiel Firmen, wo der Kameras nicht erlaubt sind,
dann kann man wirklich ganz speziell geräte Features abschalten.
Was erlaubt ist und was nicht. Dafür telefonieren,
da fand ich telefonieren, wie viel darf er telefonieren und was.
Auch wichtig, so ein App-Management, was darf er installieren,
was ist installiert auch über so einen Enterprise App Store.
Also das ist wirklich so ein Firmeneigener App Store.
Da kann man dann selber Apps reinstellen,
die nicht irgendwo in einem Public App Store sind,
kann aber auch aus dem Public App Store Apps freigeben,
die man installieren darf.
Das heißt, das ganze App-Thema kann man überhaupt managen.
Und wichtigste, wenn so ein Gerät verloren geht,
Remote-Vibe oder auch Orten. Ja. Damit,
ah genau, was gibt es da für Systeme?
So die bekanntesten Airwatch-Good Mobile Iron. Blackberry war da immer
führend. Ist ja ein bisschen auf dem absteigenden Mast,
aber da die in diese gerade Infrastrukturthema so stark waren,
überlegt man ja auch,
ob man das nicht raustrennt,
von Smartphone und Infrastrukturthema
In der neuesten Variante können die auch die anderen Betriebssysteme
wie iPhone oder Android, wen das mehr interessiert,
da gibt es natürlich auch eine Gartenstudie zu, wozu nicht.
Ja, wir haben den Plan,
ITs an Bord und jetzt wollen wir mal sehen,
was geht denn so an Apps, wie können wir die umsetzen.
Zum einen wollte ich das ein bisschen,
also wir haben immer noch diese Enterprise-Brille auf,
also wir sehen das so ein bisschen aus dem Fokus,
wir wollen das für ein Unternehmen umsetzen.
Was heißt das eigentlich? Was für App-Typen haben wir denn?
Welche Werkzeuge gibt es? Und dann wollte ich noch so
ein Perspectives-Beispiel machen, wie unser Team das zum Beispiel löst
Erstmal Enterprise-Apps, nicht unbedingt immer das gleiche Consumer-Apps.
Wir haben da von Kontext her noch so ein paar andere Anforderungen oder auch Herausforderungen.
Oder was zeichnet das aus? Zum Beispiel ein viel geschlossener,
noch ein kleinerer Nutzerkreis. Also es ist nicht das Ziel,
dass es in den App-Store landet und möglichst viele Download-Zahlen kriegt.
Ganz viele Sachen, die da eine Rolle spielen.
Schöne daran ist auch oder auch nicht schön.
Man kann doch einfach mal so User-Guidelines verletzen, interessiert keinen.
Also man hat das ja im eigenen App-Store,
was man in Public dann niemals einkriegt.
Macht manchmal Sinn
Tut dann weh als Entwickler, wenn dann so Anforderungen sind,
ja, das muss so aussehen,
auch wenn das bei keiner anderen App so ist.
Aber es gibt manchmal User, die halt nicht so Firmen sind mit den Smartphones.
Und dann macht man halt eine Variante, die die raffen,
aber eigentlich nichts Schönes, spart man sich halt Schwungsaufwand.
Immer wieder dieser höhere Sicherheitsanspruch, ganz wichtig, verfolgt einen immer.
Für mich ist so der wichtigste Unterschied,
den ich immer sehe, aus Erfahrung raus,
bei Enterprise-Apps ist so dieser Anteil von Backend-Integration immer viel höher als bei Consumer-Apps.
Also bei Enterprise-Apps, so erfahrungsgemäß immer so 80 bis 30
Prozent. Bei Consumer-Apps ist das
eher geringer
Ich werde jetzt gleich so ein bisschen von Komplexität immer reden.
Da wollte ich kurz darauf eingehen, was ich da eigentlich immer mit meine.
Es gibt so manche Faktoren, die besonders entscheidend sind,
dann für die Umsetzung der App, mit welchen App-Typen man dann arbeitet.
Und die machen die Sachen halt komplexer. Immer wenn hohe Usability gefragt ist,
klar, ganz generelle Latenzen in Zugriff, Interface,
intuitive Bedienung, macht die Sache immer etwas anspruchsvoller,
wenn man lange Akkulaufzeiten haben möchte, eine große Datenmengen gefragt sind,
kommt bei Business Apps häufiger vor oder Enterprise,
dass man mehr größeren Datenmengen arbeitet,
als wenn das so in der Consumer Apps kennt
Hohe Datensicherheit, haben wir wieder. Auch Offline-Verfügbarkeit, sehr häufig gefragt.
Nicht nur, dass die Offline verfügbar sind, aber auch,
dass sie sich automatisch synchronisieren, wenn man wieder online ist.
Im Enterprise-Kontext spielt da noch mehr mit rein,
dass man häufiger mit konkurrieren Zugriffen arbeitet.
Als Konsum hat man meistens nur seine eigenen Daten.
Im Enterprise-Bereich hat man häufig, dass mehrere Leuten im gleichen Daten arbeiten.
Macht immer die Sache etwas komplexer, wenn sowas gefordert ist. Und,
was sehr häufig, was wir eben gesehen haben,
Anbindung von Peripheriegeräten, also wir hatten Barcode-Scanner,
Bluetooth-Drucker und so weiter,
kommt bei Enterprise-Apps häufiger vor,
im Consumer-Bereich
eher sehr selten
Also das sind alles so Faktoren, die wirklich Auswirkungen haben,
was macht eine App komplex in der Umsetzung und was schränkt uns dann
auch in der Auswahl von Mitteln ein wie Webs umsetzen.
Ja, App-Typen, da fange ich an mit der ersten Sache,
die überhaupt keine App ist, aber lustigerweise immer wieder bei Mobile Development landet.
Also Leute haben gebrochen, die nur one sponse of Website,
fragen erstmal die Web, die, die,
die Mobile-Jungs, weil das ist ja meistens so der,
der, der Ball jetzt für iPad optimiert werden soll,
landet das lustigerweise immer bei uns oder häufig bei uns.
Ist eigentlich keiner, aber ich denke mal, ist bekannt.
Dann, was sicherlich auch jeder kennt, auf der anderen Seite
ganz klar die native App, mit Plattform-spezifischen SDKs entwickelt.
Dann kommt ein ganz großer Haufen dazwischen, die nennt sich alle Hybrid,
die kann man so grob clustern, schon in Web-Apps an sich.
Das sind dann so die HTML5-Seiten, die wie Apps aussehen wollen.
Häufig liegen die dann so einem Container, wie Fondgame.
Und dann gibt es noch diese Cross-Compile-Apps, das sind so,
die entwickeln immer neue zu einer Metasprache, auch web-orientiert,
JavaScript, die Cross-Compile ist dann nativ in die jeweilige Zielplattform.
Responsive Website, Mobile-Website, glaube ich,
brauche ich nicht weiter darauf eingehen in so einem Kreis hier.
Die Mobile-Website kennen wir ja, das ist dann so mobile.irgendwas-stern.de,
wo man dann umgeleitet wird und hat dann so eine für das Smartphone.
Sponsored ist ja dann immer noch die gleiche Seite,
passt sich aber vom Playout natürlich an, je nachdem,
was für die weiß man, etwas darauf zugreift.
Vorteil der Geschichte, ja, super leicht umzusetzen,
bleibt Know-how, weit verbreitet, super geil für Multichannel-Sachen.
Großer Nachteil, hat natürlich überhaupt nichts mit App zu tun.
Geräte-Features, keine Möglichkeit, ein App-Store geht es auch nicht.
Deswegen Anwendungsszenarien gibt es definitiv. Also wenn wir so ganz einfache Prozesse haben,
wo fast gar keine Benutzereieingaben irgendwie gefragt sind,
wir brauchen gar keine Hardware-Features und braucht es nicht oft
Es sollen möglichst viele Geräte und man weiß gar nicht,
welche Geräte das eigentlich alles gibt. Dann kann man das
mit abdecken. Häufig hat man das auch so,
dass es dann irgendein Kunde ist, der hat schon eine
Website und will das jetzt halt auch auf mobile-ready haben.
Beispiele, alles so Sachen, wo es hauptsächlich um Ausliefern,
Zeigen von Informationen geht, gar nicht so sehr um die Eingabe von Informationen.
Ja, die Web-App hybrid an sich, zum Beispiel,
wie die meistens aussehen, ja, ist immer noch HTML 5,
tut aber so, als wäre es eine App.
Plus an der Sache immer wieder noch, ja,
diese Multi-Plattform-Geschichte und es ist Web,
leichter Einstieg
Teilweise mit Fondsgap kriegt man auch Features hin. Also Hardware-Nar-Features,
wenn man so mal ab und zu mal einen QR-Code einsgängen muss,
ist das okay. Wenn man jetzt aber so Enterprise-Features hat wie,
wir brauchen eine verschlüsselte Datenbank mit irgendwie eigenen Zertifikaten oder so,
da wird es echt schon schwierig.
Schön ist natürlich, wenn das Marketing irgendwie sagt,
hey, wir brauchen unbedingt eine App und damit kommt man
halt in den App Store und kann dann sagen,
hey, wir haben einen.
Ja, an der Stelle keine richtige App-User Experience,
nenne ich es mal. Gerade auch Cross-Plattformen merkt man das
. Die sehen halt meistens immer alle aus wie iPhone.
Wenn man das dann irgendwie so ein Windows-Phone oder einen Android-User
vorsetzt,
kriegt dann erstmal
das Grauen
Für mich als Entwickler immer so ein großer Nachteil,
man begibt sich in so einen Kompromiss, in so einen Technologiekäfig mit Einschränkungen.
Wenn Fehler und Probleme da sind, hat man es
auch immer schwieriger, da wieder Lösungen zu finden.
Natürlich Performance. Also das wird besser, aber grundsätzlich,
wenn man es benutzt, merkt man es schon,
dass es eine Web-App ist. Ja, die Hybrid,
also typische Einsatzszenarios, wo man jetzt gerne benutzt.
Dann nähern wir uns schon so ein bisschen Richtung,
ja, kann man gebrauchen, auch für Take,
vielleicht täglich mal benutzen, ein paar grundlegende Hardware-Features,
alles so was so weniger Komplexes,
ein bisschen Mittelkomplex finden uns ja an die Sachen,
was am Anfang
mit Komplexität meinte
Beispiele, so Urlaubsanträge, Ticketsystem, Motoring-Apps.
Also so typische Sachen, die man da mitmachen kann.
Dann die CrossCompile-Apps. Wie erkennt man die? Von der
Benutzerführung, von der Interface-Latenz sind die schon sehr flott,
weil ist ja nativ. Ich habe immer das Gefühl,
das sieht so aus, als hätte es sich,
als wäre es nativ, aber hätte sich jemand ausgesprochen,
wenig Mühe gegeben, dass die schön sind.
Häufig erkennt man die einfach, dass die irgendwie,
ja, nicht diese Plattform-spezifischen UI und Usability-Features haben.
Irgendwie einen gemeinsamen Länder muss man ja schon finden.
Das finde ich immer so ein Nachteil.
Das habe ich, glaube ich,
schon vorweggegriffen
Da kommen wir schon richtig ein bisschen mehr, also von den Gerätefeatures besser nutzbar.
Offline-Funktionierte auch deutlich besser. Immer noch App-Store-tauglich. Ich finde bedingt
akzeptable App-User Experience, also von der Benutzbarkeit schon besser.
Sieht halt nicht so cool aus. Immer noch,
wir haben wieder eine Technologie, die wir dazwischenschieben.
Wenn man da Probleme hat, wird es schon schwieriger,
weil meistens sind die Sachen nicht Open Source oder schwer zu debuggen.
Teilweise auch lizenzpflichtig, zum Beispiel bei Coni. Trotzdem machen
die Sinn, einzusetzen. Gibt es jetzt schon so ein bisschen noch ein Stück Richtung die native Sache,
also alles, was so ein bisschen mittlere Komplexität hat,
vielleicht ab und zu mal benutzt,
Zum Beispiel ein Vorteil bei Conny ist es,
die haben auch schon Adapt, also Enterprise Systemanbindung,
indem die so generische Adapte haben für so Standardsysteme,
manchmal ganz gut an Daten drankommt.
Typisch Beispiele, so Produktkatalog wird gerne mitgemacht. Einfache CRM,
RP, wie Bayernbindung, weil die vielleicht zum Beispiel schon
die Standardadapter dabei haben. Ja, die native App,
ich glaube, kennt jeder, der ein Smartphone hat,
der sieht direkt, was da wirklich nativ entwickelt wurde.
Meistens die vom Hersteller selber schicke Sache.
Zusammengefasst, da gibt es keine Kompromisse einfach.
Alles, was das Device hergeht, kann man natürlich machen
Großer Nachteil, natürlich spezialiertes Know-how. Und ich habe es
einmal für eine Plattform entwickelt, dann läuft es auch nicht auf anderen.
Das kann man sagen, okay, Blackberry kann auch Android-Apps abspielen,
wer das mal wirklich benutzt hat, der tut es nicht mehr.
Man merkt, es läuft deutlich langsamer. Also wirklich brauchbar
ist es nicht. So, typisches Szenario. Ja,
wir haben wenig Plattformen. Enterprise-Bereich bei manchen Angangsszenarien,
da liegt man sich auch von Device und eine Plattform einfach fest.
Haben wir bei Beispielen vorher gesehen, gerade wenn das so dieses Enterprise-Only-Strategie ist.
Wenn die App halt super häufig genutzt wird,
auch für viele Benutzereingaben, braucht viele Hardware-Features oder auch Peripriegeräte,
die angebunden werden
Beispiel Remote der Zeitzugriff, leistungsstarke CMR, PBI-Apps oder auch
ganz stark bei der mobilen Datenerfassung muss auf Geschwindigkeit ankommt.
Ja. Hier wollte ich das nochmal ein bisschen gegenüberstellen,
so mit Chart, man sieht unten auf der X-Achse die Komplexität,
wir nennen uns so die Punkte,
die so eine App alles komplex macht, wenn da was zusammenkommt,
dann rutscht es nach rechts und nach oben hin die Zielplattform,
wie viele wir da haben.
Mobile Response of Web, ganz klar, da ist irgendwann Ende an Komplexität,
bald da so ein Punkt, wo zwei sind,
die sowas nicht lösbar sind, dann ist der Ende.
Nach oben innen ist es offen, also fast jedes Smartphone hat da
Hat einen Webbrowser mit drin, da kann man das immer anschauen. So,
die Hybrid-Web-App, da sieht man, da ist oben irgendwann Ende,
da ist man gefangen in dem, was so die Plattform unterstützt.
So Komplexität geht schon besser rein. Die Kurve ist ein bisschen schräg,
einfach da deswegen,
wenn man Komplexität hat und dann noch in der Plattform ist es häufig so,
dass man doch anfängt, zu weichen und Hacks einzubauen,
das ist dann doch irgendwie auf jeder Plattform gut läuft.
Deswegen, bei vielen Plattformen und mehr Komplexität
wird es dann doch wieder nicht so die ideale Lösung
Die Cross-Compile-Geschichte ist ja schon ein bisschen effizienter.
Da ist meistens Frühjahrschluss, die unterstützen weniger Geräte als Hybrid-Web-App.
So und konträr dazu, die native App,
da merkt man ab einer bestimmten Komplexität,
macht die nur noch Sinn, als du nur damit sinnvoll gelöst wird.
Jetzt fragt man sich, was macht man, wenn man
jetzt da oben hängt? Wo gar nichts abgedeckt wird.
Zum einen, das ist natürlich jetzt nicht so hart,
wie man das hier so einzeichnet.
Das ist auch immer davon abhängig, welche Komplexitätspunkte man hat.
Manchmal reicht so einer, dann ist schon, whop,
dann fliegen alle raus. Manchmal so ein, zwei,
dann ist auch okay. An der Stelle würde ich
eigentlich aus der Erfahrung immer zu der nativen App tendieren,
aus dem Grund, weil ich da sicher gehen kann,
dass es auch wirklich lösbar ist.
Teilweise kriegt man es einfach mit den anderen Wegen
dann doch nicht gelöst und hat ziemlich viel Zeit verschwendet.
Bei der tiefen App bin ich mir sicher,
dass es definitiv irgendwie lösbar ist. Jetzt hat man so
ein bisschen gemerkt, nativ macht eigentlich Enterprise Concick häufig Sinn.
Wieso? Wir haben häufig viel Komplexität immer dran.
Also diese ganzen komplexe Textpunkte,
was jetzt bei uns in einem Projekt sehr schnell,
dass wirklich viele von diesen Punkten dort auftauchen.
Und wir haben ja eigentlich immer einen ziemlich hohen Migrationsanteil.
Also bei unseren Projekten ist wirklich der Kleidanteil eher etwas weniger.
Deswegen eigentlich jetzt nicht
so wichtig
Also bei der Umsetzung. Wir haben das jetzt für mehrere
Plattformen hat, wie macht man das dann trotzdem bezahlbar?
Weil irgendwie in der Tiefen ist doch schon irgendwie so ein Königsweg.
Ein Vorgehen, wie wir das gerne machen?
Erstmal Backend, Standardmittelwehr für die Integration. Da haben wir
eine eigene Lösung entwickelt, die wir gerade daran arbeiten,
dass die Open Source wird.
Wer da Interesse dran hat und ähnliche Probleme oder Herausforderungen hat,
kann mich da gerne zu anpingen.
Möchte ich jetzt nicht weiter darauf eingehen, sprengt den Rahmen.
Kleid ist jetzt das Interessante,
wo wir eigentlich hier reden möchten
Erstmal nochmal unser Superschaubild. Links, das kennen wir,
Kleid, eher der geringere Teil. Und den Kleinen kann man jetzt nochmal differenzieren,
dass häufig so ein schon größerer Anteil,
ungefähr die Hälfte, die immer so ein Shared-Business-Code ist,
so Sachen, die jetzt nicht unbedingt plattformspezifisch sind.
Etwas, was man eigentlich auf jedem Kleid wiederverwenden könnte.
So, was wir machen, wir nehmen diesen Teil.
Dann haben den zum Beispiel unten links,
das ist meistens so viel Modell und Logikcode,
nutzen wir das erstmal natürlich auch im Backend.
Wir machen das in Java. Im UI-Bereich im Backend
nutzt du das direkt wieder, Google Web Tokit,
übersetzt das von Java und Java-Script
Also for free quasi den ganzen Code.
Android ist das auch sehr einfach, läuft auf Java,
nutzt live, einfach eins zu eins for free.
Jetzt wird es spannend. In den anderen Plattformen machen wir
ein Cross-Cancelly, zum Beispiel bei Apple und Dective Sea.
Da auch wieder die Stärke mit Java. Da gibt es
halt nur ein Projekt, was da sinnvoll übersetzen kann.
Wird zum Glück auch von Google Mantained. Vorteil an der Stelle ist,
der Plattform-spezifische Aufwand ist wirklich nur noch diese Crimed,
Client-UI-Geschichte zu entwickeln.
Und das ist im Endeffekt in dem ganzen Konstrukt
eigentlich nur ein
sehr geringer Teil
Ehrlich muss man sagen, das zu meistern,
erst mal hinzukriegen, ist nicht so einfach.
Also das ist echt eine Herausforderung. Wenn man es hinbekommen hat,
ist das echt super geil. Also gerade die iOS-Entwickler,
die freuen sich im Loch im Bauch,
die können die meiste Zeit mit Fan-CUI-Geschichten und Designer
rumspielen und müssen sich nicht so viel mit Business-Code-Tippen beschäftigen,
dass der bei iOS echt ein bisschen nervig sein kann.
Ja, so als Idee, wie man das machen will
, lesen kann. Es gibt natürlich auch andere Werkzeuge,
wie man Mobile Development angehen kann,
dass man da so für Mittel haben kann,
so typische Cycle,
kann bilden,
integraten oder auch Apps managen
Ja, Standard-SDKs plus, was wir schon drüber geredet haben,
so die Standard-Frameworks für die Webentwicklung, die konzentrieren sich wirklich nur aufs App bauen.
Dann gibt es so diese Lösung,
wie ich schon mal Titania, dieses Cross-Plattform,
die versuchen auch in diesen Integrations- und Management-Teil reinzukommen,
was die jetzt so am Fokussieren sind, aber ja,
noch eher etwas unterentwickelt ist.
Und dann gibt es so Apps, so Standard-Lösungen,
die sich eigentlich nur auf das Integrieren von Daten beschäftigen.
Also fast jeder, BI, CRM,
es gibt für SharePoint, gibt es X-Client, Clients,
die sind fertig,
installiert man sich,
bindet Backend an und dann läuft das eigentlich schon
Und dann gibt es Lösungen, die nennen sich
Mobile Enterprise Application Plattforms, die versuchen alles abzudecken.
Da gibt es auch einige. Cony, Cybers Unway Plattform, Atella,
Convertico zum Beispiel, aber auch von IBM bis mehrere.
Ich versuche, das alles abzudecken. Das sind die sogenannten
Memes, die versuchen halt die gesamten App-Life-Cycles zu unterstützen.
Sind fast immer eine Middleware, die sich mit Integration,
Security, App-Management beschäftigen, sind.
Meiner Meinung nach für spezielle Use-Cases sind sinnvoll, auf jeden Fall.
Aber meiner Meinung nach wirklich, wenn man den Use-Case hat,
weil im Grunde sind sie auch wieder nur ein Entwicklungsgrundgerüst.
Die nehmen zwar einem viel ab, aber wenn man das
gekauft hat, Dann hat man erstmal noch nicht viel.
Manchmal so ein paar Standard-Apps, aber im Endeffekt muss man auch wieder drauf entwickeln.
Und hängt wieder in so einem Technologiekäfig. Teilweise an deren App-Designer,
also so Leute, die jetzt sich nicht jeweils mit der
spezifischen Plattform beschäftigen wollen, können das so einmal lösen.
Fast alle grundsätzlich Lizenzkosten, meist auch noch Anzahl der Clients.
Bei manchen, nicht gerade günstig. Da muss man auch
teilweise ein bisschen aufpassen. Manche Hersteller haben da gemerkt,
hup, hier geht gerade so ein Mobile-Hype-Trainer an mir vorbei
und da will ich noch schnell mit aufspringen.
Da haben die mal schnell geschaut,
was haben wir denn da schon für Software
im Unternehmen rumliegen
Und haben das ein bisschen umbenannt und Branda ist jetzt total neu,
also alter Wein im neuen Schläuchen. Manchmal kennt man die daran,
dass sie in ihrem Supported Devices noch so Simbian drinstehen haben.
Da hat man manchmal, da weiß man schon,
da sind eigentlich Dinosaurier hinter. Ja, und damit,
ja, da auch wieder eine Gärtnerstudie, wenn das interessiert.
Sind wir mit dem Schnellflug schon fast am Ende?
Hast du nochmal Zeit, unsere Studie gegeben?
Bitte? Die Juju vergeben, da zu Autos zu zeigen.
Dir? Ja, das ist nur so ein Hinweis,
dass es das gibt.
Wen es näher interessiert. Ja, okay, ja.
Ich glaube, Folien gibt es eh,
ist aufgezeichnet
So, am Ende. Erstmal sinnvolle Strategie für den stattfinden
. Nicht einfach mal 2000 Devices kaufen, die gucken,
was man damit machen kann. Ja, es gibt unterschiedsspezielle Anforderungen,
wenn man zum Beispiel mit Enterprise-Apps arbeitet oder entwickeln möchte.
Standardlösungen können für spezielle Use-Cases sinnvoll sein, zum Beispiel auch diese Standard-Apps.
Mieblösungen auch interessant. Ich muss ehrlich sagen,
nicht die tollsten Erfahrungen mitgemacht und viele Kunden,
die sich erst mal überlegt haben, setz noch mal darauf,
wenn sich ein halbes Jahr wieder meint,
irgendwie funktioniert es nicht.
Also da muss man echt
mal genauer hinschauen
Ja, und also App-Typ-Auswahl und Tools ist echt anspruchsvoll.
Ich tue uns da auch manchmal schwer, so den besten
Weg zu finden. Was nehmen wir denn da jetzt?
Gibt keinen Leitfaden. Am besten immer mehrere Meinungen auf einholen.
Schon viele Projekte scheitern sehen, die irgendeinen Ansatz versucht haben
und dann kläglich festzustellen, das geht nicht.
Jetzt machen wir es doch irgendwie nativ.
Super, vielen Dank. Ja, gerne Fragen.
Und später bin ich auch noch da
Keine Frage werden. Nicht? Ja. Was ist denn deine persönliche,
meine Norm schaue ich jetzt ja so negativ oder die anderen,
glaube ich ja nicht, aber hast du ein stüttes System,
das zu erfüllen, die das Meistertum und Geiz?
Also ich, meiner Java-Hintergrundgeschichte bin ich natürlich eher so ein bisschen Android-Minded, macht häufig auch Sinn, aus vielen Gründen. Wenn wir entwickeln,
ich gerne nativ, ich bin auch der Meinung,
wenn man ein gutes Team hat,
wo man alle Kompetenzen im Team selber hat,
Ist man auch, wenn man es immer nativ macht,
weil zum Beispiel, wenn man Android und iOS-Entwicklung jetzt macht,
die beiden Plattformen fokussiert, die anderen sind halt auch nicht so relevant,
dann schafft man es auch mit zwei guten Entwicklern,
fast der gleichen Zeit, wie einen Webentwickler,
der das dann einmal Crossplattformen entwickelt,
auch hinzukommen in der Zeit.
Also eins gegen eins,
auf jeden Fall kriegt man das in der gleichen Zeit hin,
weil zwei gegen eins, kostet man vielleicht nicht.
Manchmal verlagert sich so die Arbeit, weil wenn du es nativ machst,
dann weißt du direkt, wie es funktioniert.
Ich habe dann schon das Gefühl,
wenn man es so Crossplattformen macht,
hat man halt hinterher viel mehr Arbeit,
noch in der Nachbearbeitung,
ist es dann
wirklich sauber und richtig läuft
Echt immer so Sachen sind, die haken geht,
einfach nicht so einfach zu lösen sind.
Deswegen, ja, ich bin schon nativ gemeindet.
Kam, glaube ich, auch ein bisschen durch.
Danke. Gerne. Ja, eine Frage. Keine.
Dann. Cool. Bist du noch ein bisschen da?
Ja, ja. Ansonsten einfach dich
ansprechsam. Ja