In meiner über 30-jährigen Karriere in der IT – in verschiedenen Unternehmen, verschiedenen Ländern und verschiedenen Positionen – habe ich eine Gemeinsamkeit immer wieder beobachtet: Den Umfang der Softwareentwicklung zu unterschätzen, ist weit verbreitet. Und die Konsequenzen davon treffen selten diejenigen, die die Entscheidungen getroffen haben.
Sie treffen die Support-Mitarbeiter, die täglich mit Anfragen überflutet werden, welche bei einem vollständig durchdachten Produkt nie entstanden wären. Sie treffen die Kunden, die mit Betriebsunterbrechungen umgehen müssen – und dabei nicht selten auch ihre eigene Reputation gegenüber ihren Kunden gefährden. Und sie treffen die Entwicklerinnen und Entwickler, die Systeme warten müssen, die nie vollständig dokumentiert, getestet oder skalierbar konzipiert wurden.
Betriebswirtschaftliche Kalkulationen in Boardrooms und Budgetsitzungen sehen auf dem Papier oft sauber aus. Der Grund ist simpel: Sie berücksichtigen einzelne Elemente – aber nie das vollständige Gesamtbild.
Genau hier setzt ALEM an.
Was ist ALEM?
ALEM – Application Lifecycle & Engineering Model – ist ein vollständiges Referenzmodell, das alle Bereiche einer modernen Softwareapplikation strukturiert, benennt und in einen nachvollziehbaren Zusammenhang bringt. Es wurde aus Hersteller-Perspektive entwickelt und richtet sich gleichermassen an Unternehmerinnen und Unternehmer als auch an alle, die operativ für Applikationen verantwortlich sind.
ALEM ist kein akademisches Konstrukt. Es ist das Ergebnis von drei Jahrzehnten praktischer IT-Erfahrung – verdichtet in ein Modell, das alle beteiligten Parteien eine gemeinsame Sprache sprechen lässt.
Das Modell strukturiert eine Applikation in 18 Domänen innerhalb von 5 Zonen, ergänzt durch 4 übergreifende Querschnittsthemen und 3 Design Principles als Qualitätsmassstab.
Die 5 Zonen – ein strukturierter Überblick
ALEM gliedert eine Softwareapplikation in fünf klar voneinander abgegrenzte Zonen. Jede Zone steht für einen spezifischen Verantwortungsbereich – mit konkreten Domänen, Werkzeugen und Standards.
🔵 Zone 1 – Strategy
Die Strategy-Zone beantwortet die Frage: Wohin entwickeln wir die Applikation, und unter welchen Rahmenbedingungen? Sie umfasst vier Domänen:
- 01 · Anforderungsmanagement – systematische Erfassung und Priorisierung von Benutzerbedürfnissen (User Stories, Lastenheft, MoSCoW)
- 02 · Feature Request Management – strukturierter Umgang mit Kundenwünschen und Produktweiterentwicklung
- 03 · Vertragsmanagement / SLA – Definition und Überwachung aller vertraglichen Verpflichtungen (Uptime, RTO, RPO)
- 04 · Kosten & Lizenzmanagement – vollständige Transparenz über Infrastrukturkosten, Lizenzmodelle und TCO
🟢 Zone 2 – User
Die User-Zone stellt den Menschen ins Zentrum aller Entscheidungen. Sie umfasst drei Domänen:
- 05 · Benutzerbedürfnisse & UX – User Research, GUI-Design, Usability Testing, Accessibility (WCAG 2.1)
- 06 · Identity & Access Management – Authentifizierung (SSO, MFA, OAuth 2.0) und Autorisierung (RBAC, ABAC)
- 07 · Benutzerschulung & Enablement – aktive Befähigung aller Nutzer; das Bindeglied zwischen GUI und Mensch
🟣 Zone 3 – Engineering
Die Engineering-Zone beschreibt den technischen Bau der Applikation. Sie umfasst vier Domänen:
- 08 · Application Core – Geschäftslogik, APIs (REST, GraphQL), Microservices, Event-Bus
- 09 · Data Management – Datenbanken, Migration, Backup & Recovery, Retention-Policies
- 10 · Testing & Qualitätssicherung – Unit Tests, E2E, Performance, User Acceptance Testing, CI/CD
- 11 · Dokumentation & Wissensmanagement – API-Docs, Architektur-Dokumentation, Wissensdatenbank, Onboarding
🔴 Zone 4 – Trust
Die Trust-Zone ist strukturell besonders: Sie enthält ausschliesslich Querschnittsthemen – Domänen, die keine isolierte Schicht bilden, sondern alle anderen Zonen vertikal durchdringen. Sie umfasst zwei Domänen:
- 12 · Security ◈ – Zero Trust Architecture, Verschlüsselung, Penetration Testing, Incident Response
- 13 · Compliance & Governance ◈ – DSGVO, NIS2, ISO/IEC 27001, SOC 2, Risikomanagement
Das Symbol ◈ kennzeichnet Querschnittsthemen: Sie sind nicht optional – sie betreffen jede Zone gleichzeitig.
🟡 Zone 5 – Operations
Die Operations-Zone umfasst alles, was nach der Entwicklung passiert: Betrieb, Pflege und Weiterentwicklung. Sie enthält fünf Domänen:
- 14 · Infrastructure & Hosting – Cloud, Docker/Kubernetes, IaC (Terraform, Ansible), Disaster Recovery
- 15 · Observability & Monitoring ◈ – Prometheus, Grafana, OpenTelemetry, SLI/SLO/SLA-Messung
- 16 · Release & Versionierung – Semantic Versioning, CI/CD Pipelines, Blue/Green Deployments
- 17 · Support & Incident Management – P1–P4-Priorisierung, Eskalationspfade, Post-Mortem, SLA-Tracking
- 18 · Change Management – organisatorische Begleitung von Veränderungen, Train-the-Trainer, Migrationspläne
Die 3 ALEM Design Principles
Ergänzend zu den 18 Domänen definiert ALEM drei übergreifende Design Principles – keine eigene Zone, sondern ein Qualitätsmassstab, der bei jeder Entscheidung in jeder Domäne anzuwenden ist:
- Benutzerfreundlichkeit – Können Nutzer ihre Ziele effizient und mit Zufriedenheit erreichen, unabhängig von ihrer technischen Vorerfahrung?
- Benutzerfreundliches GUI – Ist die Oberfläche visuell klar, konsistent und auf Anhieb verständlich?
- Simplicity – Ist die Lösung so einfach wie möglich gestaltet? Wird Komplexität reduziert – und nicht lediglich versteckt?
„Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.“
– Antoine de Saint-Exupéry
ALEM in der Praxis: Dokumentenmanagementsystem
Um zu zeigen, wie ALEM konkret angewendet wird, betrachten wir den Einführungsfall eines Enterprise Dokumentenmanagementsystems in einer grossen Organisation mit mehreren Abteilungen.
Bei einem solchen Projekt sind nicht alle 18 Domänen gleich gewichtet – aber alle sind präsent. Folgende Domänen erweisen sich als besonders kritisch:
Besonders hervorzuheben ist Domäne 07 – Benutzerschulung & Enablement: Mitarbeiterinnen und Mitarbeiter ohne technische Affinität nutzen das System täglich. Keine noch so gute Software entfaltet ihren Wert, wenn die Nutzer nicht aktiv befähigt werden, sie zu verwenden. Schulung ist kein optionaler Aufwand – sie ist eine Investition in die Akzeptanz und damit in den Return on Investment des gesamten Projekts.
Ebenso unverzichtbar ist Domäne 18 – Change Management: Ein organisationsweiter Rollout, der hunderte von Nutzern betrifft, scheitert nicht an der Technologie. Er scheitert am Menschen. ALEM adressiert dies explizit als eigenständige Domäne.
Die Investitionsfrage – und die ehrliche Antwort
Ja – es ist richtig: Wer ALEM in der Softwareentwicklung tatsächlich vollständig umsetzen möchte, muss investieren. In Menschen, in Prozesse, in Werkzeuge. Das ist keine Frage der Meinung, sondern der Realität.
Die entscheidende Frage ist jedoch nicht, ob diese Investitionen notwendig sind. Die entscheidende Frage ist, ob man die Kosten des Nicht-Investierens wirklich vollständig in die Kalkulation einbezieht.
Der Return on Investment eines vollständig umgesetzten ALEM übersteigt die getätigten Investitionen bei weitem. Und dieser Return ist nicht nur finanzieller Natur. Er zeigt sich in Bereichen, die sich nur schwer in Zahlen fassen lassen – die aber langfristig über den Erfolg eines Unternehmens entscheiden:
- Das Ansehen und die Reputation des herstellenden Unternehmens im Markt
- Die Identifikation der Kunden mit dem Produkt und dem Unternehmen dahinter
- Der Respekt der Mitbewerber im gleichen Marktsegment
- Die Identifikation der eigenen Mitarbeiterinnen und Mitarbeiter mit ihrer Arbeit und ihrem Arbeitgeber
In über 30 Jahren IT-Erfahrung habe ich nur sehr wenige Unternehmen gesehen, die diese Zusammenhänge wirklich verstanden und konsequent umgesetzt haben. Eines davon war ein Unternehmen in den USA – gegründet von einem Visionär, der leider viel zu früh an Krebs gestorben ist – und das heute einen Unternehmenswert von über einer Milliarde Dollar hat. Kein Zufall.
Fazit: Die Wahl liegt bei Ihnen
Sie können weiterhin kostengünstige Erklärungen dafür finden, warum die notwendigen Investitionen und Aufwände gerade nicht möglich sind – und weiterhin in knietiefem Sumpf versuchen zu rennen.
Oder Sie nehmen sich die Zeit, ALEM zu verstehen, es zu verinnerlichen, ernsthaft darüber nachzudenken – und dann neu zu entscheiden, was für eine Art von Softwarehersteller Sie sein möchten.
Das Modell ist offen. Die Entscheidung liegt bei Ihnen.
Über den Autor
Dimitri Rupp ist Gründer von Lumi-Systems.io und IT-Spezialist mit über 30 Jahren Erfahrung in der Softwarebranche – in Positionen von technischem Support bis hin zu Head of Operations und AI & Cloud Solutions. ALEM ist das Ergebnis dieser Erfahrung: ein praxiserprobtes Modell für alle, die Software nicht nur entwickeln, sondern wirklich verstehen wollen.
📎 Die vollständige ALEM-Dokumentation sowie die interaktive Präsentation sind auf Anfrage erhältlich.
📬 Kontakt: dimitri.rupp@lumi-systems.io
