Languages that raise the level of abstraction closer to the problem domain help improve quality and productivity. This can be best achieved when the language is directly based on the problem domain, not implementation concepts or existing languages. We describe how to create domain-specific languages in tight collaboration with domain expert users: as soon as a language concept is defined it can be immediately applied by users. We demonstrate this with examples from various fields, such as automotive, home electronics and automation systems.

Target Audience: Developers, subject matter/domain experts, managers
Prerequisites: experiences on applying some modeling language
Level: Advanced

Extended Abstract:
This talk is based on industry experiences on applying domain terminology directly in a modeling language (in its grammar). This way domain experts can apply familiar terminology, and map the specifications directly to code, to other more technical models, or the same set of models are shared by both domain experts and developers. The talk starts with a practical example how domain experts from different fields can collaboratively edit the same specifications each having own background (industry process, software, hardware, communication). Next the talk describes guidelines how such languages can be created: how domain terminology is defined into a language and how such language can be applied. These guidelines are demonstrated with examples from practice, such as how functional safety engineers can collaborate using ISO26262 (functional safety standard) terminology and related them to the technical system development; and how UX and UI persons can define user interfaces and their behavior in a manner allowing developers to join and work with the same models. The talk is concluded with guidelines and hints backed by industry cases from companies like Panasonic and Elektrobit.

Moderne Cloudarchitekturen ermöglichen es, via Quellcode IT-Landschaften versioniert abzulegen und jederzeit automatisiert auf- und abzubauen. Mit dem Einsatz von Templates können Aspekte wie Sicherheit projektübergreifend genutzt und adressiert werden.

Anhand von praktischen Beispielen werden Prinzipien für eine betreibbare und wartbare Infrastrukturautomatisierung erläutert, beispielsweise Modularisierung von Infrastrukturelementen, Trennung von Konfiguration und Automatisierung sowie Lebenszyklen für Build, Deployment und Staging.

Zielpublikum: DevOps Engineer
Voraussetzungen: Grundlegendes Verständnis von DevOps
Schwierigkeitsgrad: Anfänger

Extended Abstract:
AWS, Openstack oder Azure - es ist heutzutage sehr einfach, Infrastruktur per GUI zusammenzustellen. Eine so aufgesetzte Infrastruktur ist aber nicht robust gegen Fehler und anfällig für Fehlbedienung. Im schlimmsten Fall kann die aufgebaute Infrastruktur nach einem Fehler oder Ausfall nicht mehr hergestellt werden - ein Szenario, das für eine Produktivumgebung undenkbar und höchst kritisch wäre.

Dieser Vortrag soll dazu motivieren, Infrastruktur analog zu Softwareständen als Code abzulegen und somit nachvollziehbar und reproduzierbar zu machen.

Begleiten wir in einer interaktiven Geschichte unseren Protagonisten auf seiner Reise von der Produktvision bis zum ersten Release einer beispielhaften App.

Anhand eines griffigen Fallbeispiels gestalten wir gemeinsam ein Produkt, unterstützt durch etablierte Praktiken aus dem Produktmanagement. Iterativ, inkrementell und mit einem Augenzwinkern.

Weil uns die heile Welt zu vorhersehbar ist, wird die Reise gewürzt von Änderungen und Überraschungen, die am Ende alle eines gemein haben: Die Beteiligten haben es lediglich gut gemeint.

Zielpublikum: Product Manager, Product Owner und neugierige Menschen in der Software-Entwicklung
Voraussetzungen: Grundlegendes Verständnis von Softwareproduktentwicklungen
Schwierigkeitsgrad: Fortgeschritten

Eine wesentliche Auswirkung beim Einsatz einer Microservice-Architektur ist, dass ein großer Teil der Kommunikation zwischen den einzelnen Komponenten über das Netzwerk erfolgt. Um die Vorteile dieses Architekturstils auch wirklich nutzen zu können, dürfen die einzelnen Microservices lose miteinander gekoppelt sein. In dieser Session lernen Sie die grundlegenden Integrations-Muster kennen, und sehen anhand eines konkreten Szenarios, wie Sie diese Patterns zu einer funktionierenden Anwendung verknüpfen können.

Zielpublikum: Architects, Developers
Voraussetzungen: Basic architectural knowledge
Schwierigkeitsgrad: Fortgeschritten

SAP-Projekte werden häufig von Unsicherheiten zum Testumfang sowie langen Testphasen, die die Fachseite blockieren, begleitet.

Um mit diesen Herausforderungen umgehen zu können, wurde im Rahmen eines Projektes eine zusätzliche Testphase eingeführt. In dieser wurde das System, vom verantwortlichen Testmanagement, vor Übergabe an die Fachseite getestet.

Dies war ein ungewöhnlicher Schritt, da SAP als ein System gilt, welches nur von Key-Usern und SAP-Expert:innen getestet werden kann. In diesem Vortrag teilt die Referentin ihre Erfahrung mit diesem Vorgehen.

Zielpublikum: Test-, Projektmanager:innen, Projektleiter:innen, Entscheider:innen
Voraussetzungen: Grundsätzliches Verständnis von Testmanagement
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Komplexität von SAP-Projekten ergibt sich durch die Anzahl der betroffenen SAP-Module und ihrer Schnittstellen zu anderen Systemen sowie der Summe der betroffenen Gesellschaften, Länder oder Werke.

Projektteams sehen sich hier vielen Herausforderungen gegenüber, eine davon ist der Testbereich. Sicher, SAP-Expert:innen prüfen die von ihnen angepassten Funktionalitäten technisch und Key-User testen Geschäftsprozesse aus Anwendersicht, doch gerade bei Customizing Einstellungen und individuellen Erweiterungen ergeben sich für alle Beteiligten schnell Unsicherheiten zur Testdurchführung.

Zumeist stellen sich Fragen wie:

• Was soll getestet werden?
• Sind die notwendigen Berechtigungen und Rollen bekannt?
• Wie verhindern wir Redundanzen und stellen sicher, dass die richtigen Testfälle getestet werden?
• Wie managen und bereinigen wir Testdaten?

Die Implementierung eines standardisierten Testmanagement-Prozesses schafft die nötige Transparenz, um Fachabteilungen und ihre Anforderungen zu steuern.

Im Rahmen eines Projektes wurde das System, vor Übergabe an die Fachseite, zusätzlich durch das Testmanagement-Team manuell getestet. Die Rolle des Testmanagers ähnelte damit eher der eines agilen Testers, mit planerischen und operativen Aufgaben. Dieses Vorgehen brachte Vorteile aber auch Herausforderungen mit sich.

Beispielsweise wurde zur Vorbereitung der Testfallerstellung ein Review der Anforderungsdokumente durchgeführt. Hierbei entstanden Fragestellungen, durch deren Klärung die Qualität der gelieferten Software deutlich erhöht werden konnte.

Aber auch in der Testdurchführung ergaben sich spannende Erfahrungswerte. Um mit dieser zusätzlichen Testphase wirkliche Mehrwerte liefern zu können, war eine zeitintensive Abstimmung zwischen Fachseite und Testmanagement entscheidend.

In dieser Session teilt die Referentin ihre Erfahrungswerte zu Herausforderungen und möglichen Lösungen, welche sich durch die Nutzung von Testmanagement in SAP-Projekten ergeben.

Miltenyi Biotec ist ein global agierendes Biotechnologie- und Biomedizin-Unternehmen. Es ist der führende Anbieter von Produkten zur magnetischen Zellsortierung und -analyse (MACS). Die Firma ist eines der größten deutschen Unternehmen der Biotechnologie-Branche.

Die Metapher „Software-Architektur“ wirkt oft sehr abstrakt, und man könnte manchmal das Gefühl bekommen, sie stehe für Entwicklungsabteilungen, die sich lieber mit sich selbst als mit den Anforderungen von Nutzenden und Fachabteilungen beschäftigen. Tatsächlich aber ist die Architektur unserer Systeme der entscheidende Erfolgsfaktor für eine erfolgreiche Digitalisierung. In diesem Vortrag werden wir diskutieren, welche Rolle Architektur für Entscheiderinnen und Entscheider spielt, wie sie sie beeinflussen können und von ihr beeinflusst werden und wie dazu eine kluge Arbeitsteilung zwischen Management, Entwicklung und Usern gestaltet werden kann.