Die SATURN 2020 findet dieses Jahr vom 11. bis 14. Mai in Orlando statt. Das Programm ist wieder voller Highlights für Softwarearchitekten. Wir freuen uns sehr, auch mit zwei Vorträgen dabei sein zu dürfen.
Most of the time, machine learning (ML) is strongly viewed from a data science perspective. This means, you can find tons of information on algorithms and the treatment of data. However, what it actually means to architect systems, in which ML plays a role, is rather rarely found. Our focus is on the engineering of typically large systems, which are, to some degree, basing their functionality on machine learning. As such systems often serve in production large amounts of users, the fulfillment of quality attributes is critical and needs consideration in architecture design.
In this talk, we systematically decompose in the language of software architects what it means to build a system based on machine learning. We outline an architectural design space and discuss central architecture decisions an architect has to make when designing a system based on ML.
This includes a perspective on both, the development time, and the runtime.
We show how a system can be decomposed and how machine learning components look like and behave in the context of an overall system.
Machine learning is fundamentally depending on data: ; Thus, the data aspect is central in our architectural considerations.
As neural networks are very widespread nowadays for the realization of ML-based systems, we take a closer look at their architectural implications.
We include a perspective on the activities around data collection, preparation, model selection and training, and model inference.
We discuss deployment options for model training and model inference.
We discuss different types of technologies available for machine learning, from as-a-service APIs over pre-trained models down to pure libraries requiring to construct and to the train the full model.
With this overview, architects will get the big picture of designing ML-based systems and have a much better position to bridge the gaps between data scientists, data engineers, and software developers and architects.
Digital ecosystems and platform economy are based on a strong interconnection across organizations and allow for completely new business models. They conquer more and more areas of business and private life and companies feel the pressure to reason about new opportunities.
An integrated perspective on business, technological, and legal aspects is needed. However, there is no clear method how to shape such new digital ecosystems, neither in the business world nor in the software world.
While everyone acknowledges that this is a challenging task it often remains the question who could do it. We found that software architects can be promising candidates for ecosystem shaping as they should be used to seeing the big picture and designing in the large. However, what is needed goes far beyond the standard skill set of software architects.
We report from ecosystem projects and our experiences across many domains like banking, automotive, farming, smart city, etc. Our goal is to:
make the audience interested in the world and business of digital ecosystems
give them a clear terminology to talk about digital ecosystems and the describe them
show architects what new challenges could be in front of them and how they can develop their career path
demystify the term “platform”: everything seems to be a platform — we present a proven classification of platform terms that are helpful in the context of digital ecosystems
give dos and don’ts in the shaping of digital ecosystems
outline new roles that are needed when creating digital ecosystems
Wir freuen uns sehr, bei der OOP 2019 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 2019: „Care for the future“.
Plattformökonomie verändert die Zusammenarbeit von Unternehmen geschäftlich, rechtlich und technisch, insbesondere wenn das ausgetauschte Gut auch Daten mit Personenbezug sein können. Wir berichten zu Herausforderungen und Lösungsansätzen zur rechtmäßigen Datenverarbeitung, u.a. Consent Handling, aus dem Aufbau der B2B-Datenplattform Caruso. Neben den rechtlichen Vorgaben (GDPR) müssen unterschiedlichste Anforderungen der Partner berücksichtigt werden, z.B. hinsichtlich Anonymität von Datenverarbeitern zum Schutz von Geschäftsgeheimnissen.
Die Sicherstellung der Rechtmäßigkeit der Datenverarbeitung ist eine essenzielle Aufgabe bei der Entwicklung jedes Systems, das personenbezogene Daten verarbeitet, insbesondere seit Inkrafttreten der Europäischen Datenschutz-Grundverordnung (DSGVO). Ohne entsprechende Lösungskonzepte kann das System seine Aufgabe nicht erfüllen oder es drohen empfindliche Strafen für die Unternehmen. Architekten, die Systeme entwickeln, sind also in den meisten Fällen irgendwann mit dieser Aufgabe konfrontiert. Die Erarbeitung solcher Lösungen bedeutet häufig eine Auseinandersetzung mit der rechtlichen Materie und intensive Zusammenarbeit mit Anwälten und Datenschützern. Diese Aufgabe wird noch herausfordernder in softwarebasierten Ökosystemen, in denen viele Partner zusammenkommen und durch verschiedene Beiträge voneinander profitieren.
Wir bauen seit zwei Jahren die B2B-Datenplattform Caruso auf, in der verschiedene Unternehmen effizient Daten aus der Automobildomäne austauschen können, insbesondere kann mit Zustimmung des Fahrzeugnutzers ein Zugriff auf Telematikdaten für Dienstleister ermöglicht werden. Die Sicherstellung der Rechtmäßigkeit der Verarbeitung personenbezogener Daten für die Plattform, aber auch für alle Partner ist dabei von zentraler Bedeutung. Wir haben dafür unterschiedliche Lösungsansätze entworfen und hinsichtlich unterschiedlichster Anforderungen der Partner technisch und rechtlich bewertet.
In diesem Vortrag möchten wir unsere Ergebnisse mit interessierten Architekten, Entwicklern und Entscheidern teilen. Dafür führen wir zwar einige Grundbegriffe der DSGVO ein, fokussieren uns aber auf das Design der technischen Lösungsansätze. Diese diskutieren wir anhand von illustrativen Beispielen, mit ihren Vor- und Nachteilen. Die Teilnehmer erhalten so einen Werkzeugkasten zur Umsetzung der rechtmäßigen Verarbeitung personenbezogener Daten in ihren eigenen Systemen.
Der Vortrag von Dominik Rost und Matthias Naab berichtet aus der Zusammenarbeit zwischen der Caruso Dataplace GmbH und Fraunhofer IESE. Wir werden auch gemeinsam bei der OOP den Vortrag halten.
Digitale Ökosysteme sind komplexe Konstrukte und schwer zu überblicken. Technologische, geschäftliche und rechtliche Auswirkungen sind ungleich schwerer zu verstehen, wenn Produkte und Services unternehmens- und branchenübergreifend gestaltet werden. Vielen Unternehmen fehlt der Blick auf das große Ganze und das erschwert Entscheidungen. Der Vortrag beschreibt die Methode „Tangible Ecosystem Design“ zur Definition, Gestaltung und Analyse von Digitalen Ökosystemen mithilfe von Playmobil®-Spielzeug und macht das Ökosystem damit „greifbar“.
Die digitale Transformation fast aller Industriezweige führt zu einem disruptiven Wandel. Die Platform-Economy ist in vollem Gange. Mehr und mehr Digitale Ökosysteme (Software-Ecosystems, Software-enabled Ecosystems, Smart Ecosystems usw.) entstehen, in denen Unternehmen aus verschiedensten Branchen auf einer gemeinsamen Plattform ihre Produkte und Services anbieten.
Durch die Kombination dieser Produkte und Services entstehen für Kunden und Nutzer der Plattform Vorteile, die keines der beteiligten Unternehmen alleine hätte erzeugen können. Somit stehen immer mehr Unternehmen vor der Frage, ob sie sich an einem Ökosystem beteiligen sollten und wenn ja, in welchem Ökosystem und in welcher Rolle sie auftreten sollen. Digitale Ökosysteme sind ungleich komplexer zu verstehen als Software Systeme, die unter der alleinigen Kontrolle eines einzelnen Unternehmens stehen. Die technologischen (Technology), geschäftlichen (Business) und rechtlichen (Legal) Auswirkungen sind ungleich schwerer zu verstehen, wenn Produkte und Dienstleistungen unternehmens- und branchenübergreifend gestaltet werden sollen.
Viele Unternehmen betreten zudem im Rahmen der Digitalen Transformation dabei aus ihrer Sicht Neuland und benötigen umfassendere Unterstützung als bei der Entwicklung klassischer Softwaresysteme. Die Gestaltung Digitaler Ökosysteme erfordert darüber hinaus Kompetenzen, die weit über das klassische System- und Software-Engineering hinausgehen, um die zentralen Herausforderungen beherrschen zu können.
Die Beherrschung dieser Auswirkungen bewirkt eine neue Dimension der Komplexität der Gestaltung von Software-Systemen und erschwert somit die Entwicklung von Ökosystemen und die damit verbundene User Experience:
• Vielfalt:
Ökosysteme bestehen aus einer Vielzahl von Entwicklungsorganisationen, heterogenen Technologien, einem Mix aus technischen Methoden und unterschiedlichen (teilweise widersprüchlichen) Geschäfts- und Nutzerzielen. Der Modellierungs- und Priorisierungsaufwand für das Verstehen und Beherrschen von Nutzer- bzw. Systemanforderung ist immens.
• End-to-End-Qualität:
Innerhalb eines Ökosystems sind viele Teile nicht mehr unter der Kontrolle einer Software-Entwicklungsorganisation, die den Ökosystem-Konsumenten betreut, aber dennoch muss eine durchgängige Qualität erreicht werden. Obwohl viele Unternehmen das System beeinflussen, möchten Benutzer sie als einen Service wahrnehmen und benutzen.
• Unsicherheit:
Ökosysteme entwickeln sich dynamisch und werden von vielen unabhängigen Akteuren in ihrem eigenen Tempo vorangetrieben. Manche Entscheidungen beruhen auf unvollständigen Anforderungen oder auf Einschätzungen über die Weiterentwicklung der Nutzerbedürfnisse. Diese müssen aber systematisch aufgenommen und hinterher überprüft werden.
In den letzten Jahren haben wir mehr als 20 Ökosystemprojekte durchgeführt. Dabei sind uns verschiedene Herausforderungen bei der Modellierung von Ökosystemen wiederholt begegnet:
• Große Anzahl und Typen von Rollen führen zu unklaren Zusammenhängen in Ökosystemen
• Unklare Beziehungen zwischen den Akteuren im Kontext eines Dienstes und seinen Konsumenten
• Die Auswirkungen einer (kleinen) Veränderung auf das gesamte Ökosystem sind schwer zu erkennen
• Schwer, das „Big Picture“ (Business, Technology, Legal) des gesamten Ökosystems im Auge zu behalten (und im Fokus), während man an einem der vielen Details arbeitet
• Unklare Einflüsse von Service-Regeln auf das gesamte Plattformgeschäft
• Es existieren keine Tools zur Diskussion des Plattform- und Servicedesigns im (interdisziplinären) Team
• Unreife und komplexe Modellierungssprachen für Ökosysteme
Um diese Herausforderungen zu meistern, haben wir die Methode „Tangible Ecosystem Design“ entwickelt. Unsere Methode fördert die Zusammenarbeit bei der Definition, Gestaltung und Analyse eines Digitalen Ökosystems und das mithilfe von Playmobil®-Spielzeug, was die Konzeption greifbar für die Teilnehmer macht. In Workshops können die Teilnehmer mit Playmobil und geeigneten Templates ein Digitales Ökosystem modellieren und es damit im wahrsten Sinne des Wortes „greifbar“ machen.
Ziel der Methode „Tangible Ecosystem Design“ ist es, in einem interaktiven Workshop mit verschiedenen Plattform-Playern (Stakeholder) die Modellierung eines Ökosystems, einschließlich der Plattform, ihrer Services und ihrer Akteure, zu unterstützen.
Als Teil der methodischen Anleitung wurden Modellierungselemente definiert, sodass Benutzer immer das gleiche Playmobil®-Element benutzen können, um verschiedene Services und Beziehungen darzustellen.
Die Hauptbausteine der Methode und die zugehörigen Templates werden im Vortrag vorgestellt, so wie die verschiedenen Templates angewendet. Hierzu werden zunächst eine Definition der Ziele des Ökosystems und die Philosophie des Ökosystems erfasst. Danach werden die verschiedenen Services identifiziert und in verschiedene Abstraktionsebenen modelliert. Anschließend werden die verschiedenen Akteure (Unternehmen in verschiedenen Rollen) eines Ökosystems identifiziert und dazu im Detail beschrieben. Als Abschluss werden alle Plattform spezifische Aspekten festgehalten.
Dieser Vortrag wird von Claudia Nass und Marcus Trapp gehalten.
Wir freuen uns auf eine spannende Konferenz und viele interessante Diskussionen und tiefgehenden Austausch. Hier geht es zum vollständigen Konferenzprogramm.
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!
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.
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.
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“.
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.
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.
Wir freuen uns auf eine spannende Konferenz und viele interessante Diskussionen und tiefgehenden Austausch. Hier geht es zum vollständigen Konferenzprogramm.
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.
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)
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
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
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.
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.
Neueste Kommentare