Forward Deployed Engineer – Das Schweizer Messer der Softwareentwicklung

Der Innovationsgrad der Softwareindustrie ist hoch. Regelmäßig entstehen neue Technologien und Methoden, die meist auf bestehendem aufbauen, mit dem Ziel die Herstellung von Software zu erleichtern und zu beschleunigen. Neue Methoden bringen oft neue Rollen hervor, die an die aktuelle Technologie- und Methodenlandschaft angepasst sind. Im Zuge agentischer Softwareentwicklung begegnen wir zunehmend der Rolle des Forward Deployed Engineer.

Dieser Blogpost betrachtet diese Rolle aus verschiedenen Perspektiven und bettet sie ein in bestehende Strukturen. Dazu müssen wir etwas ausholen:

Rollen und Zusammenarbeit

Zu den klassischen Rollen, die wohl jeder kennt, gehören Analyst, Projektleiter, Architekt, Entwickler oder Tester. Diese Rollen sind eher zeitloser Natur und stammen aus einer Zeit in der Softwareentwicklung als primär industrieller Prozess verstanden wurde. Sie sind bis heute gebräuchlich.

Die agile Bewegung hat seit Beginn der 2000er Jahre moderne, angepasste Rollen wie Product Owner, Scrum Master, Release Train Engineer (SAFe), Flow Master (Kanban) oder Full Stack Developer und Data Scientist im Bereich der Technik und des maschinellen Lernens hervorgebracht, um nur einige hervorzuheben. Sie sind abgestimmt auf Arbeiten in komplexen Zusammenhängen, wie wir sie in Softwareentwicklungsprojekten in der Regel vorfinden.

Im Kontext agentischer Softwareentwicklung erhält die Rolle des Forward Deployed Engineers und zunehmend an Aufmerksamkeit. Aber wozu definieren wir eigentlich Rollen?

Grundsätzlich dienen Rollen dem Zweck Aufgaben und Verantwortlichkeiten zu benennen, damit jeder, zum Beispiel im Rahmen eines Projektes, genau weiß was zu tun ist. Zudem erleichtern diese Schablonen die Beschreibung von Aufgabenfeldern im Rahmen der Personalgewinnung.

So hilfreich diese Schablonen sein können, um Klarheit in die Personalstruktur und Erwartungshaltungen zu bringen, so hinderlich können sie sein, wenn es darum geht Projektziele zu erreichen. Wer schon einmal den Satz “Das ist nicht meine Aufgabe” gehört hat, weiß, was damit gemeint ist.

Im Sinne einer gemeinschaftlichen und kooperativen Zusammenarbeit geht es weniger darum Rollen zu erfüllen, sondern anstehende Aufgaben mit den vorhandenen Fähigkeiten zu erledigen. Dabei spielt es eine untergeordnete Rolle, ob beispielsweise Softwaretests von Analysten, Architekten oder Entwicklern durchgeführt werden oder User Stories vom Product Owner oder Tester geschrieben werden. Es geht um das zu erreichende Ziel, nicht um die Erfüllung von Rollen. Teams mit hoher Kompetenzüberlappung sind dadurch flexibler, resilienter und schneller, weil es weniger Wartezustände an den Rollenübergängen gibt.

Die Idee des crossfunktionalen Arbeitens und Anwendernähe zieht sich wie ein roter Faden durch den Werkzeugkasten moderner Methoden. Wir finden es gleichermaßen in agilen Frameworks, DevOps oder auch Design Thinking. Konsequent gedacht arbeiten die Personen der Softwareentwicklung direkt mit Anwendern zusammen. Sie sehen und erfahren aus erster Hand, wie die Anwender arbeiten und beziehen sie stark mit ein. Ein Ansatz den wir beispielsweise in den Service Safaris des Design Thinking finden. Lösungsansätze werden direkt mit den Anwendern entwickelt und bewertet. Begriffe dafür kennen wir schon. Beispielsweise Embedded-IT, Customer Engineer, On-site-Engineer oder Field Engineer gehören dazu. In der Praxis sehen wir das eher selten. Vermutlich liegt es daran, das sie nicht gut in bestehende Aufbauorganisationen passen. Eine Faktor, der auch bei Forward Deployed Engineers eine Rolle spielt.

Was ist nun ein Forward Deployed Engineer?

Ein Forward Deployed Engineer (FDE) oder auch Forward Deployed Software Engineer ist ein Software Engineer mit maximaler Anwendernähe. Der Name der Rolle ist entstanden im Umfeld der großen AI Anbieter, die einen Weg suchten Softwarelösungen auf schnelle Art mit Hilfe von AI zu entwickeln. Entlehnt dem Militärjagon bedeutet es soviel wie Einsatz an der Front, was mir nicht sehr passend erscheint, da FDEs in Organisationen eher im Freundesland agieren. FDEs entwickeln Software innerhalb einer Organisation mit großer Nähe zu den Fachbereichen und ausgeprägter Hands-On Ausrichtung. Die Rolle kombiniert viele Fähigkeiten mit dem Ziel passgenaue Software in kürzester Zeit zu erstellen.

Zu den zentralen Fähigkeiten gehören:

🔹Anforderungsanalyse
🔹Konzeption und Softwareentwicklung
🔹Software Engineering
🔹AI Harness Engineering
🔹Soziale und kommunikative Fähigkeiten
🔹Empathie, Neugier, Flexibilität, Lernbereitschaft
🔹Präsentation und Moderation

Wie wir sehen ist die Rolle ist sehr breit angelegt und umfasst viele Fähigkeiten. In der Regel wird sie von Personen ausgefüllt die über ein PI-Profil charakterisiert sind. Also Generalisten mit partiellen Spezialisierungen und der Fähigkeit sich in kurzer Zeit in neue Themen, seien sie fachlich oder technisch, einzuarbeiten. Wie bei einem Schweizer Messer vereinen sich viele Funktionen in einem Werkzeug. Eine Rolle, die nur von sehr erfahrenen Engineers ausgefüllt werden kann.

Obwohl die Erfinder dieser Rolle sicher AI als treibende Kraft im Sinn hatten, ist der Einsatz agentischer Techniken eigentlich nicht zwingend. Jedoch beschleunigt der Einsatz von AI in dieser Rolle die Erstellung von Artefakten und hilft dabei schnell zu Lösungen zu kommen. Insbesondere bei Aufgaben, die nicht unmittelbar final produktionsfähige Software betreffen, wie beispielsweise Fachliche- und Codeanalyse, Prototyping, Visualisierung oder Sparring, ist AI ein Werkzeug, um die Entwicklung digitaler Produkte stark zu beschleunigen und die Passung zu erhöhen.

Diese Aufgaben charakterisieren die Tätigkeit eines FDE:

🔹Analyse und Dokumentation fachlicher Anforderungen
🔹Analyse bestehender Codebasen
🔹Context und Harness Engineering
🔹Erstellung technischer Lösungskonzeptionen
🔹Erstellung von Prototypen und Machbarkeitsstudien
🔹Entwicklung produktionsreifer Lösungen
🔹Anwendung agiler und agentischer Entwicklungsmethoden
🔹Beratung zu technischen und methodischen Fragestellungen
🔹Präsentation von Ergebnissen auf allen Ebenen der Organisation

Der wesentliche Faktor ist dabei die Nähe zu den Anwendern, hohe Transparenz, sowie schnelle Rückkopplungsschleifen. Prinzipien, die wir aus dem agilen Werkzeugkasten als Inspect & Adapt kennen und die sich vielfach bewährt haben.

Herausforderungen

Forward Deployed Engineers erfordern hohen Gestaltungsspielraum, Experimentierfreude und schnelle Entscheidungen. In Organisationsstruktur und Kulturen, in denen das nicht gegeben ist, können FDEs ausgebremst werden und keine starke Wirkung entfalten. Eine Build-To-Learn-Kultur ist für viele noch immer ungewohnt. Es ist zu klären, wie weit die Bereitschaft dazu reicht.

Insbesondere bei intensivem Einsatz von AI besteht das Risiko von Wissenserosion und kognitiver Schulden. Es ist darauf zu achten, das insbesondere geschäftskritische Artefakte von den Mitarbeitenden verstanden und ohne den Einsatz von AI gepflegt und weiterentwickelt werden können. Dies kann durch Context Engineering erreicht werden, welches das Ziel verfolgt Wissen und Wahrheit für Menschen und Maschinen gleichermaßen zu strukturieren und zugänglich zu machen.

Die Qualität der entstehenden Software ist von Menschen sicherzustellen, damit sie die Möglichkeit haben Verantwortung für die Software zu übernehmen und in kritischen Situationen zu agieren. Statt möglichst schnell möglichst viel Code zu erzeugen ist darauf zu achten, das die Menschen des soziotechnischen Systems Verantwortung übernehmen können. Das Prinzip des Sustainable Pace, also nachhaltiger Liefergeschwindigkeit gilt auch hier.

Da die Entwicklung zusammen mit den Anwendern der Fachbereiche beziehungsweise Domänen erfolgt, liegt der Fokus zunächst auf lokalen Lösungen. Es ist zu beachten, in wie weit sich diese in die bestende Produkt- und Systemlandschaften einfügen und wie sich statt Insellösungen integrative Ansätze erreichen lassen.

Einschätzungen

Insgesamt erscheint der Forward Deployed Engineer eine sinnvolle Rolle, um dem Ziel guter Software in kurzer Zeit näher zu kommen. AI kann bei vielen Aufgaben sinnvoll unterstützen. Im Kern steht die enge und vertrauensvolle Zusammenarbeit der Menschen im System der Softwareentwicklung. Dieser wichtige Aspekt ist im agilen Kontext seit langem bekannt und nachgewiesenermaßen ein entscheidender Erfolgsfaktor. Das passt also. FDEs sind Senior Engineers die eingebettet bei und mit den Kunden arbeiten. Gewissermaßen sind Forward Deployed Engineers wie ein Schweizer Messer, da sie viele Fähigkeiten in sich vereinen. Diese Rolle ist anspruchsvoll. Sie auszufüllen erfordert viel Erfahrung und Seniorität. Ein Faktor, der die Besetzung sicher nicht erleichtert.

Vielleicht ergeben sich durch Forward Deployed Engineers und dem Schwung des Themas neue Möglichkeiten die Kultur der Softwareentwicklung weiter zu verbessern und das immerwährende Ziel zu erreichen: Nutzenbringende Software herzustellen. In hoher Qualität und kurzer Zeit.

Was kann PLEUS Consulting tun?

Seit über 30 Jahren unterstützen wir Unternehmen in allen Phasen des Software Delivery Lifecycles. Wir wissen aus Erfahrung das intensive, vertrauensvolle Zusammenarbeit der Schlüssel ist. Wir durften es vielfach erleben und gestalten. Oft haben wir direkt mit den Anwendern der Fachbereiche gearbeitet und gemeinsame Erfolgsgeschichten geschrieben. Durch die Unterstützung von Startups und DAX-Konzernen in verschiedenen Branchen sind wir mit den kulturellen Unterschieden in den Unternehmen bestens vertraut und stellen uns auf deren Besonderheiten ein.

Durch unsere langjährige Erfahrung und systemisch-agile Haltung sind wir der ideale Partner wenn es darum geht anspruchsvolle Software im geschäftskritischen Umfeld zu entwickeln.


Der Autor setzt AI situativ ein wo es Sinn macht. Dieser Text ist vollständig ohne Einsatz von AI entstanden. Warum? Schreiben ist Denken! Denken macht Spaß! Innovation entsteht nicht durch Replikation! Kreatives und systemisches Denken vergrößert den Lösungsraum!

Headerbild von Clker-Free-Vector-Images auf Pixabay

Artikel: Mit System zu besserer Software

In der Maiausgabe von entwickler.de ist mein Leitartikel zum Thema Systemisches Softwareengineering erschienen.

Der Artikel beschäftigt sich mit der Frage, wie wir Kontexte in Organisationen und Unternehmen so gestalten können, damit Software optimal hergestellt werden kann.

Besondere Aktualität hat das Thema, da Software zunehmend von Mensch/Maschine Kollaboration bestimmt wird und viele Themen aktuell neu ausgehandelt werden. Oder wie es ein Kollege neulich meinte: “Alles ist offen”.

Sehr unterschiedliche Faktoren bestimmen über Erfolg oder Misserfolg von Softwareprojekten. Den Zusammenhang dieser Faktoren gemeinschaftlich zu verstehen und in wirksame Maßnahmen zur Erreichung der gewünschten Ziele umzusetzen ist der Zweck systemischen Softwareengineerings.

Einsatzgebiete finden sich beispielsweise in der Strategieentwicklung, im Veränderungsmanagement, bei Technologieeinsatz und Produktentwicklung oder der schnellen Entscheidungsfindung.

Nicht zuletzt wird Systemisches Denken von Organisationen wie dem World Economic Forum , Forbes, dem Stifterverband und vielen anderen zu den wichtigsten kognitiven Zukunftskompetenzen gezählt.

Ich lade alle ein sich mit diesem spannenden Thema tiefer zu beschäftigen. Der Artikel ist ein guter Einstieg dazu. Er ist verfügbar bei entwickler.de oder gerne auf Anfrage bei mir. Zur praktischen Vertiefung eignet sich unser Workshop Systemisches Denken in der professionellen Softwareentwicklung.

Systemisches Denken in Zeiten künstlicher Intelligenz

Moderne agile Frameworks bieten nachweislich enorme Möglichkeiten zur Verbesserungen der Softwareentwicklung. Seit mehr als 20 Jahren der Anwendung müssen wir erkennen, dass es vielen Unternehmen noch immer schwer fällt das Potential effektiv zu nutzen. Mit Systemischem Denken kann sich das ändern.

Continue reading Systemisches Denken in Zeiten künstlicher Intelligenz

Das Unbeherrschbare verstehen und gestalten – mit Systems Thinking zu besseren Entscheidungen

Als Softwareentwickler sind wir lineares Denken gewohnt. Jedoch verhält sich die Welt meistens nicht wie eine Build Pipeline. Systemisches Denken kann uns dabei helfen, nichtlineare Zusammenhänge besser zu verstehen und in komplexen Situationen erfolgreich zu agieren. Nach einer Einführung in systemisches Denken schauen wir uns typische Situationen aus dem Bereich der Softwareentwicklung aus neuen Perspektiven an und entwickeln gemeinsam Einsichten und Erkenntnisse. In dieser Session blicken wir mit Neugier nicht nur über den Tellerrand sondern direkt in das ganze Esszimmer.

Vortrag: https://jax.de/agile-culture/system-thinking-bessere-entscheidungen/

Workshop: https://www.pleus.net/systemicengineering.htm

Agile – Ein Sehnsuchtsort

In der Dezemberausgabe des Javamagazins findet sich mein aktueller Leitartikel zum Thema Agiles Arbeiten.

Der ganze Artikel findet sich unter:

https://entwickler.de/agile/agiles-arbeiten-obsoleszenz-unverzichtbarkeit

Wer das Thema gerne vertiefen möchte, ist herzlich eingeladen zur W-JAX in München. Auf dem diesjährigen FLOW-Day werden wir das Thema vertiefen und spannende Ansätze kennenlernen, um die Art wie wir Software entwickeln weiter zu verbessern.

Nutze gerne diesen Coupon bei der Anmeldung:

Softwareentwicklung als Soziotechnisches System

Das Thema Soziotechnische Systeme gewinnt in der Softwareentwicklung zunehmend an Bedeutung. Und das ist gut so.

„Im Allgemeinen muss das Management erkennen, dass der Erfolg eines Unternehmens davon abhängt, wie es als soziotechnisches System funktioniert, nicht einfach als ein technisches System mit ersetzbaren Individuen, die hinzugefügt werden und sich anpassen müssen.“

https://de.wikipedia.org/wiki/Soziotechnisches_System

Dies ist eine wichtige Erkenntnis, da die erfolgreiche Entwicklung von Software in Rahmen von Projekten, sowie deren kontinuierliche und nachhaltige Weiterentwicklung in hohem Maße von Faktoren des sozialen Gefüges und deren Zusammenarbeit abhängt.

Das Wissen darüber machen wir uns seit über 25 Jahren in zahlreichen Projekten zunutze und lassen es regelmäßig in die Projektarbeit einfliessen. Beispielsweise wenn es darum geht Teams zusammenzustellen und zu führen.

Einige Beispiele finden sich unter https://cswob.de/

Das geht so weit, das wir mit der Creative Software Workbench einen Rahmen geschaffen haben, in dem die Säule Menschen und Teams eine zentrale Rolle spielt.

Das Wissen und die Erfahrung aus vielen praktischen Anwendungen und Erfolgsgeschichten lässt sich in andere Projekte integrieren. Dabei unterstützen wir sie gerne…

The secrets of evolvable software

TL;DR: Modularization is the key to evolvable software. This blog post sheds some light on different aspects of modularization of software systems.

Motivation

The IT business is very dynamic. Changes happen everytime and everywhere. Programming languages, frameworks, tools, infrastructure – it feels like almost everything is changing all the time. For enterprises this is a challenge as it constantly requires modernization and maintenance. Ok, this is part of the nature of software systems today you might say, so why should we care?

Because from a business perspective it would be nice to have systems which do not require expensive rewrites now and then for cost reasons. Instead it would be better to have software that is able to evolve over time. Of cource maintenance is always required for example to get security patches. But if the software is build with evolvability in mind it can be adapted to future needs more easily (without major reimplementation). Evolvable software is structured in a way that enables change. It is one of the core values of Clean Code. Simply put evolvability is an important trait of modern software systems.

How can we get there? Let’s have a look at several aspects and good practices to create evolvable software.

Design

The key of evolvable software is in its design. And because the business domain is much more stable than technologies, the business is a good basis for design considerations. Domain Driven Design (DDD) means exactly that. Instead of using technical concepts such as message brokers, databases and so on we use business concepts such as products, sales or invoicing to organize our software system.

Especially important is the strategic design and in particular the concept of Bounded Contexts which is the central design pattern in DDD. Bounded Contexts foster modularity already at the design level. Domain design is carried out together with the experts from the particular domains and can be documented ideally with a graphical notation such as UML.

Codebase

Based on the domain design the codebase can be created and organized. I often see systems in which design model and code are decoupled which makes it difficult to understand the codebase. Moreover code is often structured based on technical concepts such as controllers, entities and so on. Although technical terms can be used at a lower level, the main structuring concept should be the domain. It is important to keep the design structure from the business domain at the code level to foster maintainability and evolvability.

Modularity is of utmost importance when it comes to evolvable software systems. This has to do with the fact that even the best programmers in the world are not able to understand software that is too large and complex. Modularity helps to chunk systems into smaller parts that are more likely to be understood.

Assume a Java based system. What are the options for modularity. At the language level we have packages. Actually packages are intended to structure a codebase into logical units. By keeping classes package private and exposing dedicated interfaces you can enforce encapsulation of your modules. Unfortunately it does not properly work with subpackages, but if a module is not too large this is not neccessarily a problem. By enforcing architectural constraints on your codebase with tools such as ArchUnit you can even relax encapsulation while keeping the codebase clean. If you want versioned artifacts, you can create libaries for instance with maven or gradle. If you need more independence put the libraries into separate repositories.

Services and APIs

Is that already a service? If the module has a dedicated interface contract I would say yes. But that is more of a philosophical question 😉

If you want to expose the service in an interoperable way, just add an HTTPS-Endpoint with REST- or RPC-style. No matter whether you choose a code- or contract-first approach, always go for an API-first aproach, as this gives you a better an more though-out structure which is usually closer to the business domain. My personal favourite is contract-first, for instance based on OpenAPI, because it is technology agnostic and opens the way for alternative implementation languages. Do you remember? We are talking about evolvable software. Even programming languages are changing over time. And even asynchronous interfaces and message broker based services deserve an API-contract, which can be created using AsyncAPI.

Frontend Components

Discussions about services most of the time happen on the server side in the form of service oriented architecture or microservices. But user interfaces can be modularized as well. Most modern UI frameworks such as Angular or React have a component model on board. UI components have interfaces as well. Those interfaces comprise everything that communicates with the outside world of the component such as attributes, events, cookie/local/session storage and window messages that should be properly documented. Modular distribution can be achieved by creating npm packages. If you want to increase interoperability and freedom of technology implement ui components as web components.

Containers

Containerization is a strong trend for good reasons. But over the last years the industry has learned that it is not always the best option to deploy each service or module as a separate unit. Deploying and running a lot of small units requires more infrastructure which can be costly to implement and maintain. In the past the pendulum swang from monoliths to microservices architectures which are both extreme in its implementations. Today so called moduliths are combining modularity with monolithic deployment models. Starting with a modulith can be a good option, evolving it to a microservice-based deployment model if and only if required. You can deploy a modulith standalone or using Docker and Kubernetes the same way as you would do with a single service if this is the runtime of your choice. Anyway it is important to find a proper granularity of modules. Self contained systems aligned to the business domains are often a good option in this regard. This also helps to keep cognitive load and responsibility manageable at the team level. This is again a matter of design.  

Limits

What happens when the programming Plattform changes completely, let’s say from .NET to JEE or from Java to Python? Even then you can save parts of your investments. Design outcomes and standards-based artifacts such as OpenAPI contracts are platform agnostic and can be reused. And as the business domain is usually quiet stable and not connected to changes in technology , you have a good chance to reuse your design outcomes as is.

Summary

Modularization is essential when it comes to creating evolvable software. Technologies are powerful enough to do it. Modular software is primarily a matter of design and the will to invest some effort into it. From the many projects that I have seen in my career, I am convinced that it is one of the most important things to do when creating professional software systems.

Aliens and Avatars – Explorative Product Deveploment in Action

On this years W-JAX I had the pleasure to host a session about explorative product development. The session was about the appropriate mixture of methods and software architecture especially, but not only, for projects in the pioneering phase. A good example of the Creative Software Workbench in action. You can see the session recording on entwickler.de (subscription required).

Lean Coffee at Jax Innovation Forum and DevOpsCon

This autumn I am going to moderate the Jax Innovation Forum and the DevOps Transformation Day again. On both days we will also have Lean Coffee Sessions, a format that incorporates input from the attendees. It is very energetic, interesting and fun. On top of that we conduct it even in hybrid mode, in which you can participate no matter whether you are on site or in the office. If you are interested in those kinds of events we can also carry it out it in your organisation. The event will be adjusted according to your corporate needs. You can find more information here.