It’s the Platform, Stupid!

Low-code Automation tools such as n8n, Zapier, and Make have gained tremendous popularity lately. Agencies offering automation, or even “AI Automation,” seem to be springing up everywhere. 

Having been traditionally skeptical of low-code tools, I wondered what was actually driving the hype, what the distractions were, and what made sense to me.

While the use of Artificial Intelligence agents greatly helps with the design of workflows, and while the integration of AI agents into the workflow allows for data extraction and content creation features that were hard to implement, if not unthinkable, just a few years ago, I think it is not the use of AI that is the killer feature we need here. I believe it is the availability and usability of the tool itself.

The Platform as an Enabler

Designing and reliably running asynchronous, long-running workflows that integrate with existing services is quite non-trivial in general. Rightly so. As noted in other posts, achieving state management, robustness under failure, retry handling, and monitoring is not simple.

Although developers have always had access to libraries to build these features, the effort required to maintain a custom environment for “simple” integrations was often disproportionate to the value.

Tools like n8n provide a user-friendly,feature-rich and managed platform to design and execute logic across high-level business functions.

Such platforms have only recently become widely available. The availability of business application exposure via REST or SOAP web services may soon reach a level such that integration scenarios across business systems are no longer dependent on custom interface development.

A graphical representation of a workflow is inherently more comprehensible to a business stakeholder than a block of code. This transparency offers two distinct advantages:

Reduced Dependency: Stakeholders feel more confident when they can “see” the business logic, which makes the handover and maintenance of processes feel more manageable.

Collaboration: It allows tech-savvy business users and developers to “speak the same language” when discussing process improvements.

A Pragmatic Target Architecture

Adding the integration of collaboration tools, office systems, shared file storage and much more to the mix, we create a system architecture that enables high-level automation (or, even better,: orchestration) of tasks that were previously either too complex to implement or simply too much effort to develop and maintain, given the automation value:

For example, imagine a system that (for whatever business reasons) allows the preparation of production orders in a shop floor system:

1. As a trigger, we use the reception of an email message of a given subject. We then extract basic facts such as lot data and dates via an LLM integration and store everything in a shared spreadsheet.
2. Once that is done, we send an approval email with a link to the spreadsheet to another user – the approver.
3. That user opens the spreadsheet at his discretion and checks for pending orders.
4. Once approved, another workflow is triggered that invokes the shop-floor system to set up the production configuration.
5. The status of the production order is monitored and updates are sent to the approver.

Limitations of Low-Code

While this approach looks great, graphical control flow modeling is very limited as a “programming” approach and the platforms we considered only hold up so far in terms of performance, reliability, and robustness.

Low-code tools are not ideal for critical automation control flows that require strong consistency and reliability. If a process runs many thousand times a day and requires manual intervention upon failure, you want more robustness than these tools can offer.

Low-code tools are not ideal for workloads involving high data loads, computation or transactions. Error handling and compensation are generally not that great and complex interactions may simply get too complex for graphical modeling as mentioned above.

Anything more complex than service orchestration belongs  in the realm of specified, coded applications that are subject to a test-based quality assurance and a well-run DevOps process.

You do, however, get an “AI friendly Automation User Interface” essentially for free that connects your boring business application with the professional users that need to make the best of it!

Some Notes on Automated Business Workflow Execution

This post follows Some Notes On Business Process Modeling.

Reflecting the previous post, this is what we actually do: define (technical) states that represent states of the real world process where the execution can naturally be interrupted and resumed.

We also expect the states to be essentially “self-explanatory” in the sense that, in the event of failure, it should be easy to understand what the current real world situation is, represented by the current state of the execution.

Why is that important? It is important because arguably the one thing that automated business workflow execution is about is error handling. Or to put it less charitably:

The Essence of Long Running Control Flows is the ability to manage failure.

How to Run

We implement the automation of such a business process as a transactional state machine based on the assumption that following principles, assuming that state transitions are idempotent:

Proceeding:

1. A process instance needs to be “proceeded” based on a schedule
2. The current schedule of a process instance may be set to proceed immediately, at some next point in time, at an undefined time, or it may be completed or in error.

The point of proceeding is to check whether a state transition is due, which is at the discretion of the process implementation and, if so, to actually perform that state transition. After proceeding, the updated process state is persisted.

A process implementation thus consists of a progress implementation for any modeled state that

1. … checks whether a state transition is due and, if so,
2. … performs a due state transition and then
3. … updates the process schedule by setting a subsequent point in time to proceed or by completing the process.

Or, as a flow chart:

In our case, this, scheduler, APIs and progress implementations are implemented in JAVA. There is absolutely nothing that is specific to the JAVA environment, however, and any useful programming language should do. And of course there are more utilities and goodies – some of which will be pointed out later.

No Higher Level Abstract Notation – No Language Barrier!

Note, however: There is no higher level executable notation of the process beyond our modeling as state charts. Nothing like a BPMN artifact. And this is very intentional.

We don’t need that because the way we modeled the process, mapping it to its implementation is straightforward.

And we do not want that because it would mean using a really limited programming language, instead of the proven “workhorse” of a language that you use to do the actual work and all other required abstraction levels. There is simply no good use case that justifies an implementation language barrier!

There Is More To It: Upgradeability!

Given the modeling and execution approach, we now have the following:

• A process description that specifies the process in an easy-to-understand abstraction
• A process description that naturally maps to its implementation, which is
  • Resilient to failure and interruption and
    • Can be easily monitored and interacted with (as I hope you can imagine).

It is also upgradeable. That is a big deal!

Given a regular programming language, which more or less describes what needs to be done step by step, you would not expect programs to continue where they left off during, say, a power outage.

In particular, assume that before turning on power again, the program’s code was updated.

Let’s also assume that you took a consistent snapshot of the computers main memory before the outage and loaded it back into memory when you restarted.

Would the new code work with the old memory state? Would the machine even know how to go about executing it? We can safely assume that, in general, this would not make sense.

However, under our implementation assumption, since we know that state transitions are idempotent, and since we know that the process is always in the last attained process state in a transactionally safe way, it has now become a simple task to make sure that an updated version of the implementation can continue with the state persisted for a previous version of the implementation: Ensure that the previously defined states are supported in a compatible manner.

Why is this a big deal? Imagine you have thousands of ongoing processes whose implementation has a critical bug and you have no choice but to either wait for the bug to occur or to somehow restart those processes and possibly repeat work (e.g. reordering materials?!).

Any business process execution model that does not provide for reasonably easy implementation upgrades is useless!

In a next post, we will take a look at extensibility and modularization.

References

1. Some Notes On Business Process Modeling
2. https://de.wikipedia.org/wiki/Business_Process_Model_and_Notation

Some Notes On Business Process Modeling

Originally, I wanted to write a small article about how we model business processes for documentation, specification, and implementation, and why I think this is the right way to do it. That was six months ago and this is the latest of many attempts to get it right. After all, it should be good, right?

In my case at least, I would want to know not only  what it is good for, but why it is better than other techniques.

The way we model business processes is very simple: we use a slightly extended state chart notation that has named states (more on this below), transitions between states that are marked by why the transition is happening and typically a number of things that are done during the transition, and some decision about what the next state is to be.

As a drawing that looks something like this:

Quite simple, actually. Ellipses are states. Bold ellipses are final states (i.e. where the business process has finished). Rectangles are actions. Conditions and reasons are markers on the edges that describe state transitions. So this is not quite UML notation – but it is not far off. It turns out that the formal notation is not really that important anyway.

There are, however, a few rules that I will explain in detail later, and which will not only feel natural in the end, but will also make the whole thing make sense.

1. A state as shown in the diagram is persistent. That means that if the execution of the business process were to  be interrupted (however that happens, it would be known that the business process is (still) in that particular state – and whoever is responsible for monitoring the business process would know what that state means and what is expected to continue the business process.
2. Transitions between states are idempotent. That means that if the business process is interrupted for any reason during the transition from, say, state A to state B, the execution can resume from state A.

Let’s consider some examples:

Asynchronous Document Gateway: Receive and Validate before Forwarding to Service

A very simple process that provides, an asynchronous validation gateway to a synchronous service:

Note that based on our assumption we have always have a way forward and implicitly implement an “at least once” delivery of a message.

Note the naming of states: Those that are transitory in that they describe something that is ongoing, are named as present participle.

Replenish a Good by Ordering and Receiving

In this example, a stock item needs to be (optionally) replenished. We start a workflow that orders a shipment and waits for the goods to arrive (the numbers are updated by a companion “goods received” workflow that we will not show here).

We assume that the logic that triggers this process rejects a concurrent order process for the same good. Therefore, we need to check whether another order is due immediately, after the order is fulfilled, so that this process, if all goes well, will continue to order goods until the required stock level is no longer below the threshold.

Note that in this case we have a non-transitory state “ORDERED”, during which we wait for fulfillment of the order, which may take some time. In this case, we use a past participle describing achievement.

Conclusion

While these examples and the modelling details have obviously been  simplified, I hope you have noticed the following:

While a process can be naively be described as a sequence of steps that need to be performed, modelling the process as a control flow between named states is actually very natural and more informative. If you think about it:

What is a business process if not a sequence of transitions from one state of the real world to another state of the real world?

Showing the states at which the process execution is to be resumed provides the observer with a named representation of a change that has already been achieved and upon which the process execution is (or will be) resumed.

Secondly, as we will see in more detail in the second post of this series,

The exercise of modelling the business process is precisely to name relevant states for the execution of the process.

Indeed, even in the simple examples above, states were not designed arbitrarily, but with our initial design rules in mind.

In the next post, we will see how to implement automation for the processes modeled as above in a way that is very “true” to the model – thus adding even more value to  the model.

The Technicians of Tomorrow will be Software Engineers

(German: Die Schlosser von Morgen sind Softwareentwickler)

Manufacturing companies require increasingly complex skills to maintain production and optimize operations.

This is not just about saving costs, but also about having the expertise to implement complex and innovative improvements – beyond what suppliers have to offer.

In the past, machines were bought for production and serviced by the supplier. Then operators realized that it was not only cheaper but also smarter to perform the maintenance oneself.

From the ability to carry out maintenance autonomously, it is not a far step to acquire the competence to modify, extend, and supplement machines in a way that aligns best with one’s business processes.

The exact same applies to business software today!

If you initially had industry solutions developed or bought them off the shelf and had them customized, now is the time to gain the expertise to expand, supplement or even modify the software yourself.

While this has always been explicitly possible with ERP solutions (especially SAP), and has been an absolutely critical factor in the long-term success of ERP providers, it is still the exception with other software.

However, especially for use in production and in connection with increasing automation, it is extremely relevant not only to combine software solutions with each other, but also to be able to modify existing solutions and, at best, to master them completely.

Only with the ability to “skillfully own” your software stack will it be possible to fully master operational processes in the future. And only then will it be possible to customize them as needed and design them for business success.

On-Premise vs. Software-as-a-Service

In dem Post Warum Individualsoftware? habe ich über die Vor- und Nachteile von Individual­software vs. Standardsoftware geschrieben.

In diesem Post geht es um On-Premise-Software, also vom Verwender selbst betriebene Kaufsoftware im Vergleich zu Software-as-a-Service-Software (SaaS) bzw. Mietsoftware – also Software, die vom Lösungsanbieter betrieben wird, und für die der Verwender ein Nutzungsrecht auf Online-Nutzung erwirbt.

Es wird vor allem darum gehen, welche Aspekte besonders wichtig für eine Entscheidung sind – vor und nach der Entscheidung.

Wenn es bei Warum Individualsoftware? um geschreinertes Regal vs. Billy-Regal ging, dann geht es hier gewissermaßen um Haus kaufen vs. Wohnung mieten – mit analogen Effekten.

Wesentliche Aspekte einer SaaS-Lösung sind:

Keine Investition

Die Anschaffung einer Software kann eine nicht unwesentliche Investition bedeuten. Bei gemieteter Software entfällt dieses Problem. So kann es sinnvoll sein, mit einer gemieteten Lösung zu starten, obwohl man sich bewusst ist, dass unten stehende Nachteile vielleicht später zuschlagen. Der Wert des einfachen Starts und möglicherweise auch die eingeschränkte Freiheit können helfen, genauer zu verstehen, wie der eigene Geschäftsprozess am besten umzusetzen ist.

Kein Betriebsaufwand

Weder muss Infrastruktur angeschafft noch betrieben werden. Es muss kein Ausfallplan und kein Backup erstellt werden. Die Gewährleistung der Verfügbarkeit der Lösung ist nicht ihr Problem (eine ungenügende Verfügbarkeit an sich aber vielleicht doch).

Bekommt die Software neue Feature oder Bug-Fixes und muss aktualisiert werden: Nicht ihr Problem.

Abhängigkeit: Kein Plan B, falls Angebot nicht mehr passt oder Anbieter geht.

Es gilt der alte Spruch: Daten leben länger als Software. In diesem Fall liegen ihre Daten beim Lösungsbetreiber. Kündigen Sie, können Sie womöglich Ihre Daten in irgendeiner Form herunterladen – ohne die fremde Software aber nur unter unklarem Aufwand damit weiter arbeiten (z. B. nach einer Migration für eine andere Software).

Flexibilität: What You See Is What You Get

Die gemietete Lösung ist nur so anpassbar wie sie entworfen wurde. Stellen Sie fest, dass ihr Geschäftsprozess schwer mit der Lösung umzusetzen ist, sind Sie auf das Wohlwollen ihres Anbieters angewiesen.

Integrierbarkeit: Keine Lokale Integration (sicher) möglich

Grundsätzlich stellt die Integration mit einer externen Lösung ein Sicherheitsproblem dar. Dabei geht es hier weniger um die Qualität der Netzwerkinfrastruktur oder ob diese lokal ist oder in der Cloud ist, sondern darum, dass möglicherweise sensible Daten Ihr Netzwerk über nicht von Ihnen abgesicherte Protokolle verlassen.

Es sind genau diese Aspekte, die eine Mietsoftware von einer Kaufsoftware unterscheiden. Vereinfacht und zur Illustration in Korrelation zur Individualsoftware stellen sich die Fälle ziemlich komplementär dar:

In den meisten Fällen sollte die Entscheidung einfach sein: Ist eines der Kriterien aus Abhängigkeit, Anpassbarkeit, Integrierbarkeit kritisch für den Geschäftszweck, so scheidet die fremd betriebene Mietsoftware aus. Das ist bei standardisierten Prozessen häufig nicht der Fall (E-Mail, Steuer, Personalabrechnung, …) aber zum Beispiel bei produktionsnaher Software (MES Systeme, Rework / Manuelle Workflows) meist doch.

Wenn man nun aber feststellt, dass die Software am besten lokal betrieben wird, was kann den Aufwand reduzieren?

Entscheidende Kriterien sind hier stets Komplexitätsgetrieben:

Komplexität der Installation

Ist die Installation komplex, zum Beispiel weil viele Fremdbibliotheken installiert werden oder Abhängigkeit an Elemente einer Betriebsystemversion bestehen oder muss gar eine Serverlandschaft aufgesetzt und abgesichert werden muss, so handelt es sich um eine Komplexitätskatastrophe mit Ansage.

Sind die Grenzen zwischen der gekauften Leistung und ihrer Betriebsumgebung schlecht definiert, so ist der Betrieb und seine Verantwortlichkeiten undurchschaubar und die Wartung entweder nicht vernünftig leistbar oder teuer.

Entsprechend finden wir:

Komplexität des Upgrades

Ist die Installation schon komplex, so kann davon ausgegangen werden, dass spätere Softwareversionen durch neue Abhängigkeiten und damit Veränderungen innerhalb des komplexen Setups nur noch komplizierter und damit unverständlicher und in der Folge teurer werden.

Komplexität der Software-Logistik

In der Königsklasse, nämlich der kundenspezifisch integrierten, erweiterten, möglicherweise sogar angepassten Software, kommt neben den beiden Punkten oben noch die Komplexität der Softwarelogistik hinzu. Zum Zeitpunkt der Anpassung und Aktualisierung der Software muss stets gewährleistet sein, dass verstanden wird, welche Änderungen wann vorgenommen wurden, ob Erweiterungen und Anpassungen kompatibel sind und wie diese qualifiziert werden können. Das bedeutet, dass die Entwicklung und die Quellcodeverwaltung der Kundenlösung nahtlos an die (hoffentlich vorhandenen) Standards des Anbieters der Basislösung angegliedert sein muss.

Zum Schluss

Dies sind exakt die Themen, die uns umtreiben. Deshalb kommt unsere Software weitgehend ohne Abhängigkeiten von externe Softwarekomponenten aus, wenn wir diese nicht mitliefern können. Und dies ist auch weshalb unsere eigene Software stets im Quellcode, integriert in eine übergreifende Software-Logistik ausgeliefert wird.

So ist es uns möglich, jegliche Aktualisierung, Erweiterung stets im lokalen Kontext zu validieren und falls notwendig erforderliche Anpassungen auch im lokalen Kontext des Kunden vorzunehmen.

Merke: Überraschungen gibt es immer. Probleme gibt es erst, wenn man damit nicht umgehen kann.

Schließlich bleibt noch das Investitionsthema. Die Tatsache, dass eine Software vom Verwender betrieben wird muss nicht zwingend implizieren, dass eine Lizenz erworben wurde. Wenn es nur um die lokale Integration geht und keine oder nur geringe Anpassungen erforderlich sind, spricht vieles für ein Mietmodell – auch daran arbeiten wir.

Verwandte Inhalte:

It’s the Platform, Stupid!

Low-code Automation tools such as n8n, Zapier, and Make have gained tremendous popularity lately. Agencies offering automation, or even “AI Automation,” seem to be springing up everywhere.  Having been traditionally skeptical of low-code tools, I wondered what was actually driving the hype, what the distractions were, and what made sense to me. While the use…

by blohen January 26, 2026

Some Notes on Automated Business Workflow Execution

This post follows Some Notes On Business Process Modeling. Reflecting the previous post, this is what we actually do: define (technical) states that represent states of the real world process where the execution can naturally be interrupted and resumed. We also expect the states to be essentially “self-explanatory” in the sense that, in the event of…

by blohen April 16, 2025April 17, 2025

Some Notes On Business Process Modeling

Originally, I wanted to write a small article about how we model business processes for documentation, specification, and implementation, and why I think this is the right way to do it. That was six months ago and this is the latest of many attempts to get it right. After all, it should be good, right?…

by blohen January 27, 2025

Wie man einen Softwareentwickler beauftragt

(English: How to Contract a Software Developer)

Wir sind ein kleines Unternehmen, das kundenspezifische Software entwickelt, die in der Regel geschäftskritische Funktionen implementiert: Back-Ends mit vielen asynchronen transaktionalen Geschäftsabläufen, Massendatenverarbeitung, Integration mit anderen Back-Ends, Maschinendaten und auch Benutzeroberflächen in der Produktion.

Wir entwerfen und implementieren diese Software nicht von Grund auf. Wir verfügen über Werkzeuge, eine solide Softwarebasis und Erfahrung, um Geschäftsprozesse zu analysieren, sie in Software abzubilden und schließlich zu implementieren. Das bringen wir mit.

Im Allgemeinen führen wir keine Projekte zu Festpreisen durch. Das tun wir nicht, weil es im Allgemeinen einfach keinen Sinn macht – nicht für uns, nicht für unsere Kunden.

In diesem Beitrag geht es darum, warum es in den meisten Fällen falsch ist, nach einem Festpreisprojekt zu fragen – für uns als Entwickler und für Sie als Kunde. Es geht darum, warum Sie einen Entwickler nicht für ein Festpreisprojekt beauftragen sollten, und was Sie stattdessen tun sollten – um das Leben für Sie als Kunde und uns als Entwickler besser zu machen.

Grundsätzliches

Normalerweise liest man, dass der allererste Schritt eines jeden Softwareprojekts darin besteht, ein Verständnis für das eigentliche Geschäftsproblem, seine wesentlichen Datenbeziehungen und die Benutzeranforderungen an ein Softwaresystem zu entwickeln.

Zwar gibt es eine anfängliche Problembeschreibung, aber diese beschreibt das zu lösende Problem nicht unbedingt in Begriffen, die sich leicht auf einen technischen Lösungsansatz übertragen lassen. Sie müssen also eine technischere und grundlegendere Formulierung des zu lösenden Geschäftsproblems erstellen, um eine Grundlage zu schaffen, auf der das Projekt geplant und umgesetzt werden kann.

Aber das ist nicht die ganze Geschichte. Wenn Sie an diesem Punkt angelangt sind, befinden Sie sich bereits im Projekt. Ein unverzichtbarer erster Schritt ist der Aufbau einer gemeinsamen Vertrauensbasis zwischen Kunde und Entwickler.

Warum sollte ein Kunde einem Entwickler ein Softwareprojekt anvertrauen, das sich möglicherweise zu einem millionenschweren Unterfangen entwickelt, das auf einem Austausch von Designideen und einer vagen Planung beruht?

Warum sollte ein Softwareentwickler einen teuren Rechtsstreit riskieren, weil er nicht verstanden hat, was eine Lösung er für ein millionenschweres Softwareprojekt auf der Grundlage eines Entwurfs liefern soll, der sich als Wunschdenken herausgestellt hat?

Den Zeitlauf verstehen und den Erfolg absichern

Ich glaube, dass es in jedem Projekt drei wesentliche (bewegliche) Meta-Meilensteine gibt:

Nächstes: Alle Funktionen und Korrekturen, von denen Sie wissen, dass sie benötigt werden, und von denen der Entwickler weiß (oder zu wissen glaubt), wie man sie richtig umsetzt. Alles im Nächsten kann jetzt gemacht werden.

Bald: All die Funktionen, die Ihrer Meinung nach in Zukunft realisiert werden könnten, möglicherweise in Verbindung mit dem Nächsten, die Sie für sehr nützlich halten, von denen Sie aber nicht sicher sind, ob Sie wirklich bereit sind, dafür zu bezahlen, und bei denen sich Ihr Entwickler nicht sicher ist, wie lange es dauern wird, und wie gut sie funktionieren werden.

Ferne: Die Vision von dem, was man tun könnte, wenn man das Nächste und etwas vom Baldigen hätte, und vielleicht eine coole Idee und den richtigen Geschäftsrahmen. Man weiss nicht, wie man das jetzt planen soll, aber wenn man den Gedanken mit anderen teilt, erhält man eine Orientierung, wohin wir letztendlich gehen wollen.

Diese Meta-Meilensteine als bewegliches Ziel bilden die Grundlage für die wiederholte Planung und Umsetzung. Indem wir uns auf sie einigen, schaffen wir ein gemeinsames Verständnis darüber, wie wir glauben, dass das Projekt vorankommen soll – und verpflichten uns gleichzeitig, den nächsten “realistischen” Teil davon zu erreichen:

Das Bald definiert das Nächste, indem es Ihnen die Grenze dessen aufzeigt, wovon Sie sich sicher fühlen. Das Ferne wiederum leitet die Schaffung des Nahen und die Vision, die zu kommunizieren ist, wenn man die Bemühungen als Ganzes rechtfertigt.

Während der Arbeit am Nächsten werden das Baldige und das Ferne klarer – im Idealfall fließt das Baldige in das Nächste. und es gibt ständig Nahrung für die Arbeit und den Erfolg im Projekt.

Die Sache ist jedoch folgende:

• Während man sich auf das Baldige einigt und das Ferne kommuniziert, schließt man nur einen Vertrag über das Nächste ab.
• Während Sie am Nächsten arbeiten, füllen Sie es wieder mit dem Baldigen auf.
• Sie stellen sicher, dass eine Trennung der Vertragsparteien zwar nicht wünschenswert ist, aber nicht mehr verbrannte Erde hinterlässt als das aktuelle Nächste.

In der Praxis

Als potenzielle Projektpartner sollten sich Entwickler und Kunde auf eine erste Reihe von Nah- und Fernprojekten einigen. Ich neige dazu, sie als Phase 1 und Phase 2 zu bezeichnen, da dies wahrscheinlich eher erwartet wird. Das erste, was zu tun ist, ist ein erstes High-Level-Design oder sogar so etwas wie eine Spezifikation zu erstellen, die das Nächste genau definiert.

Das sollte die erste Verpflichtung sein.

Das Ergebnis der Spezifizierung wird ein verfeinertes Nächstes, Baldiges und möglicherweise auch ein aktualisiertes Fernes sein. Die Zielpfosten werden sich verschoben haben, und Sie können zur nächsten Iteration übergehen: Die tatsächliche Implementierung des Nächsten.

Im Sinne der agilen Entwicklung: Eine Iteration ist hier im Allgemeinen kein Sprint, sondern eher mehrere Sprints, je nach Größe des Projekts und des Planungshorizonts. Dennoch würden Sie die Budgetierung und die mittelfristige Planung auf die Sprintgrenzen abstimmen, um die Arbeit nicht unnötig zu unterbrechen.

Sie stellen jederzeit sicher, dass die Arbeiten spezifiziert und die Dokumentation so weit aktualisiert wurde, dass die Arbeiten bei Bedarf weitergegeben werden können.

Als Entwickler wissen Sie, dass alles vorbereitet ist und Sie keine (unerwarteten) technischen oder dokumentarischen Unzulänglichkeiten haben, die Sie später heimsuchen werden.

Als Kunde wissen Sie, dass es keine unnötigen Abhängigkeiten gibt, die dazu führen könnten, dass Sie die Kontrolle über Ihre Investition verlieren.

Dies bedeutet insbesondere:

• Verträge stellen sicher, dass alles, was entwickelt wird, dem Kunden gehört.
• Falls erforderlich, kann der Kunde die Entwicklung mit einem anderen Team fortsetzen, neue Entwickler einstellen oder die Entwicklung intern verlagern, falls dies gewünscht wird.

Letzteres bedeutet, dass die Tools für die Projektorganisation und die Inhalte sowie die Entwicklungs- und Testinfrastruktur entweder bereits vom Kunden betrieben werden, mit dem Projekt geliefert werden oder vom Kunden leicht neu erstellt werden können.

Am besten ist es natürlich, wenn die Entwicklung und das Testen in den Projektquellen enthalten und weitgehend unabhängig von anderen externen oder urheberrechtlich geschätzten Tools sind.

Um das Vertrauen in das Projekt und in Sie als Entwickler aufrechtzuerhalten, sollten Sie darauf achten, einen gut gefüllten Backlog für das Baldige zu verwalten, damit die Kontinuität des Projekts gewahrt bleibt.

Warum Individualsoftware?

Es gibt Standardsoftware und Individualsoftware. Aus Sicht eines Kunden, der eine Software-Lizenz erwirbt bedeutet eine Individualsoftware in der Regel, dass er alle Rechte an der Software besitzt. Mit Individualsoftware bezeichnen wir in der Regel Code, der speziell auf Wunsch für einen Kunden entwickelt wurde.

Als Standardsoftware bezeichnen wir dagegen Software, die vom Nutzer wohl benutzt, in der Regel aber nicht verändert oder gar vervielfältigt und vertrieben werden darf.

Soweit so klar. Oder auch nicht. Wenn man jede Software mit gleichem Aufwand, Preis, Qualität und Wartung als Individualsoftware haben könnte – nun, dann würde es den Begriff „Standardsoftware“ gar nicht geben.

Software als strategisches Investment

Individualsoftware kann viele Vorteile haben: Der Code gehört dem Auftraggeber, der alle Freiheiten hat damit zu tun, was ihm beliebt. Der Auftraggeber sitzt am Steuerrad!

Es gibt aber auch Nachteile: Bezahlt nur einer, bezahlt er mehr. Gelingt die Software überhaupt? Software braucht Betrieb, Wartung und Weiterentwicklung. Gibt es einen sicheren Partner dafür? Kann oder soll Wartung und Entwicklung selber übernommen werden?

Gerade Letzteres kann sich mittelfristig als großer Vorteil herausstellen: Alle Industrien werden Softwarelastiger und Software Know-How eine wichtige Expertise (siehe auch [Die Schlosser von morgen sind Software-Entwickler]). Die Individualentwicklung mit einem Partner kann genutzt werden, um interne Kompetenz risikoarm aufzubauen und für die Zukunft abzusichern.

Individualsoftware macht nur dann Sinn, wenn sie strategisch ist! Strategisch ist sie, wenn sie das Geschäftsmodell ermöglicht oder hinreichend verbessert und für die Zukunft absichert.

Fertigungstiefe

Ein wichtiger Faktor, der das Kosten-Nutzen-Verhältnis und das Wartungsrisiko beeinflusst ist der Anteil des speziell entwickelten Codes an der eigentlichen Lösung. Gewissermaßen die „Fertigungstiefe“.

Keine Software die heute entwickelt wird fußt nicht zu einem Großteil auf vorhandene Bibliotheken, Frameworks, und grundsätzlicher Technologien wie Betriebssystemen, Datenbanken, und einer Unmenge an Konventionen und Standards.

Die Verfügbarkeit von verwendbaren Technologien eröffnen eine enormen Raum an Möglichkeiten. Das ist aber häufig gar nicht von Vorteil. Noch besser ist, wenn bereits ein vorhandener Anwendungsrahmen – gewissermassen ein Chassis – vorhanden ist, in dem eine neue Spezialisierung implementiert wird, ohne dass grundlegende Fähigkeiten für den Geschäftseinsatz wie z. B. Stammdaten-, Benutzer- und Rechteverwaltungen neu erfunden werden müssen.

Planen Sie eine Erweiterung einer SAP Lösung, dann müssen sie sicher nicht ein neues Materialwirtschaftssystem entwickeln.

Das Ziel ist es, sich möglicht mit dem eigentlichen Problem zu beschäftigen – und nicht das Rad neu zu erfinden!

Nicht von Vorne anfangen. Eine Basis wählen, die schon zum geplanten Einsatz passt.

In eigener Sache

Was ich oben beschrieben habe ist unser Modell.

1. Wir bieten technologische Basis, die durch starke Modularisierung und Software-Logistik, den idealen Unterbau für anpassbare und erweiterbare on-premise Software ergibt.
2. Wir bieten einen Applikationsrahmen, der viele Entscheidungen vorwegnimmt und grundlegende Business-Funktionalitäten mitbringt.
3. Wir befähigen unsere Kunden, die Dinge soweit in die Hand zu nehmen, wie sie mögen und springen ein sobald es nötig ist.

Wenn schon Individualsoftware, dann richtig!

Referenzen

• Die Schlosser von Morgen sind Softwareentwickler
• How to Contract a Software Developer

Die Schlosser von Morgen sind Softwareentwickler

Produzierende Betriebe müssen immer komplexere Qualifikationen mitbringen, um ihre Produktion am Laufen zu halten und optimal zu betreiben.

Hier geht es nicht nur darum, Kosten zu sparen, sondern auch darum, die Kompetenz zu haben, komplexe und innovative Verbesserungen umzusetzen – jenseits dessen, was Lieferanten zu bieten haben.

Früher hat man Maschinen für die Produktion gekauft und vom Lieferanten warten lassen. Dann hat man verstanden, dass es nicht nur günstiger sondern auch klüger ist, die Wartung selber zu unternehmen. Von der Fähigkeit, die Wartung selber durchzuführen ist es kein unüberwindbarer Schritt, die Kompetenz zu erlangen, Maschinen zu erweitern, zu ergänzen und Produktionsprozesse im eigenen Sinne zu optimieren und zu integrieren.

Ganz genauso verhält es sich heute mit der betrieblichen Software. Hat man zunächst Branchenlösungen entwickeln lassen oder von der Stange gekauft und anpassen lassen, so ist der nächste Schritt, die Kompetenz zu erlangen, die Software selber zu erweitern, zu ergänzen oder sogar zu modifizieren.

Während das bei ERP Lösungen (insb. SAP) schon immer explizit möglich war, ein absolut signifikanter Faktor für den lang anhaltenden Erfolg von SAP, so ist das bei anderer Software immer noch die Ausnahme.

Gerade für den Einsatz in der Produktion und im Zusammenhang mit zunehmender Automatisierung ist es jedoch extrem relevant, Software-Lösungen nicht nur miteinander zu kombinieren, sondern auch in der Lage zu sein, vorhandene Lösung modifizierend zu erweitern und bestenfalls komplett zu beherrschen.

Nur mit dieser Fähigkeit, wird man in der Zukunft betriebliche Prozesse komplett beherrschen können. Und nur dann ist es möglich, diese nach Wunsch anzupassen und für den geschäftlichen Erfolg zu gestalten.

The Ability to Create Abstraction Necessarily Wins Over any Ability to Keep Track of Many Pieces

A Simple Thought.

We know that our ability to create abstractions is key to manage complexity – in life, in science, in mastering technology. Without creating abstractions we would not be able to make sense of our daily routine, what we work on, and much less of the constant sensory input we receive.

In fact, I doubt that anybody can meaningfully keep track of more than a handful interconnected things while “thinking”. That is why powerpoint presentations explaining a concept should never have more than three boxes with arrows between them – nobody will buy your idea otherwise. Likewise, any concept described by three connected boxes look convincing for most people – most likely the true reason for the demise of countless companies.

Abstractions are essential to software development. Not only that the whole idea of software requires some serious level of abstraction, but thankfully programming languages provide the means to stack abstractions on top of each other – leading to libraries of libraries of concepts and abstractions borrowed from those around and before us allowing us to create software that encompasses many millions, if not billions of lines of code – while writing only a fraction of that by ourselfs.

All that while being mostly ignorant to the intricacies of the lower layers of the pile of abstractions (actually the shoulders of the giants) we are standing on. So much so, that something like a file system occurs to us as natural a concept as, say, a horse.

And here is the catch: Because any layer of abstraction is hiding a number of lower level concepts, and since that number is naturally at least two (otherwise: Why bother?), the sum of lower level abstractions made tangible by introducing higher level concepts essentially growth exponentially.

Not very scientifically speaking, for code this means:

However the same pattern applies to other realms, be it running an organization or taking care of business or being a school teacher. Somebody good at computing does not necessarily make a good mathematician while being good at computing is not at all required to be a good mathematician. The ability to understand, create, and apply abstractions hands down wins over any “increased clock speed”.

In other words: As long as we are good at building abstractions, it’s ok that we cannot handle more than three boxes with arrows per slide….

If You Want to Make It, You’ve Got to Own It

Imagine you are a high volume manufacturer of vacuum cleaners. Everything runs smoothly, but you feel there may be some business potential for configurable high end vacuum cleaners that are built to spec.

You image a GOLD series of vacuum cleaners for which customers can configure various color schemes and decorations, various sensor add-ons, GPS tracking, and other features that a certain high-profile customer group finds exciting.

Of course, ordering a GOLD configuration from the web site comes at a premium.

Problem is: Your current production process does not accommodate for an ad hoc built-to-spec production. If you cannot reliably produce it, you cannot sell it!

So you come up with a pragmatic process, that makes sure you can track from order to shipment and that everything is consistent with your ERP recorded data. For example something like this (that I just made up – and you will get the point I suppose):

Obviously this requires some software support. It is not huge, but it may need to evolve and go through changes when you evolve your business. Who knows, maybe one day you will want to inform your customers on the production progress of there GOLD product.

Unfortunately you do not have much software development expertise in-house. So where do you get that software from? Do you ask your ERP supplier? Do you ask your Production Automation / MES supplier? Maybe not. Both are not exactly into custom development and will only increase your lock-in with them.

You could ask a software development agency – maybe even something really cheap with developers elsewhere but a local project manager.

Problem is: You might get a great solution but it will be a one-off solution. Who is going to maintain it, if the team that developed it will break up and join other projects right after? How do make sure, you can maintain it later?

The catch is:

You need to own it, if you want to make it!

Developing appropriate software development expertise is difficult. Developing and maintaining a custom business application that manages some long running workflows and integrates with legacy systems in a manageable way is different from developing a Web site. So you should look for a partner that provides

• The expertise to build a solution;
• A blueprint on how to extent and expand the solution into YOUR business platform;
• A technology platform that you can build on, and
• Support when you feel it is time to take over

This is the essence of digital transformation: It is not about creating digital versions of processes you already have, it is about making use of digital capabilities to implement new business models or process optimizations that were simply not possible before.

Please check out the great article by Volker Stiehl linked below.

References

1. https://www.volkerstiehl.de/digitalisierung-vs-digitale-transformation/ (German only)
2. How to Contract a Software Developer