Das Produkt modellieren
Begriffe, Rollen, Daten und Zustände müssen dieselbe Bedeutung haben. Ein verständliches Modell verbindet Oberfläche, Dienste und vorhandene Systeme.
DEEPBURG / MULTI-PLATFORM-APP-ENTWICKLUNGEin Produkt.
Ein Produkt.
Vier Kontexte.
Wir entwickeln Apps, die über Geräte hinweg zusammenarbeiten. Fachliche Regeln und Daten bilden die gemeinsame Grundlage. Ansichten, Eingaben und Gerätefunktionen richten sich danach, wie Menschen das Produkt tatsächlich nutzen.
Architektur erkundenPRODUKT
KERNWEBiOSANDROIDDESKTOP
EIN SYSTEM / PASSENDE BEDIENUNGKERNWEBiOSANDROIDDESKTOP
DIE ARCHITEKTURFRAGE
Was teilen wir – und was gestalten wir eigens?
Gemeinsame Bausteine helfen, wenn sie Änderungen über Plattformen hinweg zusammenhalten. Eigene Lösungen sind sinnvoll, wo Bedienung, Gerätefunktionen oder Betrieb sie erfordern. Die Grenze bestimmen wir aus Anforderungen, Team und Pflegeaufwand.
Für die Plattform entwerfen
Eine mobile Dokumentation braucht andere Eingaben als die Auswertung am Arbeitsplatz. Navigation, Offline-Verhalten und Systemintegration folgen diesem Kontext.
Die Entscheidung festhalten
Wir vergleichen technische Ansätze nach Anforderungen und Abhängigkeiten. Dokumentiert werden gemeinsame Bausteine, eigene Implementierungen und die Gründe für diese Wahl.
VIER NUTZUNGSSITUATIONEN
Bedienung beginnt mit dem Kontext.
Web
Übersichten, Zusammenarbeit und direkt erreichbare Arbeitsflächen. Tastaturbedienung, unterschiedliche Bildschirmgrößen und unterstützte Browser gehören in den Entwurf.
iOS
Fokussierte Aufgaben unterwegs. Navigation, Touch-Eingaben und die Nutzung von Kamera oder anderen Gerätefunktionen werden zu einem verständlichen Ablauf verbunden.
Android
Mobile Nutzung auf den vereinbarten Geräten und Systemversionen. Layout, Navigation und Verhalten bei wechselnder Verbindung werden für diese Auswahl geplant.
Desktop
Vergleichen, bearbeiten und länger am Produkt arbeiten. Tastatur, Fenster, Dateiaustausch und eine angemessene Informationsdichte unterstützen diese Aufgaben.
SCHEMATISCHES ENTSCHEIDUNGSPROTOKOLL
Gemeinsame Regeln. Eigene Umsetzung.
Eine App soll Anmeldung, Offline-Arbeit und mehrere Releasewege verbinden. Das folgende Beispiel zeigt mögliche Grenzen zwischen gemeinsamer Planung und plattformspezifischer Umsetzung.
| BEREICH | GEMEINSAM | PLATTFORMSPEZIFISCH |
|---|---|---|
| Identität | Rollen, Zugriffsregeln und Prüfung durch angebundene Dienste | Anmeldeablauf, Gerätespeicher und lokale Freigaben |
| Offline | Datenbedeutung, ausstehende Änderungen und Konfliktregeln | Lokaler Speicher und zulässige Hintergrundverarbeitung |
| Release | Qualitätsziele, unterstützte Versionen und Abnahmekriterien | Web-Veröffentlichung, Store-Prüfung und Desktop-Verteilung |
Prinzipstudie mit hypothetischen Anforderungen. Die tatsächlichen Systemgrenzen werden im Projekt bestimmt.
TECHNISCHE ENTSCHEIDUNGEN IM ALLTAG
Für die Realität entwickelt.
Ein Produkt wird auch dann gebraucht, wenn das Netz fehlt, mehrere Personen dieselben Daten bearbeiten oder ein angeschlossenes System sich ändert. Diese Situationen gehören in den Entwurf. Ihre Umsetzung wird im Projekt festgelegt.
Wenn die Verbindung fehlt
Lesen, lokal speichern und übertragen sind unterschiedliche Aufgaben. Wir klären, welche davon offline möglich sein müssen, wie ausstehende Änderungen sichtbar bleiben und wer Konflikte nach der Synchronisation auflöst.
Wenn mehrere Menschen zusammenarbeiten
Ein Rollenmodell legt fest, wer welche Daten lesen oder verändern darf. Die Oberfläche zeigt erlaubte Aktionen; die angebundenen Dienste prüfen die Berechtigung für jeden Zugriff. Gemeinsame Bearbeitung braucht außerdem Regeln für veraltete Datenstände.
Wenn vorhandene Systeme angebunden werden
Datenverträge beschreiben Bedeutung, Format und zulässige Änderungen. Zuverlässige Anbindungen brauchen auch definierte Fehlerreaktionen, Versionswechsel und Zuständigkeiten. Migration und der Ausfall eines Dienstes gehören in die Planung.
Wenn ein Release ansteht
Web, App-Stores und Desktop-Verteilung haben eigene Wege. Wir klären unterstützte Versionen, Signatur- und Store-Konten, Abnahmekriterien und den Umgang mit fehlerhaften Releases. Zeitpunkt und Ergebnis externer Store-Prüfungen bleiben außerhalb unserer Kontrolle.
VON DER IDEE ZUM RELEASE
Die kritischen Entscheidungen kommen früh.
Wir legen zentrale Aufgaben, Zielgruppen und Plattformen fest. Ergebnis ist ein priorisierter erster Umfang mit offenen Fragen.
Datenflüsse, Schnittstellen und Sicherheitsgrenzen werden geklärt. Kritische technische Annahmen erhalten eine gezielte Prüfung.
Überprüfbare Zwischenstände zeigen Fortschritt und offene Punkte. Vereinbarte Nutzungssituationen und Fehlerfälle dienen als Grundlage für die Abnahme.
Releaseweg, Quellcode, Konten und Betriebsverantwortung erhalten klare Zuständigkeiten. Weiterentwicklung und Pflege werden im vereinbarten Umfang vorbereitet.
Woran ein gutes Angebot erkennbar ist.
Es nennt Zielplattformen und unterstützte Versionen, Funktionsumfang, Abnahmekriterien, Veröffentlichungsweg, Quellcode- und Kontozuständigkeiten sowie Wartung und Updates. Der konkrete Leistungsumfang wird individuell vereinbart.
Die Umsetzung wählen
Multi-Platform oder nativ?
Gemeinsamer Code ist eine Architekturentscheidung. Die Wahl richtet sich danach, was das Produkt leisten muss, wie es das Gerät nutzt und wer es später weiterentwickelt.
Was wir vergleichen
- Benötigte Gerätefunktionen und unterstützte Versionen
- Offline-Verhalten, Reaktionszeit und Datenumfang
- Zugänglichkeit und Konventionen der Plattform
- Releasewege, Erfahrung des Teams und langfristige Pflege
Das Ergebnis kann eine gemischte Architektur sein: gemeinsame Produktregeln und Dienste, ergänzt um native Bausteine, wo die Aufgabe davon profitiert. Die Grenzen halten wir vor der Umsetzung fest.
DEEPBURG DIGITAL SCIENCE / KONTAKT
Welche Plattform braucht Ihr Produkt zuerst?
Beschreiben Sie die Aufgabe, die Nutzer und vorhandene Systeme. Gemeinsam können wir den ersten sinnvollen Umfang eingrenzen.