Wissensdatenbank

Glossar: Fachbegriffe für App-Entwicklung & Industrie 4.0

29 Begriffe quellenbasiert erklärt — von DSGVO und MDR über Cross-Platform und Microservices bis zu MES und Predictive Maintenance. Alle Inhalte mit Datum der letzten Verifikation und mit Verlinkung der Originalquellen.

Direkt zu

Regulatorisch & Compliance 8

Architektur & Technologie 10

Industrie & B2B 6

Projekt & Methodik 5

Regulatorisch & Compliance

Datensouveränität

#

Die Fähigkeit einer Organisation, die Speicherung, Verarbeitung und den Zugriff auf ihre Daten unter ihrer eigenen Kontrolle zu halten — einschließlich der Wahl von Anbietern, Standorten und Schlüsseln.

Datensouveränität ist kein einzelnes Gesetz, sondern ein Architekturprinzip. Es kombiniert mehrere Ebenen: rechtliche Souveränität (welche Jurisdiktion hat Zugriff?), operative Souveränität (wer verwaltet die Infrastruktur?), und technische Souveränität (Verschlüsselung, Schlüsselverwaltung, Open-Source-Komponenten). In der Praxis bedeutet das im DACH-Raum oft: Hosting in der EU, eigene Schlüsselverwaltung (BYOK / HYOK), Vermeidung der Übermittlung in Länder mit US-CLOUD-Act-Zugriff, sowie Bevorzugung europäischer Hyperscaler-Alternativen oder selbstverwalteter Infrastruktur. Initiativen wie Gaia-X formalisieren Bewertungskriterien.
Warum es zählt

Im DACH-Mittelstand wird Datensouveränität zunehmend zum harten Ausschreibungskriterium — insbesondere bei Maschinenbau, Healthcare und öffentlicher Hand.

Quellen

Verifiziert 2026-04-30

DSGVO-konforme App · DSGVO / GDPR

#

Eine App, deren Datenverarbeitung den Anforderungen der EU-Datenschutz-Grundverordnung (Verordnung (EU) 2016/679) entspricht — insbesondere Rechtsgrundlage, Zweckbindung, Datenminimierung, Betroffenenrechte und Rechenschaftspflicht.

Die DSGVO ist seit dem 25. Mai 2018 in allen EU-Mitgliedstaaten unmittelbar anwendbar. Für mobile Anwendungen bedeutet DSGVO-Konformität nicht nur eine Datenschutzerklärung im App-Store-Listing — sondern Privacy by Design und Privacy by Default (Art. 25 DSGVO), eine dokumentierte Rechtsgrundlage für jede einzelne Verarbeitungstätigkeit, ein Verzeichnis der Verarbeitungstätigkeiten (Art. 30), aktive Implementierung der Betroffenenrechte (Auskunft, Löschung, Datenübertragbarkeit), Auftragsverarbeitungsverträge mit allen Drittanbietern und gegebenenfalls eine Datenschutz-Folgenabschätzung. Der Standort der Datenverarbeitung ist relevant: Übermittlungen in Drittländer benötigen ein zusätzliches Übermittlungsinstrument (z. B. Standardvertragsklauseln nach dem Schrems-II-Urteil des EuGH).
Warum es zählt

Bußgelder können bis zu 20 Mio. € oder 4 % des weltweiten Konzernumsatzes erreichen — und Auftraggeber im DACH-Mittelstand verlangen DSGVO-Konformität als Standard-Zusicherung in jedem App-Vertrag.

Verwandt im Service-Portfolio
Quellen

Verifiziert 2026-04-30

EU AI Act

#

Verordnung (EU) 2024/1689 zur Regulierung künstlicher Intelligenz. Tritt phasenweise zwischen August 2024 und August 2027 in Kraft.

Der EU AI Act trat am 1. August 2024 in Kraft. Die Bestimmungen werden in mehreren Stufen anwendbar: 2. Februar 2025 — Verbote bestimmter KI-Praktiken (Art. 5) und KI-Kompetenz-Pflicht (Art. 4); 2. August 2025 — Pflichten für Anbieter von General-Purpose-AI-Modellen (Art. 51–56); 2. August 2026 — die meisten Pflichten für Hochrisiko-KI-Systeme nach Anhang III, Transparenzpflichten nach Art. 50 sowie Sanktionen; 2. August 2027 — Hochrisiko-KI in regulierten Produkten (Anhang I). Der "Digital Omnibus"-Vorschlag der Kommission (November 2025) kann die Anhang-III-Frist auf den 2. Dezember 2027 verschieben — die Annahme durch Rat und Parlament steht aus.
Warum es zählt

Wer KI-Komponenten in Apps integriert (z. B. LLM-basierte Assistenten, automatisierte Entscheidungen im HR- oder Kreditbereich), muss prüfen, ob die Anwendung als Hochrisiko-System eingestuft wird — und entsprechende Risiko-, Daten- und Transparenz-Pflichten erfüllen.

Quellen

Verifiziert 2026-04-30

EU Data Act

#

Verordnung (EU) 2023/2854 über harmonisierte Vorschriften für einen fairen Datenzugang und eine faire Datennutzung — gilt seit dem 12. September 2025.

Der EU Data Act trat am 11. Januar 2024 in Kraft und ist seit dem 12. September 2025 vollständig anwendbar. Er gewährt Nutzerinnen und Nutzern vernetzter Produkte (Smartwatches, Maschinen, Fahrzeuge) das Recht, die durch ihre Nutzung erzeugten Daten einzusehen, zu nutzen und an Dritte weiterzugeben. Hersteller solcher Produkte müssen Geräte und zugehörige Dienste so gestalten, dass dieser Datenzugriff technisch möglich ist — und sie müssen die Bereitstellung der Daten zu fairen, angemessenen und nichtdiskriminierenden Bedingungen anbieten. Für Cloud- und SaaS-Anbieter regelt der Data Act zusätzlich den Anbieterwechsel (Switching) und untersagt unfaire Datenklauseln in Verträgen.
Warum es zählt

Industrieprodukte mit Telemetrie (z. B. IoT-Sensorik, vernetzte Maschinen, Fahrzeugflotten) müssen ein Self-Service-Datenzugriffs-Interface anbieten — typischerweise umgesetzt als Kundenportal mit strukturiertem Datenexport.

Verwandt im Service-Portfolio
Quellen

Verifiziert 2026-04-30

EU-Batteriepass

#

Digitaler Produktpass nach Verordnung (EU) 2023/1542. Verpflichtend ab dem 18. Februar 2027 für EV-Batterien, LMT-Batterien und industrielle Batterien mit mehr als 2 kWh Kapazität.

Der EU-Batteriepass ist Teil der EU-Batterieverordnung (Verordnung (EU) 2023/1542), die seit dem 18. Februar 2024 Anwendung findet. Ab dem 18. Februar 2027 müssen alle Elektrofahrzeug-Batterien, Batterien für leichte Transportmittel (LMT, z. B. E-Bikes) sowie industrielle Batterien über 2 kWh — gleichzeitig mit der Erstinverkehrbringung — einen Batteriepass tragen. Der Pass enthält strukturierte Daten zu Material­zusammensetzung, CO₂-Fußabdruck, Recyclinganteilen, Lebenszyklus, Reparierbarkeit und Verantwortlichen entlang der Lieferkette. Zugriff erfolgt über einen QR-Code, mit rollenbasierter Sichtbarkeit für Endkunden, Recycler und Marktüberwachungsbehörden.
Warum es zählt

Hersteller mit betroffenen Batterien benötigen ab 2027 ein Daten-Backend mit unveränderlichem Geburts-Snapshot pro Einheit, einer rollenbasierten QR-Schnittstelle und einer Anbindung an Recycling- und Servicepartner.

Verwandt im Service-Portfolio
Quellen

Verifiziert 2026-04-30

IEC 62304

#

Internationale Norm für den Software-Lebenszyklus von Medizinprodukten. Aktuell gültig in der konsolidierten Fassung IEC 62304:2006/AMD1:2015.

IEC 62304 definiert Lebenszyklus-Anforderungen für medizinische Software — von der Anforderungsanalyse über Architektur, Implementierung, Verifikation und Release bis hin zur Pflege. Die Norm klassifiziert Software in drei Sicherheitsklassen (A, B, C) basierend auf möglichem Schadenspotenzial. Klasse A bedeutet keine Verletzung oder Schaden möglich; Klasse C bedeutet möglicher Tod oder schwere Verletzung. Höhere Klassen erfordern detailliertere Architekturpläne, Unit-Tests, Integrationstests und Dokumentation der SOUP (Software of Unknown Provenance, also Drittkomponenten). IEC 62304 ist in der EU als harmonisierte Norm für die MDR anerkannt — Konformität bedeutet Konformitätsvermutung gegenüber den Software-Anforderungen der MDR.
Quellen

Verifiziert 2026-04-30

ISO/IEC 27001

#

Internationaler Standard für Informationssicherheits-Managementsysteme (ISMS). Aktuelle Fassung: ISO/IEC 27001:2022 (3. Edition).

ISO/IEC 27001 wurde am 25. Oktober 2022 in der dritten Edition veröffentlicht. Sie definiert Anforderungen an Aufbau, Betrieb und kontinuierliche Verbesserung eines ISMS — also einer dokumentierten und auditierten Struktur zur Steuerung von Informationssicherheits-Risiken. Die Übergangsfrist für die alte Fassung (ISO/IEC 27001:2013) endete am 31. Oktober 2025; alle gültigen Zertifikate basieren seither auf der 2022er-Fassung. Annex A enthält 93 Maßnahmen, organisiert in vier Themen (organisatorisch, personell, physisch, technologisch). Eine Ergänzung (ISO/IEC 27001:2022/Amd 1:2024) integriert Klimathemen in die Anforderungen.
Warum es zählt

Großkunden (Versicherer, Banken, regulierte Branchen) verlangen ISO-27001-Zertifizierung von ihren Software-Lieferanten oder zumindest die Bereitschaft, einen entsprechenden Sicherheits-Audit-Fragebogen zu beantworten.

Quellen

Verifiziert 2026-04-30

MDR (Medizinprodukteverordnung) · MDR

#

Verordnung (EU) 2017/745 über Medizinprodukte. Software, die einen medizinischen Zweck erfüllt, gilt als Medizinprodukt und unterliegt einer risikoklassenbasierten Konformitätsbewertung.

Die MDR ist seit dem 26. Mai 2021 anwendbar und ersetzt die alten Richtlinien 90/385/EWG und 93/42/EWG. Software als Medizinprodukt (Software as a Medical Device, SaMD) wird nach den Klassifizierungsregeln der MDR — insbesondere Regel 11 — eingestuft. Die meisten klinischen Entscheidungs-Apps fallen mindestens in Klasse IIa, was eine Konformitätsbewertung durch eine Benannte Stelle, ein Qualitätsmanagementsystem nach ISO 13485, klinische Bewertung und Post-Market Surveillance erfordert. Die Verordnung (EU) 2024/1860 (in Kraft seit dem 9. Juli 2024) verlängerte die Übergangsfristen für Bestandsgeräte und führte eine Pflicht zur Vorabmeldung bei Lieferunterbrechungen ein.
Warum es zählt

Wer eine medizinische App vermarktet, muss Klassifizierung, klinische Bewertung, Risikomanagement (ISO 14971) und Software-Lebenszyklus (IEC 62304) belegen — das prägt Architektur, Dokumentation und Release-Prozess von Tag eins an.

Quellen

Verifiziert 2026-04-30

Architektur & Technologie

Backend-as-a-Service · BaaS

#

Managed Backend-Plattformen, die Authentifizierung, Datenbank, Storage, Funktionen und Push-Dienste als Cloud-Service anbieten — z. B. Firebase, Supabase, AWS Amplify.

BaaS-Lösungen beschleunigen Time-to-Market signifikant: anstelle eines eigenen Backend-Stacks (API, Auth, Datenbank, Worker) wird der Plattform-Stack genutzt. Der Trade-off ist Lock-in — Datenmodell, Auth-System und Funktionen folgen der Plattformsemantik, ein Wechsel bedeutet meist eine vollständige Backend-Migration. Firebase (Google) und Supabase (Open-Source-Alternative auf PostgreSQL-Basis) sind die meistgenutzten Optionen im Cross-Platform-App-Bereich. BaaS eignet sich gut für MVPs, kostenrelevante frühe Phasen und Produkte ohne komplexe domänenspezifische Logik. Bei wachsender Komplexität, regulatorischen Anforderungen oder spezieller Backend-Logik wird ein eigenes Backend wirtschaftlicher.
Verwandt im Service-Portfolio

Verifiziert 2026-04-30

Cross-Platform App-Entwicklung

#

Entwicklungsansatz, bei dem eine gemeinsame Codebasis sowohl iOS- als auch Android-Apps (und teilweise Web/Desktop) erzeugt — typisch über Frameworks wie Flutter oder React Native.

Cross-Platform-Frameworks dominieren heute den Mobile-Markt: Laut Statista nutzten 2024 ca. 46 % der Cross-Platform-Entwicklerinnen und -Entwickler weltweit Flutter, gefolgt von React Native (35 %), Xamarin (15 %) und Ionic (4 %). Der Hauptvorteil ist die Wiederverwendung von 70–95 % des Codes für iOS und Android, was Entwicklungskosten und Time-to-Market typischerweise um 30–40 % gegenüber zwei nativen Entwicklungen reduziert. Cross-Platform ist nicht gleichbedeutend mit "Hybrid" oder "Web-View" — moderne Frameworks wie Flutter kompilieren zu nativem Code und liefern native Performance.
Verwandt im Service-Portfolio
Quellen

Verifiziert 2026-04-30

Edge Computing

#

Verlagerung von Datenverarbeitung an den Rand des Netzwerks — also möglichst nah am Datenursprung (Gerät, Maschine, Sensor) — statt zentral in der Cloud.

Edge Computing reduziert Latenz, Bandbreitenbedarf und Cloud-Kosten und ermöglicht Anwendungen mit Echtzeit-Anforderungen oder eingeschränkter Konnektivität. Beispiele: Predictive-Maintenance-Modelle, die direkt auf einem Industrie-Gateway laufen; CDN-Edge-Funktionen für personalisierte Web-Inhalte (Vercel Edge, Cloudflare Workers); On-Device-Inferenz für ML-Modelle (Apple CoreML, Android NN-API). Im Industrie-4.0-Kontext fungiert das Edge-Gateway oft als Puffer zwischen Maschinen-Bussen (Modbus, OPC UA, MQTT) und der Cloud — und übernimmt Datennormalisierung, Vor-Aggregation und Sicherheits-Authentifizierung. Edge ist kein Cloud-Ersatz, sondern komplementär: Edge übernimmt zeitkritische, lokale Aufgaben; die Cloud Aggregation, Modelltraining und Langzeit-Speicher.

Verifiziert 2026-04-30

Headless CMS

#

Ein Content-Management-System ohne fest gekoppeltes Frontend. Inhalte werden über eine API ausgeliefert und können von beliebigen Clients (Mobile, Web, Voice, IoT) konsumiert werden.

Im Gegensatz zu monolithischen CMS wie WordPress, das HTML direkt rendert, liefert ein Headless CMS Inhalte ausschließlich als strukturierte Daten (typischerweise JSON über REST oder GraphQL). Beispiele sind Strapi (Open Source), Contentful, Sanity, Storyblok, Directus. Vorteile: ein Redaktionssystem versorgt mehrere Frontends (Marketing-Website, Mobile App, Partner-Portal); klare Trennung zwischen Inhalt und Präsentation; bessere Performance durch Static Site Generation am Frontend. Nachteile: Vorschau und WYSIWYG-Erlebnisse für Redakteure brauchen separate Implementierung. Kombination mit Astro, Next.js oder Nuxt ist verbreitet.

Verifiziert 2026-04-30

Microservices

#

Ein Architekturmuster, bei dem ein Backend in mehrere unabhängig deploybare Dienste zerlegt wird, die über klar definierte Schnittstellen (HTTP, Messaging) kommunizieren.

Microservices stehen im Kontrast zum Monolithen, bei dem das gesamte Backend in einem Deployment-Artefakt liegt. Vorteile: separates Deployment, separate Skalierung, technologische Vielfalt pro Service, organisatorische Skalierung über mehrere Teams. Nachteile: deutlich höhere Komplexität in Betrieb (Distributed Tracing, Service Discovery, Konsistenzgarantien), Schnittstellen-Versionierung und Datenkonsistenz. Microservices sind kein Default — für die meisten B2B-App-Backends mit ein bis zehn Engineers ist ein gut strukturierter "Modulith" (modulare Monolith) die bessere Wahl, der bei Bedarf später dekomponiert werden kann.

Verifiziert 2026-04-30

Native vs. Hybrid Apps

#

Native Apps werden in der plattformeigenen Sprache (Swift/Kotlin) entwickelt und kompiliert. Hybrid-Apps verpacken eine Web-Anwendung in einen plattformeigenen Container (Cordova, Capacitor).

"Hybrid" und "Cross-Platform" werden oft fälschlich gleichgesetzt. Hybrid bedeutet streng: HTML/CSS/JavaScript in einer WebView, ergänzt durch Brücken zu nativen APIs (z. B. Apache Cordova, Capacitor). Cross-Platform-Frameworks wie Flutter oder React Native sind technisch keine Hybrid-Lösungen — sie rendern direkt mit nativen UI-Primitiven oder einer eigenen Rendering-Engine. Die Unterscheidung ist relevant für Performance, App-Store-Akzeptanz und Wartung. Native bleibt die Referenz für rechenintensive Anwendungen (AR, Spiele, fortgeschrittene Audio/Video-Pipelines); Cross-Platform dominiert den B2B- und Mittelstandsbereich; Hybrid wird zunehmend von PWAs verdrängt.

Verifiziert 2026-04-30

OAuth 2.0 & OpenID Connect · OIDC

#

OAuth 2.0 (RFC 6749) ist das Standardprotokoll für delegierte Autorisierung. OpenID Connect ist eine Identitäts-Schicht darüber, die Authentifizierung standardisiert.

OAuth 2.0 ermöglicht es einer Anwendung, im Namen eines Nutzers auf eine Ressource zuzugreifen, ohne dessen Passwort zu kennen — z. B. "Mit Google anmelden". OpenID Connect (OIDC) erweitert OAuth 2.0 um ein standardisiertes ID-Token (JWT), das Identitätsinformationen enthält. Für moderne Apps gilt der Authorization Code Flow with PKCE (RFC 7636) als sicherer Standard; der Implicit Flow ist obsolet. OAuth 2.1 (in Erarbeitung) konsolidiert Best Practices. Bei B2B-Anwendungen wird OIDC oft mit Identity-Providern wie Authentik, Keycloak, Auth0 oder Microsoft Entra ID kombiniert; mehrere Provider parallel sind über einen Multi-Auth-Guard im Backend möglich.
Quellen

Verifiziert 2026-04-30

Progressive Web App · PWA

#

Eine Web-Anwendung, die durch standardisierte Browser-APIs (Service Worker, Web App Manifest, Web Push) das Verhalten einer nativen App nachbildet — installierbar, offline-fähig, mit Push-Benachrichtigungen.

PWAs werden über den Browser ausgeliefert und benötigen keinen App-Store. Eine korrekt implementierte PWA kann zum Home-Screen hinzugefügt werden, im Vollbild laufen, Hintergrund-Synchronisation durchführen und Push-Nachrichten empfangen (auf iOS seit Safari 16.4, also iOS 16.4 / 2023). Vorteile: keine App-Store-Reviewzeiten, kein Plattform-Tax, keine Trennung der Codebasis. Einschränkungen: kein Zugriff auf bestimmte native APIs (NFC mit Limitationen, Bluetooth Low Energy nur in Chrome/Edge, keine breite Background-Verarbeitung auf iOS), und im B2B-Vertrieb fehlt das vertraute Symbol im App-Store. Sinnvoll für Tools, Dashboards und Inhaltsplattformen ohne harte Hardware-Anforderungen.
Quellen

Verifiziert 2026-04-30

SPA vs. SSR

#

SPA (Single Page Application) lädt die App einmal als JavaScript und rendert clientseitig. SSR (Server-Side Rendering) liefert vollständig gerenderte HTML-Seiten — wichtig für Performance und SEO.

Reine SPAs (klassisch React mit Create-React-App, alte Angular-Setups) sind heute selten erste Wahl: Suchmaschinen-Crawler haben Schwierigkeiten mit JS-rendered Inhalten, Erst-Lade-Performance leidet, und Core-Web-Vitals-Werte sinken. SSR rendert Seiten vorab am Server — entweder zur Build-Zeit (Static Site Generation, SSG) oder pro Request (klassisches SSR) — und liefert sofort HTML. Moderne Frameworks wie Next.js, Nuxt, Astro, Remix oder SvelteKit kombinieren Hybrid-Strategien: statisch wo möglich, server-gerendert wo dynamisch nötig, mit Hydration zum Client. Astro praktiziert "Islands Architecture": die Seite wird statisch ausgeliefert, JavaScript-Inseln werden gezielt hydratisiert. Das ist Standard für SEO-relevante öffentliche Inhalte.

Verifiziert 2026-04-30

WebSocket

#

Ein Protokoll (RFC 6455) für persistente, bidirektionale Verbindungen zwischen Client und Server über eine einzige TCP-Verbindung — geeignet für Echtzeit-Updates und niedrige Latenz.

WebSockets ermöglichen Anwendungen wie Chats, Live-Dashboards, Telemetrie-Streams oder kollaborative Editoren, bei denen der Server jederzeit Daten an den Client schicken können soll. Im Gegensatz zu klassischem HTTP-Polling gibt es keine wiederholten Requests; die Verbindung bleibt offen. Alternativen sind Server-Sent Events (SSE) — einfacher, aber unidirektional — sowie Long-Polling als Legacy-Fallback. Im B2B-IoT-Kontext werden WebSockets häufig mit MQTT (über WebSocket Transport) kombiniert. Für Edge-Verbindungen mit geringer Bandbreite ist MQTT direkt geeigneter; im Browser bleibt WebSocket der Standard.
Quellen

Verifiziert 2026-04-30

Industrie & B2B

Bluetooth Low Energy · BLE

#

Energiesparende Variante des Bluetooth-Standards für Sensorik, Wearables und IoT-Geräte. Aktuelle Spezifikation: Bluetooth Core 6.1 (April 2025) mit Channel Sounding für Distanzmessung.

Bluetooth Low Energy (BLE) wurde mit Bluetooth 4.0 (2010) eingeführt und ist seither die dominante drahtlose Schnittstelle für batteriebetriebene Geräte mit niedrigem Datendurchsatz — etwa Pulsmesser, Asset-Tracker, intelligente Schlösser oder Industriesensoren. Bluetooth Core 6.0 (September 2024) brachte Channel Sounding ein — eine sichere, präzise Distanzmessung über phasenbasierte Messverfahren und Round-Trip-Time, geeignet für Find-My-Anwendungen und digitale Schlüssel. Bluetooth Core 6.1 (April 2025) ergänzt dies um Randomized Resolvable Private Addresses zur verbesserten Privacy. Im Mobile-Bereich integrieren Flutter (über `flutter_blue_plus`) und React Native (über `react-native-ble-plx`) BLE-Funktionalität direkt; Web-Bluetooth ist nur in Chromium-Browsern verfügbar.
Verwandt im Service-Portfolio
Quellen

Verifiziert 2026-04-30

Industrie 4.0

#

Konzept der vierten industriellen Revolution: intelligente Vernetzung von Maschinen, Produkten und Prozessen über Internet-Technologien. Der Begriff wurde 2011 auf der Hannover Messe geprägt.

Der Begriff "Industrie 4.0" wurde 2011 von Henning Kagermann (acatech), Wolfgang Wahlster (DFKI) und Wolf-Dieter Lukas (BMBF) geprägt und ist Teil der "Hightech-Strategie 2020" der deutschen Bundesregierung. Die Plattform Industrie 4.0 (geleitet vom Bundesministerium für Wirtschaft und Klimaschutz und vom Bundesministerium für Bildung und Forschung) bündelt seitdem die nationale Umsetzung. Konkret bedeutet Industrie 4.0: cyber-physische Systeme, Internet der Dinge, Digital Twins, vorausschauende Wartung, autonome Logistik, individualisierte Massenproduktion ("Losgröße 1"). In der Praxis liegt der Fokus 2026 auf industrieller KI, Edge-Computing, Datensouveränität und Lieferketten-Transparenz.
Quellen

Verifiziert 2026-04-30

Internet of Things · IoT

#

Vernetzung physischer Objekte mit dem Internet, sodass diese Daten erfassen, austauschen und auf Anweisungen reagieren können — von Konsumgütern bis zu Industriesensoren.

IoT-Anwendungen bestehen typischerweise aus vier Schichten: Geräten (Sensoren, Aktuatoren), einer Konnektivitätsschicht (BLE, LoRa, NB-IoT, MQTT), einer Datenebene (Telemetrie-Ingestion, Time-Series-Datenbank) und einer Anwendungsschicht (Dashboard, Alerts, Automatisierung). Im B2B-Kontext sind Industrie-IoT-Plattformen (IIoT) besonders relevant — sie verbinden Maschinen mit Cloud-Diensten, ermöglichen Predictive Maintenance, Fernsteuerung und neue Geschäftsmodelle wie Pay-per-Use. Datenschutz und Datensouveränität sind zentrale Architekturentscheidungen, vor allem nach dem Inkrafttreten des EU Data Act (12. September 2025).

Verifiziert 2026-04-30

Manufacturing Execution System · MES

#

Ein System zur Steuerung und Überwachung von Produktionsabläufen auf Werks-Ebene. Sitzt im Modell IEC 62264 / ISA-95 auf Ebene 3, zwischen ERP (Ebene 4) und SCADA / Maschinensteuerung (Ebene 1–2).

Ein MES verwaltet Aufträge, Materialfluss, Qualitätsdaten, Maschinen-Auslastung und Personalplanung in Echtzeit. Es füllt die Lücke zwischen der hochaggregierten Geschäftslogik des ERP (SAP, Microsoft Dynamics) und der hardwarenahen Steuerung der einzelnen Maschinen. Die Norm IEC 62264 (auch als ANSI/ISA-95 bekannt) definiert Schnittstellen, Datenmodelle und Aktivitätsmodelle für die Integration. Mobile MES-Apps erlauben es Werkern, Aufträge auf dem Tablet zu quittieren, Qualitätsprüfungen zu dokumentieren oder Störungen zu melden — und sind ein klassischer B2B-App-Anwendungsfall für Cross-Platform-Frameworks.
Quellen

Verifiziert 2026-04-30

Predictive Maintenance

#

Wartungsstrategie, die anhand von Telemetriedaten und Modellen den optimalen Wartungszeitpunkt vorhersagt — vor dem Ausfall, aber nach dem Punkt, an dem die Wartung wirtschaftlich nötig ist.

Predictive Maintenance ersetzt zwei klassische Strategien: Reaktive Wartung (Ausfall → Reparatur, hohe Folgekosten) und Präventive Wartung (feste Intervalle, oft zu früh oder zu spät). Voraussetzung ist eine zuverlässige Telemetrie-Pipeline mit historischen Daten zur Trainings-Datenbasis. Modelle reichen von einfachen Schwellwert-Regeln über Time-Series-Forecasting (ARIMA, Prophet) bis zu Deep-Learning-Modellen (LSTM, Transformer) für komplexe Mustererkennung. Im DACH-Mittelstand sind Hybrid-Ansätze verbreitet: einfache Regeln am Edge ergänzt durch Modell-Updates aus der Cloud. Die wirtschaftliche Wirkung ist gut belegt — Studien zeigen typischerweise 25–35 % geringere Wartungskosten und 70–75 % reduzierte ungeplante Ausfälle.

Verifiziert 2026-04-30

Telemetrie

#

Automatisierte Messung und Übertragung von Daten über große Distanzen — typischerweise von Sensoren oder Geräten an ein zentrales Auswertesystem.

Telemetrie-Datenströme sind das Rückgrat moderner IoT- und Mobilanwendungen: Geräte erzeugen kontinuierlich Messwerte (Spannung, Temperatur, Position, Status), die an eine Backend-Plattform übermittelt werden. Architekturentscheidungen drehen sich um Frequenz (Echtzeit vs. Batch), Protokoll (MQTT, HTTP, CoAP), Speicherung (Time-Series-Datenbanken wie InfluxDB, TimescaleDB), Aggregation und Alerting. In regulierten Branchen (Medizintechnik, Energie) müssen Telemetriedaten zusätzlich auditierbar gespeichert werden — typischerweise als Append-only-Eventlog. Ein gut geplanter Telemetrie-Stack ist Voraussetzung für Predictive Maintenance, Anomaly Detection und KI-gestützte Auswertung.

Verifiziert 2026-04-30

Projekt & Methodik

Agile / Scrum

#

Agile ist ein Werte-Rahmen für Produktentwicklung (Agile Manifesto, 2001). Scrum ist ein konkretes Framework innerhalb der agilen Familie mit definierten Rollen, Events und Artefakten.

Das Agile Manifest (2001) priorisiert Individuen und Interaktionen, funktionierende Software, Kundenkollaboration und Reaktion auf Veränderung. Scrum (formalisiert von Ken Schwaber und Jeff Sutherland) konkretisiert dies durch zeitlich begrenzte Sprints (typischerweise 1–4 Wochen), Rollen (Product Owner, Scrum Master, Entwicklungsteam), Events (Daily, Planning, Review, Retrospective) und Artefakte (Product Backlog, Sprint Backlog, Inkrement). Kritik an Scrum bezieht sich häufig auf "Cargo-Cult-Adoption" — die Form ohne den Inhalt. Erfolgsentscheidend ist nicht die strikte Befolgung, sondern die kontinuierliche Anpassung an die jeweilige Situation. Alternativen: Kanban (Pull-basiert, ohne feste Sprints), Shape Up (Basecamp), kombinierte Hybride.
Quellen

Verifiziert 2026-04-30

Build vs. Buy

#

Die strategische Entscheidung, eine Funktion selbst zu entwickeln (Build) oder ein bestehendes Produkt einzukaufen (Buy) — abhängig von Differenzierung, Time-to-Market, Total Cost of Ownership und Lock-in-Risiko.

Die Faustregel: bauen, wo das Geschäft differenziert; kaufen, wo es eine Commodity ist. Authentifizierung, Zahlungsabwicklung, E-Mail-Versand, Analytics — überwiegend Buy. Das Kerngeschäftsmodell, die proprietäre Geschäftslogik, kundenspezifische Workflows, regulatorische Compliance — überwiegend Build. Die Entscheidung sollte über mehrere Achsen geprüft werden: Anschaffungs- und Lizenzkosten über fünf Jahre, Integrationsaufwand, Anbieter-Stabilität, Datenschutz und Datensouveränität, Wechselkosten bei Ausstieg, Roadmap-Übereinstimmung mit eigenen Bedürfnissen. Ein häufiger Fehler ist es, "Buy" auszuwählen, ohne die Integrationskosten und das Lock-in-Risiko mit demselben Detailgrad zu kalkulieren wie die Build-Kosten.

Verifiziert 2026-04-30

CI/CD · CI/CD

#

Continuous Integration (CI) ist die automatische Integration und Prüfung von Codeänderungen. Continuous Delivery / Continuous Deployment (CD) automatisiert das Veröffentlichen.

CI führt jede Codeänderung sofort durch eine standardisierte Pipeline: statische Analyse, Unit-Tests, Integrationstests, Build, optionale UI-Tests. Continuous Delivery hält das Hauptzweig-Release-Artefakt jederzeit deploybar — ein Mensch entscheidet aber wann. Continuous Deployment automatisiert auch diesen Schritt: jede Änderung im Hauptzweig geht automatisch in Produktion. Im Mobile-Bereich gibt es zusätzliche Schritte: Signaturen, App-Store-Submissions, TestFlight/Play-Store-Beta-Kanäle, automatisierte Versionsincrements. Verbreitete Werkzeuge: GitHub Actions, GitLab CI, Bitrise, Codemagic, Fastlane. Eine reife CI/CD-Pipeline ist nicht optional — sie ist Voraussetzung für sichere, häufige Releases und für Compliance-Nachweise (z. B. IEC 62304 verlangt nachvollziehbare Build- und Release-Prozesse).

Verifiziert 2026-04-30

Minimum Viable Product · MVP

#

Die kleinste sinnvolle Produktversion, die echten Nutzern erlaubt, das Wertversprechen zu erleben — und dem Team erlaubt, Annahmen mit echten Daten zu validieren.

Der Begriff geht auf Eric Ries' Buch "The Lean Startup" (2011) zurück. Ein MVP ist nicht "ein Prototyp" und nicht "die erste schlechte Version" — es ist eine bewusst reduzierte Lösung, deren Zweck Erkenntnisgewinn ist. Im B2B-Kontext bedeutet MVP häufig: ein einzelner kritischer Workflow für eine erste Pilot-Kundengruppe, mit echten Daten und echtem Kundensupport. Was zum MVP gehört, ist eine strategische Entscheidung — nicht eine Frage der Aufwandsreduktion. Häufige Fehler: das MVP zu groß denken (führt zu monatelangem Build ohne Validierung) oder zu klein denken (führt zu MVP, das nichts beweist).

Verifiziert 2026-04-30

Time-to-Market · TTM

#

Die Zeit von der Produktidee bis zur ersten Markteinführung. Eine Kernmetrik für Wettbewerbsfähigkeit — besonders in Märkten mit kurzen Innovationszyklen.

TTM wird oft mit "schnell" gleichgesetzt, aber die relevante Frage ist: schnell mit welcher Mindest-Qualität für welche Zielgruppe? Eine Pilot-Version für drei Lead-Kunden hat eine andere TTM als eine vollständige Multi-Tenant-Plattform. Hebel zur TTM-Reduktion: Cross-Platform statt zwei native Codebasen (typisch -30 bis -40 %), BaaS statt eigenes Backend in der frühen Phase, vorgefertigte Komponenten (UI-Bibliotheken, Auth-Provider) statt Eigenentwicklung, klar abgegrenzter MVP-Scope, kontinuierliche Releases statt Big-Bang-Launch. Im B2B-Bereich ist TTM oft direkt verknüpft mit Cashflow: jeder Monat früher bedeutet einen Monat früher Umsatz und Validierung.

Verifiziert 2026-04-30

Frage zu einem Begriff oder konkretes Projekt?

Wir entwickeln Mobile- und Backend-Software für regulierte und industrielle B2B-Anwendungen. Sprechen wir über Ihre Anforderungen.

E-Mail schreiben