en
de

Dukatenesel Domänenexperte

16 Juni 2014
| |
Lesezeit: 2 Minutes

Hilfe, jetzt bin ich arbeitslos! Wie konnte es nur dazu kommen?

Als Dienstleister führt mich mein Arbeitsleben zu verschiedenen Kunden, die häufig eines gemeinsam haben: Ich habe von der Fachdomäne des Kunden keine Ahnung. Jedenfalls ist das zu Beginn der Projekte meistens der Fall. Heute habe ich es mit Verfahrenstechnikern und morgen mit Physikern zu tun. In Ihrer Domäne sind die Experten nicht selten ganz vorne mit dabei. Aber bei der technischen Umsetzung Ihrer Produkte unterstützt Zühlke.

Meine Aufgabe bei einem neuen Kunden ist daher in der Regel zunächst die Domäne zu verstehen, um eine gemeinsame Sprache mit den Domänenexperten zu finden. Das ist eine spannende Herausforderung für sich, über die ich aber hier nicht weiter sprechen möchte. Der Prozess ist aufwändig für beide Seiten. Als Dienstleister kann mir das natürlich nur recht sein, dafür werde ich ja bezahlt. Aber für die Domänenexperten bedeutet dieser Aufwand, dass sie für ihre eigentliche Aufgabe weniger Zeit haben. Und genau hier versteckt sich ein Dukatenesel, den man nur pflegen muss.

Domänenorientierte Softwareentwicklung

Ich baue die Software angepasst an die Domäne. Das „Domain Driven Design“ hat Eric Evans schon vor mehr als 10 Jahren als Begriff geprägt. Bereits in der Architektur sehe ich entsprechende Schichten vor, um die fachlichen Aspekte der Domäne auf die technischen Aspekte der Umsetzung abzubilden. Diese Abstraktion kostet einiges an Mühe und Denkarbeit, aber damit ist eine wichtige Grundlage gelegt. Auf dieser Basis kann ich die fachlichen Lösungen der Domänenexperten direkt umsetzen. Doch solange der Domänenexperte immer noch für jede Anpassung seiner Lösungen zu mir kommen muss, geht mir die Arbeit mit Sicherheit nicht aus.

Domänenexperten ohne Berührungsängste vor einem C/C++-Compiler würden mich vielleicht schon an dieser Stelle arbeitslos machen. Bisher habe ich jedoch nur Domänenexperten kennengelernt, die kein gesteigertes Interesse haben C/C++ zu programmieren. Mithilfe einer domänenspezischen Sprache (DSL) kann ich diesen Kollegen noch weiter entgegenkommen. Hier habe ich die Wahl

  • verfügbare Modellierungswerkzeuge zu nutzen und anzubinden, etwa MATLAB/Simulink oder
  • eine eigene Sprache nebst Codegeneratoren zu entwerfen (externe DSL) oder
  • eine eine Scriptsprache in mein System einzubetten (interne DSL).

Für welchen Weg ich mich entscheide hängt sehr stark vom Projekt und der Domäne ab.

Domänenexperte, übernehmen sie

Meine Verfahrenstechniker etwa hantieren wie selbstverständlich mit MATLAB/Simulink. Obgleich das Werkzeug für die Aufgabe überdimensioniert scheint, erfüllt die Integration doch den Zweck. Die Domänenexperten haben ein bekanntes Werkzeug und können ihre Aufgabe effizient erledigen. Die Physiker kennen die Scriptsprache Python aus dem Hochschulbetrieb und der Forschung. Eine interne DSL lässt sich mit dynamischen Scriptsprachen gut realisieren. Getreu dem Motto „Hilfe zur Selbsthilfe“ erreiche ich auch so das Abstraktionsniveau, damit die Domänenexperten ihre Fachlogik selbst umsetzen können.

Hilfe, jetzt bin ich arbeitslos! Oder eben auch nicht, denn es gibt immer neue Innovationen, deren Umsetzungen mir spannende Herausforderungen bieten. Ich habe vielmehr einen eleganten Weg gefunden mich vor der endlosen Wartung von Altlasten zu drücken. Für mich bedeutet das Freiraum für neue Aufgaben, und für meine Kunden viel gespartes Geld.

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »