Modelle der Zusammenarbeit
Unterstützung für Wachstumsstrategien, Transformationen oder M&A-Prozessen.
Unsere Freelance Experts verfügen über tiefgehendes Fachwissen in ihrem Bereich.
Wir liefern Ihnen erfahrene Interim Manager, die Verantwortung übernehmen.
Maßgeschneiderte Expertenteams für komplexe Projekte
Für diese Unternehmen finden wir die besten Experten
Private Equity
Effiziente Unterstützung im gesamten Deal Cycle
Unternehmensberatungen
Flexible Ressourcen für anspruchsvolle Projekte
Mittelstand
Beratungsexpertise für den Mittelstand
Corporates
Fach- und Führungsexperten für operative Exzellenz
Scale-Ups
Strategische & operative Unterstützung für Wachstum
Maßstab

Was Softwareentwicklungsberatung leistet — und was nicht

Quellcode einer gewachsenen Fachanwendung auf einem Entwicklerbildschirm

Softwareentwicklungsberatung — je nach Haus auch Software-Architekturberatung, Beratung für Individualsoftware oder Software-Engineering-Beratung genannt — bewertet ein System nicht danach, ob es fertig ist. Fertig ist Software nie. Bewertet wird, was die nächste Änderung kostet: an Tagen, an Abstimmung, an Risiko im Betrieb. Diese eine Zahl entscheidet darüber, ob ein Haus in fünf Jahren noch handlungsfähig ist, und sie steht in keinem Abnahmeprotokoll.

Lauffähig ist nicht änderbar. Zwei Anwendungen können dieselbe Fachaufgabe gleich gut erledigen und sich in den Folgekosten um den Faktor fünf unterscheiden. Der Unterschied steckt nicht im Funktionsumfang, sondern in den Abhängigkeiten: wie viele Stellen eine neue Anforderung berührt, wie oft eine Änderung an einer Stelle etwas an einer anderen zerlegt, wie lange es dauert, bis jemand mit Gewissheit sagen kann, dass nichts kaputt ist. Wer nur die Funktion abnimmt, kauft die Änderungskosten unbesehen mit.

Der Schnitt entscheidet vor der Technologie. Die Frage, welches Framework, welche Datenbank, welcher Cloud-Dienst, wird meist zuerst gestellt und ist die unwichtigere. Wichtiger ist, wo die Grenzen zwischen den fachlichen Bereichen liegen und welcher Bereich welche Daten besitzt. Ein Schnitt quer zur Fachlichkeit lässt sich später nicht durch Technologie reparieren; ein guter Schnitt erlaubt es dagegen, Technologien einzeln zu tauschen, ohne das Ganze anzufassen.

Wissen im Kopf ist nicht Wissen im System. Wo Regeln nur als Erfahrung einzelner Personen existieren, ist jede Abwesenheit ein Betriebsrisiko und jede Einarbeitung ein Monat. Änderungsfähigkeit heißt deshalb auch: automatisierte Tests, die eine Aussage treffen, eine reproduzierbare Auslieferung und eine Dokumentation der Entscheidungen — nicht der Zeilen. Diese drei Dinge sind das, was ein Team nach dem Weggang eines Schlüsselentwicklers noch hat.

Im englischsprachigen Umfeld heißen dieselben Aufgaben software engineering consulting, software architecture consulting oder custom software development consulting; wer nach software architects oder senior software engineers sucht, meint in der Regel diese Leistung. Für international besetzte Entwicklungsteams arbeiten wir zweisprachig.

Was sie nicht leistet. Sie nimmt Ihnen die Produktentscheidung nicht ab: was gebaut wird, welche Anforderung Vorrang hat und was ein Feature wert ist, bleibt im Haus. Und sie kann eine Fachlichkeit nicht klären, die niemand entscheiden will — wo zwei Bereiche sich über die Definition eines Kunden, eines Auftrags oder eines Preises nicht einigen, entsteht kein Systemschnitt, sondern eine Schnittstelle mehr.

Wo diese Seite endet: IT-Strategie, Applikationslandschaft, Sourcing und Betriebsführung behandeln wir in der IT-Beratung. Plattform, Migration und Kostensteuerung stehen in der Cloud-Beratung, Datenmodelle und Berichtswesen in der Business-Intelligence-Beratung. Für Modelle und deren Einbettung ins Produkt siehe die KI-Beratung, für Arbeitsweise und Zusammenarbeit im Team die Agile Transformation.

Auslöser

Wann externe Unterstützung in einem Softwarevorhaben weiterhilft

Ein eingespieltes Entwicklungsteam mit klarem Auftrag braucht keine Beratung. Der Bedarf entsteht an den Stellen, an denen ein Team seine eigene Lage nicht mehr von innen beurteilen kann — weil die Entscheidung größer ist als der nächste Sprint, weil das nötige Wissen im Haus nie aufgebaut wurde, oder weil eine Aussage gebraucht wird, die nicht von denen kommt, die das System gebaut haben.

1. Jede Erweiterung dauert länger als die vorige

  • Die Anwendung tut, was sie soll, aber der Aufwand für vergleichbare Änderungen steigt von Quartal zu Quartal.
  • Niemand kann benennen, woran das liegt — die Vermutungen im Team gehen auseinander.
  • Gesucht ist eine Bestandsaufnahme, die die Ursachen nach Wirkung sortiert, statt eine Neuentwicklung zu empfehlen.

2. Ein Altsystem hängt an einzelnen Personen

  • Zwei oder drei Personen verstehen die Fachlogik, geschrieben ist sie nirgends.
  • Der Hersteller einer eingesetzten Komponente hat den Support beendet oder die Laufzeitumgebung ist abgekündigt.
  • Gesucht ist ein Weg, das Wissen ins System zu holen, bevor es das Haus verlässt.

3. Vor der Entscheidung fehlt eine unabhängige Aussage

  • Ein Anbieter oder das eigene Team schlägt einen Entwurf vor, im Haus fehlt der Maßstab, ihn zu prüfen.
  • Kaufen oder bauen ist ungeklärt, und beide Lager argumentieren mit Zahlen, die niemand nachrechnen kann.
  • Gesucht ist eine Zweitmeinung mit Begründung, nicht eine Empfehlung mit Angebot dahinter.

4. Das Vorhaben ist beschlossen, die Kapazität fehlt

  • Budget und Zieltermin stehen, die passenden Profile sind am Markt nicht kurzfristig festanstellbar.
  • Das bestehende Team trägt parallel den Betrieb und kann nicht beides.
  • Gesucht ist Verstärkung, die sich in die vorhandene Arbeitsweise einfügt, statt eine zweite daneben aufzubauen.

5. Die Schnittstellen sind der Engpass, nicht die Anwendung

  • Neue Anbindungen an ERP, Shop, Portal oder Partner dauern jedes Mal von neuem Monate.
  • Dieselben Daten liegen in mehreren Systemen unterschiedlich, und keiner ist als führend festgelegt.
  • Gesucht ist eine tragfähige Ordnung der Schnittstellen, nicht die nächste Punkt-zu-Punkt-Verbindung.

6. Nach einem Zwischenfall fehlt Vertrauen in die Auslieferung

  • Ein Release hat den Betrieb gestört, seither wird seltener und mit mehr Aufwand ausgeliefert.
  • Tests gibt es, aber ihre grüne Farbe sagt nichts über den Zustand des Systems.
  • Gesucht ist ein Prüfnetz, das eine belastbare Aussage trifft — und damit häufigere, kleinere Auslieferungen erlaubt.

Kommt Ihnen einer dieser Auslöser bekannt vor? Zwanzig Minuten reichen, um Ihre Lage einzuordnen und zu sagen, ob eine Bestandsaufnahme, ein Entwurf oder zusätzliche Entwicklungskapazität der richtige nächste Schritt ist.

Ebenen

Wo Softwareentwicklungsberatung ansetzt: die Ebenen vom Code bis zur Systemlandschaft

Softwarearbeit lässt sich auf sechs Ebenen beschreiben, die aufeinander aufbauen und einzeln oder in Kombination besetzbar sind. Ein Vorhaben scheitert selten an der Ebene, an der es gerade arbeitet — es scheitert an der darunter, die übersprungen wurde. Deshalb ist die erste Frage nie, wie gebaut wird, sondern auf welcher Ebene die Unklarheit sitzt.

Anforderungen und fachlicher Schnitt

Bevor eine Zeile entsteht, wird die Fachlichkeit sortiert: Welche Begriffe bedeuten in welchem Bereich was, wer besitzt welche Daten, welche Regeln sind Gesetz und welche sind gewachsene Gewohnheit. Aus dieser Sortierung entstehen die Grenzen des späteren Systems. Ergebnis ist ein abgestimmtes Begriffsmodell und eine Liste der Stellen, an denen zwei Bereiche dasselbe Wort verschieden verwenden — die häufigste Quelle späterer Sonderfälle.

Architektur und Zielbild

Das Zielbild legt fest, aus welchen Bausteinen das System besteht, welcher Baustein welche Verantwortung trägt und wie sie miteinander sprechen. Dazu gehört die ehrliche Begründung der Zuschnitthöhe: ein Monolith mit klaren inneren Grenzen ist für viele Häuser die tragfähigere Antwort als verteilte Dienste, die eine Betriebsmannschaft voraussetzen, die es nicht gibt. Festgehalten werden nicht Diagramme, sondern Entscheidungen samt Alternativen und Grund.

Umsetzung und Entwicklungskapazität

Auf dieser Ebene wird gebaut: Fachanwendungen, Backend-Dienste, Weboberflächen, Auswertungslogik, Automatisierungen. Externe Kapazität arbeitet dabei in der Arbeitsweise des Hauses und nicht daneben — gleiche Repositories, gleiche Prüfschritte, gleiche Auslieferungswege. Wo eine Technologie im Haus neu ist, gehört das Anlernen der eigenen Leute zum Auftrag, nicht in eine Anschlussphase.

Schnittstellen und Integration

Kaum eine Anwendung steht allein. Hier wird geklärt, welches System für welchen Datensatz führend ist, welche Schnittstellen synchron antworten müssen und welche besser ereignisgesteuert arbeiten, und wie Versionswechsel möglich bleiben, ohne alle Anbindungen gleichzeitig anzufassen. Verträge über Schnittstellen werden explizit gemacht und geprüft — nicht aus Formalismus, sondern weil sie die Stelle sind, an der Änderungen sonst am teuersten werden.

Qualität, Test und Sicherheit

Ein Prüfnetz ist nur dann eines, wenn ein roter Lauf eine echte Aussage bedeutet. Dazu gehören Tests auf der richtigen Ebene statt möglichst vieler, Prüfungen der Abhängigkeiten und ihrer Lizenzen, das Erkennen bekannter Schwachstellen im Bauprozess und die Frage, wie Fehler im Betrieb sichtbar werden, bevor Anwender sie melden. Sicherheit im Anwendungscode gehört hierher; das organisatorische Schutzniveau steht in der Cyber-Security-Beratung.

Betrieb, Übergabe und Weiterentwicklung

Eine Anwendung ist ab dem ersten Tag im Betrieb ein Dauerposten. Auf dieser Ebene geht es um reproduzierbare Auslieferung, um Beobachtbarkeit im laufenden System und um die Frage, wer die Anwendung nach dem Ende des externen Mandats tatsächlich weiterentwickelt. Eine Übergabe, die aus einer Dokumentation besteht, ist keine — übergeben ist, was das eigene Team ohne Rückfrage geändert hat.

Welche Ebene bei Ihnen den Ausschlag gibt, lässt sich in einem kurzen Gespräch einordnen — meist genügen die Historie der letzten drei Releases und ein Blick auf die Abhängigkeiten.

Zuschnitt

Wie externe Entwicklungskapazität eingebunden wird

In Softwarevorhaben entscheidet neben der Fachtiefe vor allem, wo die Entscheidungshoheit liegt. Wer einen Entwurf verantwortet, braucht andere Befugnisse als wer eine Anforderung umsetzt, und beide brauchen etwas anderes als jemand, der eine bestehende Architektur prüfen soll. Vier Zuschnitte deckt unser Netzwerk regelmäßig ab; sie unterscheiden sich in Entscheidungsspielraum und Einbindungstiefe, nicht im Anspruch.

Entwurf

Zielbild für ein neues System

Eine Architektin oder ein Architekt klärt Fachschnitt, Bausteine und Schnittstellen und hinterlässt begründete Entscheidungen samt Alternativen. Die Umsetzung übernimmt danach das eigene Team oder ein Dienstleister — der Entwurf ist absichtlich so geschrieben, dass beides möglich bleibt.

Umsetzung

Verstärkung im bestehenden Team

Senior-Entwicklerinnen und -Entwickler arbeiten in Ihren Repositories, Ihren Prüfschritten und Ihrem Rhythmus mit. Die fachliche Priorisierung bleibt bei Ihnen; mitgebracht wird Erfahrung mit vergleichbaren Systemen und die Bereitschaft, das eigene Wissen im Team zu verankern.

Verantwortung

Technische Führung auf Zeit

Eine Person übernimmt die technische Verantwortung für eine Anwendung oder ein Team — bei Vakanz, während eines Aufbaus oder wenn eine strittige Architekturentscheidung eine Instanz braucht, die sie trifft und trägt.

Prüfung

Zweitmeinung zu einer Architektur

Ein eng gefasster Auftrag mit Berichtsergebnis: bestehende Architektur, Angebot eines Dienstleisters oder Bau-oder-Kauf-Frage werden geprüft und die Befunde nach Wirkung auf die Änderungskosten sortiert — ohne Anschlussangebot im Rücken.

Domänenlogik

Softwareentwicklung nach Branche: was die Domäne dem Entwurf vorschreibt

Software lässt sich nicht branchenneutral entwerfen, weil die Fachlichkeit die Grenzen des Systems bestimmt und nicht die Technologie. Was in einem Handelsunternehmen ein Auftrag ist, ist in der Versicherung ein Vertrag mit Historie und im Maschinenbau eine Konfiguration mit Stückliste — und diese Unterschiede schlagen bis in den Datenschnitt durch. Ebenso unterschiedlich ist der Rahmen: Wo eine Anwendung in einer Anlage läuft, entscheidet die Betriebssicherheit über die Auslieferungsfrequenz; wo Aufsichtsrecht gilt, ist Nachvollziehbarkeit eine Anforderung an die Architektur und keine Dokumentationsaufgabe; wo Lastspitzen saisonal auftreten, wird der Schnitt entlang der Skalierung gezogen.

Wir besetzen deshalb nach Domänenerfahrung, nicht nur nach Sprache und Framework: Eine Entwicklerin, die Chargenrückverfolgung schon dreimal gebaut hat, stellt am ersten Tag die Fragen, auf die ein fachfremdes Team im dritten Monat stößt. Die folgenden Felder sind der Ausschnitt, in dem wir am häufigsten besetzen — weitere Domänen erschließen wir über das Netzwerk.

Ingenieure prüfen eine Fertigungsanwendung an mehreren Bildschirmen

Industrie & Maschinenbau

Entwicklerteam einer Versicherung arbeitet an einer Bestandsanwendung

Banken & Versicherungen

Mitarbeiterin im Handel nutzt eine Anwendung am Verkaufsort

Handel & E-Commerce

Produktteam eines Softwareanbieters am gemeinsamen Bildschirm

Software & SaaS

Windpark als Sinnbild für Anwendungen bei Energieversorgern

Energie & Versorger

Roboterarm mit Steuerungsbaustein als Bild für eingebettete Software

Automotive & Embedded

Ingenieure prüfen eine Fertigungsanwendung an mehreren Bildschirmen

Industrie & Maschinenbau

Entwicklerteam einer Versicherung arbeitet an einer Bestandsanwendung

Banken & Versicherungen

Mitarbeiterin im Handel nutzt eine Anwendung am Verkaufsort

Handel & E-Commerce

Produktteam eines Softwareanbieters am gemeinsamen Bildschirm

Software & SaaS

Windpark als Sinnbild für Anwendungen bei Energieversorgern

Energie & Versorger

Roboterarm mit Steuerungsbaustein als Bild für eingebettete Software

Automotive & Embedded

Auftragsbilder

Auftragsbilder in Softwarevorhaben und ihr Prüfstein

Was in der Softwareentwicklung beauftragt wird, fällt zum größten Teil in wenige wiederkehrende Bilder. Für jedes gibt es einen Prüfstein — die Größe, an der sich nach Abschluss zeigt, ob der Auftrag etwas verändert hat. Ohne diesen Prüfstein endet ein Vorhaben mit einer Lieferung statt mit einem Ergebnis.

Neuentwicklung einer Fachanwendung

Ausgangslage: Ein Prozess läuft über Tabellen und Zurufe, eine Standardlösung passt nicht auf die Besonderheit, die das Geschäft ausmacht. Gebaut wird zuerst der Kern, der diese Besonderheit trägt, alles Übrige wird zugekauft oder angebunden. Prüfstein: die Durchlaufzeit des unterstützten Prozesses und der Anteil manueller Nacharbeit — nicht die Zahl umgesetzter Anforderungen.

Ablösung eines Altsystems

Ausgangslage: Eine tragende Anwendung ist technisch am Ende, fachlich aber unverzichtbar und nirgends vollständig beschrieben. Abgelöst wird in Abschnitten mit Parallelbetrieb, beginnend an der Stelle mit dem geringsten Rückweg. Prüfstein: der Anteil des Altsystems, der nachweislich abgeschaltet ist — ein zu 90 Prozent ersetztes System kostet so viel wie ein ganzes.

Architektur-Review vor der Entscheidung

Ausgangslage: Ein Entwurf liegt vor — aus dem eigenen Haus oder von einem Anbieter — und es fehlt eine unabhängige Einschätzung, bevor Budget gebunden wird. Geprüft werden Fachschnitt, Abhängigkeiten, Betriebsannahmen und die Frage, was der Entwurf im Fall einer Kehrtwende kostet. Prüfstein: benannte Risiken mit Eintrittsbedingung und eine Aussage zur Umkehrbarkeit jeder tragenden Festlegung.

Verstärkung für ein laufendes Vorhaben

Ausgangslage: Der Zieltermin steht, das Team trägt parallel den Betrieb, und die gesuchten Profile sind nicht kurzfristig festanstellbar. Ergänzt wird innerhalb der bestehenden Arbeitsweise, nicht als zweites Team daneben. Prüfstein: die Auslieferungsfrequenz nach dem Zugang — steigt sie nicht innerhalb weniger Wochen, war nicht Kapazität der Engpass.

Wie aus einem Architekturentwurf lauffähige Software wird

Umfang und Reihenfolge der Abschnitte hängen davon ab, wie viel Fachlogik im Spiel ist, wie viele Systeme angebunden sind und wie viel Rückweg jede Festlegung lassen muss. Die Folge selbst ist stabil: Was übersprungen wird, kommt später als Sonderfall zurück.

Auswertung von Abhängigkeiten und Auslieferungshistorie einer Anwendung

1. Bestandsaufnahme statt Vermutung

Abhängigkeiten, Änderungshäufigkeit und Fehlerlast je Systemteil erheben — die Stellen mit beiden Eigenschaften sind die teuren.
Auslieferungshistorie lesen: Frequenz, Dauer, Rückrollungen und was ein Release im Haus an Abstimmung kostet.
Wissensverteilung offenlegen: Wer kann welchen Teil ändern, und was passiert, wenn diese Person nicht verfügbar ist.
Erarbeitung des fachlichen Systemschnitts an der Wand

2. Fachlicher Schnitt und Zielbild

Begriffe und Datenhoheit je Bereich festlegen — inklusive der Stellen, an denen zwei Bereiche dasselbe Wort verschieden verwenden.
Bausteine, Verantwortungen und Schnittstellen des Zielbilds benennen und die Zuschnitthöhe begründen.
Jede tragende Festlegung mit Alternative, Grund und Umkehrbarkeit dokumentieren.
Entwicklung eines ersten Systemausschnitts als Referenz

3. Referenzimplementierung eines Ausschnitts

Einen fachlich vollständigen, technisch schmalen Ausschnitt bauen — von der Eingabe bis in die Persistenz.
Auslieferungsweg, Prüfschritte und Beobachtbarkeit an diesem Ausschnitt einmal vollständig durchziehen.
Aus dem Ergebnis die Annahmen des Zielbilds korrigieren, solange das noch billig ist.
Entwicklerteam richtet automatisierte Prüfungen für die Auslieferung ein

4. Prüfnetz mit Aussagekraft

Tests auf der Ebene ansetzen, auf der sie eine Aussage treffen — fachliche Regeln nah am Kern, Zusammenspiel an den Grenzen.
Abhängigkeiten, Lizenzen und bekannte Schwachstellen im Bauprozess prüfen, nicht in einem Jahresaudit.
Grenzwerte festlegen, bei deren Überschreitung nicht ausgeliefert wird — und sie einhalten.
Abstimmung zur schrittweisen Ablösung einer Altanwendung

5. Schrittweise Ersetzung im Parallelbetrieb

Abschnitte in der Reihenfolge des geringsten Rückwegs ablösen, alter und neuer Weg laufen befristet parallel.
Je Abschnitt vorher festlegen, woran der Erfolg gemessen wird und wann zurückgeschaltet wird.
Abgelöste Teile tatsächlich abschalten — ein nicht abgeschaltetes Altsystem verdoppelt die Pflege.
Internes Team übernimmt die Weiterentwicklung der Anwendung

6. Übergabe und Weiterentwicklung im Haus

Übergabe daran messen, dass das eigene Team eine Änderung ohne Rückfrage ausgeliefert hat.
Entscheidungsdokumentation, Betriebsanleitung und Bereitschaftswege an eine benannte Rolle übergeben.
Restpunkte und bewusst offengelassene Stellen als Liste hinterlassen, nicht als mündliche Anmerkung.
Tagessatzspannen

Was Softwareentwicklung mit externen Fachleuten kostet

Externe Unterstützung in Entwicklung und Architektur wird bei uns nach Tagessatz abgerechnet, nicht nach Projektpauschale. Der Satz ergibt sich aus fünf Größen: der Entwurfsverantwortung im Auftrag (Architekturrollen liegen über reinen Umsetzungsrollen), der Seltenheit des Technologieprofils, der Domäne und ihrem Nachweisbedarf, dem Präsenzanteil vor Ort sowie der Mandatsdauer — längere Mandate liegen pro Tag niedriger.

Die Spannen unseres Bestands im Fachbereich Software Engineering & Architektur liegen aktuell zwischen 450 € und 1.200 € pro Tag. Je Rolle ausgewiesen sieht das so aus:

Jede Spanne ist auf der jeweiligen Rollenseite ausgewiesen — nicht auf Anfrage.

Wie sich ein Vorhaben budgetieren lässt. Gerechnet wird in Personentagen, nicht in einer Gesamtsumme. Eine Bestandsaufnahme mit Abhängigkeits- und Änderungsanalyse liegt für eine mittelgroße Anwendung meist bei 10 bis 20 Personentagen. Ein Zielbild samt Referenzausschnitt eher bei 30 bis 60 Tagen. Eine Ablösung wird in Abschnitten gerechnet, damit nach jedem Abschnitt entscheidbar ist, ob der nächste den Aufwand rechtfertigt. Verstärkung im laufenden Team rechnet anders: drei bis fünf Tage pro Woche über sechs bis achtzehn Monate.

Der aussagekräftigere Vergleich ist nicht der Tagessatz, sondern der Aufwand der Änderung, die Sie sich damit erkaufen: Wenn eine typische Erweiterung heute vierzig Personentage kostet und nach dem Entwurf zwölf, ist ein Zielbild über dreißig Tage nach zwei Erweiterungen eingespielt. Wo eine Anwendung ohnehin nur noch einmal im Jahr angefasst wird, lohnt kein Umbau — diese Antwort geben wir vor dem Angebot.

Was ein Netzwerk anders abrechnet als ein Lieferwerk. Bezahlt wird die Person, die entwirft oder entwickelt, und keine Struktur über ihr: kein Engagement Manager, kein Partneranteil, keine Sockelkosten für Methodik. Dafür bekommen Sie kein Lieferwerk — Sie beauftragen einzelne Fachleute oder ein kleines Team und behalten die Produktverantwortung im Haus. Festpreise auf Basis eines Lastenhefts bilden wir nicht ab: sie setzen den Anreiz, den Umfang zu verteidigen, statt die Lösung zu verbessern.

Welches Profil trägt, entscheidet die Ebene der Unklarheit: Ein Zielbild verlangt andere Erfahrung als die Ablösung eines gewachsenen Altsystems. Die vollständige Übersicht steht unter Software Engineering & Architektur — darunter Software Architekt, API Architekt, Full Stack Developer, Backend Developer und Mobile Testing Engineer. Für angrenzende Aufgaben ergänzen Cloud, Infrastruktur & DevOps, Data Engineering & Data Science, Product Management & UX und Cybersecurity.

Marktzahlen

Offene IT-Stellen bleiben im Schnitt über ein halbes Jahr unbesetzt

109.000

Stellen für IT-Fachkräfte waren 2025 in Deutschland unbesetzt — die Lücke trifft Entwicklung und Architektur genauso wie den Betrieb.
Bitkom, Der Arbeitsmarkt für IT-Fachkräfte, Studienbericht 2025

7,7 Monate

dauert es im Durchschnitt, bis eine IT-Stelle besetzt ist — Zeit, die ein beschlossenes Vorhaben selten hat.
Bitkom, Der Arbeitsmarkt für IT-Fachkräfte, Studienbericht 2025

12 %

der Unternehmen setzen verstärkt externe IT-Fachkräfte ein, um die Lücke zu schließen, statt weiter auf eine Festanstellung zu warten.
Bitkom, Der Arbeitsmarkt für IT-Fachkräfte, Studienbericht 2025
Nachgefragt

Wiederkehrende Fragen zu externer Softwareentwicklung

Softwareentwicklungsberatung unterstützt Unternehmen dabei, eigene Software so zu entwerfen, zu bauen und weiterzuentwickeln, dass Änderungen auch nach Jahren bezahlbar bleiben. Sie umfasst den fachlichen Systemschnitt, das Architekturzielbild, Schnittstellen und Datenhoheit, das Prüfnetz aus automatisierten Tests und Sicherheitschecks sowie die Übergabe in den Betrieb. Der Unterschied zur reinen Programmierleistung liegt in der Begründung: Nicht nur was gebaut wird, sondern warum es so geschnitten ist und was die Alternative gekostet hätte.
Ein Softwarearchitekt legt fest, aus welchen Bausteinen ein System besteht, welcher Baustein welche Verantwortung trägt und wie sie zusammenspielen — und dokumentiert die Gründe. Gebraucht wird die Rolle, sobald eine Festlegung schwer umkehrbar ist: bei einem neuen System, bei der Ablösung eines Altsystems, bei der Aufteilung eines gewachsenen Monolithen oder wenn mehrere Teams an derselben Fachlichkeit arbeiten. Für eine abgegrenzte Erweiterung innerhalb bestehender Grenzen genügt in der Regel Umsetzungserfahrung.
Die Tagessätze in unserem Bestand im Fachbereich Software Engineering & Architektur liegen zwischen 450 € und 1.200 €. Umsetzungsrollen für verbreitete Technologien liegen im unteren Bereich, Architekturrollen und seltene Profile wie eingebettete Software oder Legacy-Modernisierung im oberen. Jede Spanne ist auf der jeweiligen Rollenseite ausgewiesen — die Kacheln in diesem Abschnitt lesen dieselben Werte, damit Seite und Angebot nicht auseinanderlaufen.
Von der Entwurfsverantwortung im Auftrag, von der Seltenheit der Technologie- und Domänenkombination, vom Nachweisbedarf der Branche, vom Präsenzanteil vor Ort und von der Mandatsdauer. Eine Architekturrolle mit Entscheidungshoheit und Nachweispflicht im regulierten Umfeld liegt deutlich über einer Umsetzungsrolle in einer verbreiteten Sprache. Längere Mandate liegen pro Tag niedriger, weil Einarbeitung und Verfügbarkeitsrisiko sich verteilen.
An der Frage, ob der betroffene Prozess Ihr Geschäft unterscheidbar macht. Wo ein Prozess bei allen Wettbewerbern gleich läuft, ist Standardsoftware fast immer günstiger — auch wenn sie Anpassung im Ablauf verlangt. Eigenentwicklung lohnt an den wenigen Stellen, an denen die Besonderheit den Ertrag trägt. Der teuerste Weg ist der dritte: eine Standardlösung so weit anzupassen, dass sie de facto eine Eigenentwicklung ist, aber deren Änderungsfreiheit nicht hat.
Indem in Abschnitten abgelöst wird und alter wie neuer Weg befristet parallel laufen. Begonnen wird an der Stelle mit dem geringsten Rückweg, damit ein Fehlschlag früh und billig sichtbar wird. Je Abschnitt wird vorher festgelegt, woran der Erfolg gemessen und wann zurückgeschaltet wird. Entscheidend ist das Abschalten: Ein zu 90 Prozent ersetztes Altsystem verursacht nahezu den vollen Pflegeaufwand und macht die Rechnung des Vorhabens zunichte.
An drei messbaren Größen, die kein Fachwissen über den Code verlangen: wie lange eine vergleichbare Änderung heute gegenüber vor einem Jahr dauert, wie viele Systemteile eine durchschnittliche Anforderung berührt, und wie hoch der Anteil der Fehler ist, die erst im Betrieb auffallen. Steigen alle drei gemeinsam, ist es keine Personalfrage. Eine Bestandsaufnahme legt dann die Stellen offen, an denen häufige Änderung und hohe Fehlerlast zusammenfallen — dort liegt der Hebel.
In Ihrer Arbeitsweise, nicht neben ihr: gleiche Repositories, gleiche Prüfschritte, gleiche Auslieferungswege, gemeinsame Priorisierung. Ein getrenntes externes Team erzeugt eine Schnittstelle, die anschließend gepflegt werden muss, und verlagert das Wissen nach außen. Zur Einbindung gehört von Beginn an, dass eigene Leute an denselben Stellen arbeiten — sonst ist die Übergabe am Ende ein zweites Projekt. Wie das im Team organisiert wird, beschreibt die Agile Transformation.
Sie können sich auf uns verlassen

Ausgezeichnet. Finden nicht nur wir selbst.

consultingheads wurde mehrfach von führenden Fachmagazinen und unabhängigen Dritten ausgezeichnet.

Auszeichnung für consultingheads: F.A.Z. Institut TOP Berater 2026
Auszeichnung für consultingheads: brand eins Beste Unternehmensberater 2025
Auszeichnung für consultingheads: kununu Top Company 2025
Auszeichnung für consultingheads: kununu Top Company 2024
Auszeichnung für consultingheads: brand eins Beste Unternehmensberater 2024
Auszeichnung für consultingheads: kununu Top Company 2023
Auszeichnung für consultingheads: brand eins Beste Unternehmensberater 2021
Auszeichnung für consultingheads: brand eins Beste Unternehmensberater 2020
Auszeichnung für consultingheads: brand eins Beste Berater 2019
Auszeichnung für consultingheads: brand eins Beste Unternehmensberater 2026
Auszeichnung für consultingheads: F.A.Z. Institut TOP Berater 2026
Auszeichnung für consultingheads: brand eins Beste Unternehmensberater 2025
Auszeichnung für consultingheads: kununu Top Company 2025
Auszeichnung für consultingheads: kununu Top Company 2024
Auszeichnung für consultingheads: brand eins Beste Unternehmensberater 2024
Auszeichnung für consultingheads: kununu Top Company 2023
Auszeichnung für consultingheads: brand eins Beste Unternehmensberater 2021
Auszeichnung für consultingheads: brand eins Beste Unternehmensberater 2020
Auszeichnung für consultingheads: brand eins Beste Berater 2019
Auszeichnung für consultingheads: brand eins Beste Unternehmensberater 2026
bildmarke
brand eins Beste Unternehmensberater 2026 — consultingheads
Erstgespräch

Sprechen wir über Ihre Codebasis.

Einordnung Ihrer Änderungskosten in zwanzig Minuten
Eine benannte Ebene statt einer Technologieempfehlung
Jede Tagessatzspanne steht offen auf der Rollenseite
Zwanzig Minuten, in denen wir Ihre Ausgangslage einordnen und benennen, auf welcher Ebene die Unklarheit sitzt — und ob wir dafür der richtige Partner sind.