On Tour: ICSA 2018, Seattle, USA

Bei der ICSA 2018 in Seattle werden Matthias Naab und Dominik Rost vertreten sein. Am 01.05. halten sie ein Tutorial zur Bewertung von Softwarearchitekturen und am 02.05. einen Vortrag zu Erfahrungen aus dem Aufbau eines Digitalen Ökosystems.

How to Evaluate Software Architectures: Tutorial on Practical Insights on Architecture Evaluation Projects with Industrial Customers

Hier die offizielle Ankündigung und Beschreibung:

„Thorough and continuous architecting is the key to overall success in software engineering, and architecture evaluation is a crucial part of it. This tutorial presents a pragmatic architecture evaluation approach and insights gained from its application in more than 75 projects with industrial customers in the past decade. It presents context factors, empirical data, and example cases, as well as lessons learned on mitigating the risk of change through architecture evaluation.

By providing comprehensive answers to many typical questions and discussing lessons learned, the tutorial allows the audience to not only learn how to conduct architecture evaluations and interpret its results, but also to become aware of risks such as false conclusions, manipulating data, and unsound lines of argument.

The target audience includes both practitioners and researchers. It encourages practitioners to conduct architecture evaluations. At the same time, it offers researchers insights into industrial architecture evaluations, which can inspire future research directions.“

Das Tutorial basiert auf unserem Buch „Pragmatic Evaluation of Software Architectures“.

Wir freuen uns auf viele Teilnehmer und interessante Diskussionen.

Wer nicht zur ICSA kommen kann, hat die Gelegenheit dieses Tutorial auch als Teil des nächsten Architekturseminars im April am IESE zu besuchen.

 

Architecting a Software-Based Ecosystem for the Automotive Aftermarket:
An Experience Report

Matthias Naab und Dominik Rost präsentieren einen wissenschaftlichen Erfahrungsbericht aus der Kooperation mit unserem Kunden Caruso.

Hier geht es zum wissenschaftlichen Programm.

Abstract unseres Papers:

„Software-based ecosystems comprise multiple software systems developed by a multitude of organizations. They are on the one hand technically integrated, often via a dedicated platform forming the center of the ecosystem. On the other hand, the organizations and their systems interact in a way that provides (business) benefits for all participants and leads to new forms of businesses. The ecosystem platform is typically defined, developed and operated by the ecosystem initiator. In the past two years, we have been working on the initiation of an ecosystem and the development of a platform for the automotive aftermarket: a data and service marketplace. As core contributions in this paper, we share the experiences and lessons learned from the early phases from an architect’s point of view. As a background, we first describe our key architecture drivers, the current state of the architecture, and how architecture work is performed. We experienced a substantially extended scope for ecosystem architects, working on the overall ecosystem and the platform. Especially in the beginning, architects have to live with a high degree of uncertainty and fuzziness and have to help shaping and aligning business, technical, and legal aspects. Besides these key insights, we share lessons learned in the following categories: Requirements and Priorities, Architecture and Architecture Work, Platform Releases and Time-to-Market, Partners, Communication, Learning from other Ecosystems.“

AccsoCon – Digitalisierung: Vortrag zu Digitalen Ökosystemen und Plattformen

Die AccsoCon ist die interne Konferenz der Firma Accso zu aktuellen Themen in der IT. Am 16.03.2018 fand die Konferenz zum Thema „Digitalisierung“ statt. Matthias Naab vom Fraunhofer IESE war als Sprecher mit einem Vortrag zu Digitalen Ökosystemen und Plattformen dabei. Er illustrierte neue Erkenntnisse am Beispiel des B2B Daten- und Servicemarktplatzes Caruso Dataplace.

Die AccsoCon bot ein sehr vielfältiges, interessantes und unterhaltsames Programm, das ich hier nochmal kurz Revue passieren lassen möchte. Ich freue mich, als Sprecher dabei gewesen zu sein und konnte alle Vorträge und viele spannende Diskussionen genießen.

Die Accso-Mitarbeiter waren auch auf Twitter sehr aktiv, so kann man auch nochmal die Highlights der Konferenz nachverfolgen: #accsocon und @accso.

Sören Kewenig
Digitalisierung

Sören Kewenig führte zielgenau auf das Thema hin, indem er für verschiedene Branchen beleuchtete, was Digitalisierung dort aktuell bedeutet (Mobilität, Produktion, Finanzwesen, …).

Kim Lauenroth
Der Digital Designer als neuer Partner für den Softwarearchitekten

Kim Lauenroth ordnete detaillierter ein, wie man den Begriff „Digitalisierung“ differenzieren kann: Digitale Produkte, Digitale Prozesse, Digitale Geschäftsmodelle … leider gibt der deutsche Begriff Digitalisierung diese Unterscheidung nicht her.

Dann postulierte er das neue Rollenideal des Digital Designers, der notwendige Kompetenzen für die Gestaltung von Software-basierten Systemen bündelt und technischen Rollen des Software Engineering gegenüber gestellt ist. Er bemühte dafür insbesondere den Vergleich mit Architekten und Bauingenieuren.

Er prangerte an, dass die Informatik in der Ausbildung zu undifferenziert ist und setzt sich dafür ein, einen Ausbildungsweg zum Digital Designer zu etablieren.

Alexander Culum
Driving Blockchain Adoption: The Challenges ahead

Alexander Culum positionierte die Blockchain als allgegenwärtigen Protagonisten, wenn über Digitalisierung gesprochen wird. In erfrischender Art betonte er, dass die Blockchain eben nicht die Lösung für alles ist, auch wenn der Begriff reflexartig in den Ring geworfen wird. Er differenzierte geschickt und erklärte fortgeschrittene Anwendungsszenarien und technische Eigenschaften und Implikationen der Blockchain.

Eric Wilde
API-Economy: Who is in the Driver’s Seat?

Eric Wilde befasste sich mit der API-Economy. Seine Haupt-Message:

„Es geht nicht einfach darum, APIs zu monetarisieren, sondern es geht um Geschäftsmodelle, die Services und Inhalte über geeignete APIs den Kunden zur Verfügung stellen.“

Matthias Naab
Caruso: Ökosystem und Plattform

Ich hielt einen Vortrag zum Thema Digitale Ökosysteme und Plattformen. Am Beispiel unseres Kunden Caruso Dataplace konnte ich viele Erfahrungen illustrieren und eine angeregte Diskussion initiieren. Der Vortrag gab einen Überblick über folgende Themen:

  • Einordnung von Digitalisierung, Digitaler Transformation, Plattformen, Ökosysteme
  • Was sind die Ideen hinter Caruso: Geschäftlich, technologisch, rechtlich?
  • Wie sieht das Caruso-Ökosystem, die Partnerlandschaft und die Plattform aus?
  • Welche Arten von Plattformen gibt es in der Branche und wie stehen diese in Bezug zu Caruso?
  • Erfahrungen aus dem Aufbau des Ökosystems und der Plattform

Gunter Dueck
Reise durch Disruptionen

Gunter Dueck hielt einen mitreißenden Vortrag, in dem er sarkastisch IT, deutsche Unternehmen, den aktuellen Stand der Digitalisierung, Management-Strategien und vieles weitere beleuchtete.

Er appelierte, Verantwortung zu übernehmen, einfach zu machen, schwachsinniges Vorgehen zu ignorieren und damit einen echten Beitrag zum Standort Deutschland und seiner Digitalisierung zu leisten.

On Tour: SATURN 2018, Plano, TX, USA

Wir freuen uns sehr, bei der SATURN 2018 als Sprecher dabei sein zu dürfen. Die SATURN findet vom 07. bis zum 10. Mai 2018 in Plano, Texas statt. Das Programm verspricht wieder eine sehr spannende und interessante Konferenz für Softwarearchitekten!

How do Software Architects find the way to User Experience? With Google Maps!

UX is surprisingly often neglected by software architects, and talking to UX people is rather the exception. With the example of Google Maps, we illustrate the mutual impact of architecture and excellent UX, covering also the specifics and relationship between UX designers and software architects.

Architecture of the CARUSO Ecosystem – Bringing a Market Place for Car-Related Data and Services to Speed

CARUSO is a B2B market place brokering data and services around car telematics. We report from the architects’ work in creating the ecosystem: continuous tension among business, legal, and technology. Key challenges are openness, trust, attractiveness for partners, and low entry barriers.

Dieser Vortrag ist zusammen mit Jens Knodel, Caruso Dataplace GmbH

 

Wir freuen uns auf eine spannende Konferenz und viele interessante Diskussionen und tiefgehenden Austausch.

 

On Tour: OOP 2018, München

Wir freuen uns sehr, bei der OOP 2018 als Sprecher dabei sein zu dürfen. Mit vielen Tracks zu spannenden Themen rund um Softwareentwicklung verspricht die OOP wieder ein echtes Highlight zu werden. Das Motto 2018: „Software meets Business“.

Wie finden Softwarearchitekten den Weg zu User Experience? Mit Google Maps!

Softwarearchitektur und User Experience (UX) sind zentrale Erfolgsfaktoren von Softwaresystemen. Wir beleuchten das Spannungsfeld zwischen diesen beiden Bereichen. Wir illustrieren am Beispiel von Google Maps, welche architektonischen Höchstleistungen und Tradeoffs notwendig sind, um die Google-Experience zu erreichen, das heißt: Einfachheit zu gewährleisten und gleichzeitig global zu skalieren. Der Vortrag zeigt auf, wie trotz der unterschiedlichen Charaktere von Architekten und UX-Designern großartige Systeme erschaffen werden können.

Architektur des CARUSO-Ökosystems – Telematik, Daten und Marktplatz digital ins Rollen gebracht

CARUSO ist ein B2B-Marktplatz zum Brokering von Daten und Services rund um Fahrzeug-Telematik. Wir berichten von der Arbeit der Architekten im Spannungsfeld von Geschäftsmodellen, Recht und Technologien eines entstehenden Ökosystems. Der Weg zur erfolgreichen Digitalisierung der Domäne ist gepflastert mit Zielanpassungen, Experimenten und schnellen Entscheidungskorrekturen. Kernherausforderungen sind Offenheit bei gleichzeitiger Sicherheit und Vertrauen sowie hohe Attraktivität für Partner bei gleichzeitig einfachem Eintritt ins Ökosystem.

Dieser Vortrag ist zusammen mit Jens Knodel, Caruso Dataplace GmbH

Wir freuen uns auf eine spannende Konferenz und viele interessante Diskussionen und tiefgehenden Austausch. Hier geht es zum vollständigen Konferenzprogramm.

Jan Bosch: Viele Firmen verbauen sich den Weg zu Innovation, indem sie von bestehender Organisation und Prozessen starten statt von ihrem zukünftigen Business und daraus abgeleiteten Architekturen.

Gemacht wird: OPAB
Richtig wäre: BAPO.

Gregor Hohpe: Warum interne Reibung und Ineffizienz in Unternehmen 1.) besonders den eigenen High-Peformern schadet und 2.) die so wichtige Bindung neuer Top-Talente verhindert.

Architekten als Geschichtenerzähler, Soziotechnologen, Dokumentierer und mehr (O’Reilly Architecture Conference London 2017)

London - Tower Bridge at Night
Am 16./17. Oktober fand in London die O’Reilly Conference Software Architecture statt. Wir waren mit unserem Talk „How do software architects find the way to user experience? With Google Maps“ dabei. In diesem Artikel lassen wir die Konferenz Revue passieren.

Die Konferenz war sehr gut besucht (geschätzt ca. 500 Leute) und zog Architekten und Entwickler aus ganz Europa, aber sogar auch von anderen Kontinenten an.

Ein interessantes Konzept waren die recht kurzen Keynotes (ca. 20 Minuten). So wurden statt einer langen Keynote gleich 3 Keynotes am Stück präsentiert, was zu sehr pointierten und kurzweiligen Vorträgen führte.

Auch eine interessante Beobachtung (wie bei einigen vergangenen Veranstaltungen): Firmen sind aktuell stärker auf der Suche nach neuen Mitarbeitern als nach neuen Kunden! Architekten und Software Engineers im Allgemeinen sind aktuell also sehr gesucht!

Es gab Talks zu unterschiedlichsten Aspekten von Softwarearchitektur. Wir orientieren uns hier im Artikel an einer Charakterisierung von Architekturkompetenz und Architekturthemen, die wir im Blog auch demnächst noch beschreiben werden. Die Darstellung der Talks hier im Artikel soll nicht repräsentativ sein, sie spiegelt eher wieder, welche Talks wir uns angesehen haben und für besonders sehenswert halten. Meist sind auch die Folien der Talks verfügbar oder sogar Videoaufzeichnungen, die wir dann verlinkt haben.

  • Architekturgrundlagen
  • Architekturmethoden und –Tools
  • Architekturelle Systemexpertise (Herausforderungen, Lösungskonzepte, Technologien, Frameworks, …)
  • Architekturaspekte rund um Menschen und Organisationen

Zum Abschluss gab es als Übung und gemeinsames Event noch Architecture Katas, die wir am Ende des Artikels beschreiben.

Architekturgrundlagen

Mark Richards widmete sich in seiner Keynote „The move toward modularity“ dem Thema Modularität, das eine zentrale Rolle für Softwarearchitektur spielt und durch Microservices wieder mehr ins Bewusstsein gerufen wurde. Mark Richards beleuchtete verschiedene Facetten von Modularität, insbesondere auch die dahinterstehenden Ziele (bei ihm: Agility, Testability, Deployability, Scalability, Availability).

Architekturmethoden und –Tools

Der neue CTO Patrick Kua vom deutschen Fintech-Unternehmen N26 sprach über in unterhaltsamer und anschaulicher Weise über Architekturdokumentation. Dazu verwendete er als Analogie den Reiseführer: „The travel guide to a software system“.

Er beschäftigte sich mit zahlreichen Fragen rund um die Erstellung von guter und pragmatischer Architekturdokumentation:

  • Gründe, sich mit Architekturdokumentation zu beschäftigen
    • Menschen kommen und gehen
    • Organisationen wachsen
    • Man hinterlässt mit einem System ein Vermächtnis
    • Zukünftige Arbeiten sollte nicht mit Detektivarbeit starten müssen
  • Wichtigste Inhalte
    • Historie (Kontext, Entstehungsgeschichte, Erfahrungen, wichtigste Entscheidungen, …)
    • Sinnvolle Fakten (Domänenwissen, Akronyme, Personas, wichtigste Use Cases, …)
    • Kultur (Coding Guidelines, Konventionen im Code, Entwicklungsprozess, …)
    • Karten / Sichten (Gesamtsicht, verschiedene Aspekte und Sichten des Systems (z.B. C4 Model von Simon Brown), Sequenzdiagramme, Flussdiagramme, …)
    • Sehenswürdigkeiten (Wichtigste Punkte im System, Systeme häufigster Änderungen, …)
    • Fun (Fun Facts zum System, Stellen, an denen besonders innovative oder kreative Lösungen zu finden sind, …)
  • Die Reise zur Architekturdokumentation
    • Ausgangspunkt (Immer vom Leser her denken, was sind die Use Cases von Dokumentation)
    • Größe (hängt von Historie, Menschen, Änderungsgrad und –geschwindigkeit, Domänenkomplexität ab)
    • Aktuell halten

Architekturelle Systemexpertise (Herausforderungen, Lösungskonzepte, Technologien, Frameworks, …)

Eoin Woods, CTO von Endava, sprach über Security aus Sicht des Architekten: „Practical security principles for the working architect”. Der Talk war extrem kurzweilig und stellte zentrale Sicherheitsprinzipien dar, die bei jedem Design einer Systemarchitektur durchdacht werden sollten. Insbesondere die Betrachtung von Security jenseits der reinen Codeebene (wie z.B. Lücken wie Buffer Overflows) ist sehr wichtig und wird häufig in der Praxis vernachlässigt. Eoin Woods zeigte an guten Beispielen auf, wie Architekturentscheidungen und verschiedene Modularisierungen zu unterschiedlich sicheren Systemen führen können.

Auch unser Vortrag „How do software architects find the way to user experience? With Google Maps“ passt in diese Kategorie. Er illustriert den engen Bezug zwischen User Experience und Softwarearchitektur, der immer noch zu wenig Beachtung findet. Das liegt unter anderem auch an den unterschiedlichen Ausbildungshintergründen von Softwarearchitekten und UX Designern. Am Beispiel von Google Maps zeigen wir auf, welche Architekturentscheidungen getroffen wurden, um die bekannt gute User Experience von Google Maps zu erreichen.

Yan Cui sprach zum Thema serverless computing am Beispiel von Amazon Web Services Lambda: „Serverless in production: An experience report“. Er berichtete von Erfahrungen bei ersten Experimenten und realem Einsatz von AWS Lambda. Er konnte mit vielen Beispielen und Fallstricken punkten und konnte somit der aktuell sehr gehypeten Technologie eine gute Erdung und viele Tipps zur Umsetzung geben.

Architekturaspekte rund um Menschen und Organisationen

Nathaniel Schutta gab eine großartige Keynote zur Kommunikation von Softwarearchitekten: „Architect as storyteller”.

Zwei Aspekte hat er dabei insbesondere herausgearbeitet:

  • Zur Kommunikation braucht mal als Architekt (wie in anderen Rollen auch) klar herausgearbeitete Messages und eine konsistente Story. Ein Architekt muss ein „Keeper of Tales“ sein, er muss also viele gute Stories kennen. Dabei ist es nicht zwingend erforderlich, dass er die Story, die er erzählt selbst erlebt hat. Hauptsache es ist eine wahre Story, die sich gut zum Erklären eines bestimmten Sachverhalts eignet.
  • Je nach Zielgruppe muss man die Messages und die Story stark anpassen. Da der Architekt potentiell mit sehr vielen verschiedenen Zielgruppen / Stakeholdern (Manager, Kunden, Produktmanager, Projektleiter, Entwickler, Tester, …) arbeitet, muss entsprechend angepasst werden. Das verursacht zwar Aufwand, lohnt sich aber weil ansonsten die Message nicht verstanden wird und dadurch viele Probleme verursacht werden.

Nick Tune widmete sich dem Thema Organisationsgestaltung durch Architekten: „Great technical architects must be great organization architects”. Im Kontext von Microservices hat Conway’s Law wieder sehr viel Aufmerksamkeit bekommen. Nick Tune erläuterte anschaulich, wie die integrierte Gestaltung von Organisationsstrukturen und Softwarearchitekturen dafür sorgen kann, Reibung in der Entwicklung zu erkennen und zu vermeiden und damit schneller Software liefern zu können.

Dazu gab Nick konkrete Beispiele, welche organisatorischen Entscheiden mit Aspekten der Systemdekomposition zusammenspielen. Ankerpunkt war dabei natürlich Domain-Driven Design und Bounded Contexts.

Nick ging darüber hinaus auch auf das oft vorherrschende Bild von rein technischen Softwarearchitekten im Elfenbeinturm ein. Seinen Vortrag gestaltete er dann als Plädoyer für eine andere Art von Softwar

earchitekten (den Sociotechnical Architect), die sich ganzheitlichen Aufgaben widmen und trotzdem mit der gebotenen Demut an die Aufgabe herangehen.

Architecture Katas

Zum Abschluss der Konferenz gab es im großen Stil die Möglichkeit, an Architecture Katas teilzunehmen. Die Idee dabei ist, Architekten die Möglichkeit zu geben, Architekturarbeit zu üben …

Dazu die zwei folgenden Zitate:

  • „How do we get great designers? Great designers design, of course.“ –Fred Brooks
  • „So how are we supposed to get great architects, if they only get the chance to architect fewer than a half-dozen times in their career?“ –Ted Neward

Organisiert und moderiert waren die Katas durch Neil Ford. Die Aufgabenstellungen stehen auch online auf seiner Webseite.

Insgesamt konnten 30 Personen in 6 Gruppen aktiv teilnehmen und hatten 45 Minuten Zeit, um die Aufgabe so gut wie möglich zu bearbeiten. Die übrigen Teilnehmer waren Beobachter (oder unterhielten sich abseits bei Bier und Häppchen ;-)).

 

Matthias war beim Design in einer Gruppe dabei, Marcus war einer der Beobachter. Wir haben das in der Form zum ersten Mal gemacht und möchten gerne einige der Erfahrungen und Erkenntnisse von den Architecture Katas teilen.

Matthias als Teilnehmer am Design:

  • 5 Teilnehmer einer Architekturkonferenz haben mitunter sehr unterschiedliche Auffassungen davon, was Architektur ist und wie man zu einer Architektur kommt 😉
  • Man muss eigentlich alles diskutieren: Anforderungen, Scope der Aufgabe, Reihenfolge des Vorgehens, inhaltliche Architekturentscheidungen, Notationen, was soll überhaupt abgeliefert werden?, wer macht was?, …
  • Dadurch dass die Katas so kurz formuliert sind, bieten sie erheblichen Ausgestaltungsspielraum, den Informatiker / Architekten / Entwickler natürlich direkt erkennen und zu diskutieren wissen
  • Deshalb sind 45 Minuten wirklich kurz, um etwas auf die Beine zu stellen
  • Es hat nicht unbedingt der Recht, der am lautesten redet 😉
  • Die Aufgabe per Mikrofon weiter zu präzisieren, während 100 Leute schon arbeiten und reden, funktioniert nicht
  • Wenn man die Teilnehmer nach Ablauf der Zeit nicht zwingt, aufzuhören, dann machen sie noch 20 Minuten weiter während die ausgewählten Gruppen schon ihr Ergebnis präsentieren müssen
  • Es macht einen riesigen Unterschied, wer die Architektur letztlich vorstellt und wie gut er sie erklärt (insbesondere den Kontext, die Überlegungen, Einordnungen, Erklärungen, die alle nicht aufgeschrieben wurden in der kurzen Zeit)
  • 5 Leute sind für eine Gruppe zu viel, um gut voranzukommen. Eine Gruppengröße von 2-3 Leuten wäre besser geeignet

Architecture Kata Session as Observer - O'Reilly Software Architecture 2017

Marcus als Beobachter:

  • Alle 6 Gruppen sind sehr unterschiedlich vorgegangen.
  • Das fängt schon bei der Art und Weise an, wie sie Gruppen sich aufgeteilt haben. Allen 6 Gruppen stand ein großer Runder Konferenz-Dinner Tisch sowie 2 Flipcharts zur Verfügung. 2 Gruppen haben sich dazu entschieden, sich um die Flipcharts zu stellen (darunter auch die Gruppe von Matthias). Die anderen 4 Gruppen haben sich an die Konferenztische gesetzt.
  • Aus meiner Beobachtersicht heraus kamen die zwei Gruppen, die stehen geblieben sind, schneller voran.
  • Die Gruppen an den Flipchart haben auch mehr als ganze Gruppe diskutiert, wohingegen die Gruppen an den Tischen eher in Kleingruppen (2-3er) diskutiert haben.
  • Alle Gruppen haben direkt mit fachlichen Diskussionen angefangen. Keine der Gruppen hat sich mit „organisatorischen“ Dingen (direkt am Anfang) beschäftigt (z.B.: Welche Sichten benötigen wir? Sollen wir uns für Teilaufgaben aufteilen? Wer stellt am Ende das Ergebnis vor?)
  • Es ging wohl so richtig in allen Gruppen erst voran, als einer oder zwei Gruppenteilnehmer die Initiative übernommen haben.
  • Eine Gruppe hat sich sogar trotz der geringen Zeit von 45 Minuten dafür entschieden, einige Dokumente digital zu erstellen und nicht nur am Flipchart.
  • Die Repräsentation der Ergebnisse war auch völlig unterschiedlich. Dabei beziehe ich mich nicht nur darauf, was die Gruppen gezeigt haben, sondern auch wie sie es dargestellt haben.
  • Man sollte sich gerade in solchen „künstlichen“ Situationen auch direkt damit beschäftigen, wie das Ergebnis am Ende repräsentiert wird.
  • Auch die Wahl des Präsentators sollte gut ausgewählt werden, insbesondere, wenn es etwas zu gewinnen gibt.

Insgesamt waren die Architecture Katas eine sehr interessante Erfahrung. Wir können es Architekten und Entwicklungsteams nur empfehlen, solche Übungen auch zu machen. Dabei kann der Scope durchaus auch ausgeweitet werden, um auch das Zusammenspiel mit anderen Disziplinen wie Requirements Engineering oder User Experience Design zu üben. Der Vorbereitungs- und Zeitaufwand ist gering, dafür lernt man vieles und kommt zu zahlreichen Erkenntnissen über die Zusammenarbeit mit Kollegen.

Warum Beispiele so wichtig für den Erfolg sind (UX Day 2017)

Beispielhafter Erfolg & Beispiellose Niederlage – Warum gute Beispiele so wichtig für den Erfolg eigener Ideen sind habe ich in meinem Talk beim UX Day 2017 in Mannheim vorgestellt.

Am 10.10.2017 fand wieder der UX Day in Mannheim in der Alten Feuerwache statt. Ich bin ein großer Fan der Veranstaltung und wurde auch in diesem Jahr wieder nicht enttäuscht. Bei der Closing Keynote gab es sogar „Zugabe“-Rufe, was auf Konferenzen eher nicht der Fall ist. Auch in 2017 war ich wieder mit einem Vortrag vertreten. Worum es ging, erfahrt ihr hier und den Link zum Vortragsvideo findet ihr unten:

Marcus Trapp beim UX Day 2017 in Mannheim, Alte Feuerwache

„Hast du mal ein Beispiel, damit ich es besser verstehen kann?“, „Wie muss ich mir das vorstellen, zeigst du das noch am Beispiel?“, „Das hast du aber sehr vereinfacht erklärt, hast Du noch ein realitätsnahes Beispiel?“ – Diese oder ähnliche Aussagen sind oft die ersten Reaktionen auf die Präsentation einer neuen Idee. Obwohl wir selbst den Präsentierenden oft als Erstes nach einem guten Beispiel fragen, vergessen wir bei unseren eigenen Präsentationen gerne, wie wichtig gute Beispiele sind, um andere von unseren neuen Ideen zu überzeugen. Der Vortrag zeigt, warum „Lorem Ipsum“, „Max Mustermann“, „Unternehmen 1“ und „Kundengruppe A“ nicht ausreichen, um andere für die Umsetzung eigener Ideen zu begeistern.

Oft sind es gute Beispiele, die über den Erfolg oder Misserfolg einer Idee entscheiden. Verwenden wir keine oder schlechte Beispiele, wenn wir unsere Ideen anderen erklären, so stoßen wir oft auf Missverständnis oder gar Unverständnis. Da wir uns selbst so lange mit der Idee beschäftigt haben, fällt uns das Fehlen von Beispielen oft gar nicht so leicht auf, da wir selbst kein Beispiel (mehr) benötigen. Wenn wir jedoch Pech haben, dann wird unsere Ideen direkt nach unserer Präsentation abgelehnt, ohne dass wir die Chance haben, die Idee noch einmal besser zu erklären. Wenn wir Glück haben, dann werden wir direkt nach einem guten Beispiel gefragt, um unsere Ideen zu illustrieren oder zu visualisieren. Dann müssen wir jedoch spontan reagieren und uns ein Beispiel ad hoc überlegen. Das funktioniert meistens nicht gut. Denn gute Beispiele für die Erklärung von neuen Ideen zu erstellen ist harte Arbeit. Es ist meist ein langwieriger Prozess, bei dem viel ausprobiert werden muss. Ein gutes Beispiel muss „groß genug“ sein, um realitätsnah zu sein und nicht direkt als „vereinfachter Spezialfall“ abgehandelt zu werden. Eine moderate Komplexität ist zudem wichtig, um ein oft gewünschtes „durchgängiges Beispiel“ zu erhalten, dass uns erlaubt, die Idee aus unterschiedlichen Blickwickeln zu zeigen und möglichst vielen Facetten zu beleuchten. Das Beispiel muss aber auch klein genug sein, dass wir nicht die ganze Vortragszeit benötigen, um das Beispiel zu erklären. Die Realitätsnähe zum tatsächlichen Anwendungsfalls ist immens wichtig. Warum „Max und Maria Mustermann“, „Lorem Ipsum“, „Unternehmen 1“ und „Kundengruppe A“ daher nur bedingt geeignet sind, um gute Beispiele zu erstellen und worauf wir noch achten müssen, um unsere Ideen zu beispielhaften Erfolg zu führen, wird im Vortrag aufgezeigt.

Auch in diesem Jahr gab es wieder sehr viele gute Vorträge. Insbesondere möchte ich euch die folgenden Vorträge ans Herz legen:

Wenn euch mein Vortrag gefallen (oder auch nicht) oder wenn ihr Anregungen und Fragen zum Thema habt, dann schreibt einfach einen Kommentar.

Interview: „Fähnchen statt echter Digitalisierung“

Am 29. November sprechen wir bei der Cloud Expo Europe.

In der Vorbereitung gaben wir ein Interview zu den Themen Softwarearchitektur, User Experience und Digitale Transformation:

„Fähnchen statt echter Digitalisierung“

 

On Tour: Cloud Expo Europe, Frankfurt, 2017

Am 28. und 29. November 2017 findet in Frankfurt die Cloud Expo Europe statt. Wir sind mit einem Vortrag zu Softwarearchitektur und User Experience dabei.

Wie finden Softwarearchitekten den Weg zu User Experience? Mit Google Maps!

Eine hervorragende Softwarearchitektur und eine tolle User Experience sind zentrale Erfolgsfaktoren von  Softwaresystemen. Der Vortrag betrachtet das Spannungsfeld zwischen diesen beiden Bereichen. Dabei gehen wir nicht nur auf die durchaus unterschiedlichen Personengruppen der Softwarearchitekten und UX Designer ein, sondern betrachten auch den Zusammenhang und die Tradeoffs zwischen tollen UX Konzepten und technischen Konzepten, die zur Umsetzung benötigt werden. Wir illustrieren am Beispiel von Google Maps, welche architektonischen Höchstleistungen notwendig sind, um die Google-Experience zu erreichen, das heißt: Google-typische Einfachheit zu gewährleisten und Google-typische Mega-Dienste überhaupt zu ermöglichen. Der Vortrag zeigt auf, wie trotz der unterschiedlichen Charaktere von Architekten und UX Designern großartige Systeme erschaffen werden können.

Unser Vortrag ist am 29. November um 13:10 .

Dazu gibt es auch ein Interview mit uns.

« ältere Beiträge

© 2018 mibinu

Theme von Anders NorenNach oben ↑