Unsere multidisziplinäre Expertise und ein ausgereiftes Vorgehen ermöglichen unseren Kunden optimale Lösungen für Ihre spezifischen Herausforderungen. Dafür nutzen wir etablierte Werkzeuge auf vielfältige Art, um sie auf diesem Weg zu begleiten.
Unser Vorgehen basiert auf Grundsätzen, die den Methodiken des Design Thinkings und des Google Design Sprints entlehnt sind und schafft den Schulterschluss mit etablierten agilen Frameworks wie Scrum oder Kanban. Wir folgen keiner strengen Methodik, sondern wählen zur Aufgabenstellung passende Werkzeuge für einen verantwortungsvollen Umgang mit der uns zur Verfügung gestellten Zeit.
Designgetriebene und nutzerzentrierte Lösungen
Digitale Produkte sind in unserem Verständnis digitale Lösungen für kommunikative, geschäftliche, gesellschaftliche oder soziale Probleme. Die Bandbreite solcher Lösungen reicht von webbasierten Anwendungen, die in einem Browser ausgeführt werden, über mobile Anwendungen bis hin zu Applikationen, die auf eigens zu diesem Zweck konzipierter Hardware ausgeführt werden.
Wir können unsere Qualitäten besonders in designgetriebene Projekte einbringen, die auf Neu- oder Weiterentwicklung einer Lösung abzielen und sich in einem frühen Stadium befinden. Wir begleiten unsere Kunden bei der Strategie-Entwicklung, Zielfindung, Konzeption und Realisierung als Advokat des Anwenders und bringen so eine Perspektive ein, die immer relevanter für den Erfolg digitaler Lösungen wird.
Um den unterschiedlichen Anforderungen in den einzelnen Projektphasen zu begegnen, greifen wir auf verschiedene Methoden für zielführende und lösungsorientierte Fortschritte zurück.
Typische Projektziele und Vorgehensweisen
In der Regel arbeiten wir in Projekten, die einer spezifischen Zielsetzung folgen. Je nach Zweck der angestrebten Lösung und den zur Verfügung stehenden Ressourcen variieren die Ziele in Reifegrad, Umfang und Nachhaltigkeit des Ergebnisses.
Typische Ergebnisziele, die uns im Alltag regelmäßig begegnen und in deren Kontext wir uns zu Hause fühlen, sind Prototypen-, PoC-, MVP- und Release-Projekte.
Prototypen dienen dazu, einen spezifischen und konkreten Ausschnitt aus einem Projekt zu verproben. Dabei kann schnell und in kurzen Iterationen eine kleine Einheit – beispielsweise eine komplexe Nutzerinteraktion, eine kritische technische Implementierung oder eine zentrale Architekturkomponente – evaluiert werden. Wenn als Ergebnis eine umfangreichere Sicht notwendig ist, um zum Beispiel einen Prozess aus Nutzersicht vollständig darzustellen, können fachlich nicht wesentliche Bestandteile des Prototyps simuliert werden.
POC – Proof of concept
PoC-Projekte verfolgen das Ziel, einen kritischen Teil eines Vorhabens zu verproben. Dabei stehen ganze Funktionalitäten oder Features im Fokus. Das bedeutet, es gelten für diese Teile einer Lösung dieselben fachlichen und inhaltlichen Anforderungen, die auch bei einem produktiven Release angelegt werden. Auf technischer Ebene können hingegen einfachere Werkzeuge gewählt werden, um in kurzer Zeit ein testbares Ergebnis zu erlangen. In der Regel sind Proof-of-Concept-Ergebnisse nicht für den produktiven Einsatz geeignet.
MVP – Minimum viable product
Ein MVP-Projekt hat als Ergebnis ein auf den wesentlichen fachlichen Kern reduziertes Produkt. Der Umfang wird durch eine strikte Priorisierung der fachlichen Minimalanforderung zur Erfüllung des originären Zwecks definiert. Das Resultat muss allen Anforderungen an eine Vollentwicklung genügen – der definierte Umfang muss also unter Berücksichtigung aller Rahmenbedingungen (fachlich, technisch, rechtlich, betrieblich) realisiert werden.
Auf Basis der Erfahrungen aus dem Betrieb eines MVP unter Realbedingungen – also Nutzer-Feedback, fachliche Bewertungen etc. – lassen sich wertvolle Insights gewinnen, um die im Projekt getroffenen Annahmen zu evaluieren und das weitere Vorgehen auf dem Weg zu einem Release-Kandidaten zu bestimmen.
Release candidate
Mit jedem Release können verschiedene Aspekte eines Produktes unter Produktivbedingungen bereitgestellt und in Betrieb genommen werden. Dabei stehen Fehlerbehebungen, Anpassungen oder Erweiterungen des Funktionsumfangs im Fokus. Üblicherweise werden die ersten Releases auf Basis eines MVP erarbeitet. Mit jedem Release nehmen Umfang und Reife eines Produktes zu.
Sind für ein Release geplante Anpassungen umfangreich und erfordern eine erneute Evaluierung, wird häufig auf eine erneute PoC- oder MVP-Phase zurückgegriffen, um nur diesen Aspekt unter Laborbedingungen zu beleuchten.
Typisches Vorgehen und Ziele, Entwicklungsphasen, Domänen und Disziplinen
Vorgehen und Ziele
Unser Vorgehen ist davon geprägt, in einem durchlässigen Prozess Schritt für Schritt transparent und nachvollziehbar wertschöpfend und zielführend gemeinsam mit unseren Auftraggebern agieren zu können. Dabei folgen wir einem erprobten Vorgehen, um notwendige Informationen zu gewinnen und Ressourcen zu erschaffen, die für den jeweils nächsten Schritt erforderlich sind.
Das große Ganze verstehen
Zu Beginn jeder Mission müssen wir verstehen, welche Gesamtzusammenhänge es gibt, in welchem Kontext ein Projekt verortet ist und welche allgemeinen Anforderungen bestehen. Wir sind auf Kenntnisse der Geschäftsziele ebenso angewiesen wie auf ein grundsätzliches Verständnis der fachlichen Inhalte. Wir beschäftigen uns intensiv mit Nutzerbedürfnissen und -erwartungen. So finden wir gemeinsam mit unseren Auftraggebern ein Ziel, bemessen den Wert eines Produktes und erarbeiten objektive Kriterien zur Bewertung des Projektes.
Nutzungsszenarien
Wir helfen unseren Auftraggebern dabei, aus dem großen Ganzen einzelne Nutzungsszenarien abzuleiten und zu bewerten. Dabei findet ein permanenter Abgleich mit fachlichen und geschäftlichen Prozessen und Zielen statt, um zu gewährleisten, dass ein homogenes Produkt entstehen kann, das sowohl den Nutzerbedürfnissen als auch den geschäftlichen Rahmenbedingungen entspricht.
Projektinhalt und Werkzeuge
Auf diesem Weg entsteht ein klares Bild des Projektinhalts und -umfangs. Auch ein zielgerichtetes, projektspezifisches Vorgehen und die Kriterien, die im weiteren Verlauf Relevanz haben, lassen sich so schlüssig ableiten.
Wir können so ein gemeinsames Verständnis von geeigneten Mitteln und Wegen, Projektbeteiligten und deren Rollen gewinnen. Auch die Dimension des Projektes in Bezug auf die Laufzeit sowie die erforderlichen Personen und deren Expertise wird greifbar.
Projektarbeit
Durch die geleistete Vorarbeit sind wir dazu in der Lage, im weiteren Prozess domänenübergreifend, effizient und zielgerichtet vorzugehen. Die gewonnenen Informationen und Kenntnisse geben allen Beteiligten Sicherheit, vereinfachen das Treffen von Entscheidungen und erlauben dem Projektteam selbstbewusste und gemeinschaftliche Fortschritte.
Entwicklungsphasen
Jede Produktentwicklung oder -weiterentwicklung erfolgt in mehreren Entwicklungsphasen, deren Ergebnisse in der jeweils nächsten die Grundlage für das weitere Vorgehen bestimmen. Diese Phasen werden in jedem Release-Zyklus der Entwicklung – beispielsweise in jedem Sprint – im jeweils erforderlichen Umfang durchlaufen.
Um die Ziele jeder Phase zu erreichen, setzen wir verschiedene Methoden ein, um transparent und zügig zu den gewünschten Ergebnissen zu gelangen. Die im Folgenden dargestellten Methoden bilden ein typisches Vorgehen in einer üblichen Produktarchitektur ab. Das bedeutet nicht, dass wir einem starren Prozess mit fixem Ablauf folgen. Unsere Projekte zeichnen sich durch diverse Herausforderungen aus und so gilt es, den spezifischen Anforderungen und dem jeweiligen Gesamtbild mit den vielversprechendsten Werkzeugen zu begegnen.
Discover
Research
Concept
Ideate, Define, Visualize
Refine, Prototype
Build, Integrate, Deliver
Measure, Optimize
Discover
Ziel der Phase ist es, die geschäftlichen Ziele sowie die fachlichen und funktionalen Anforderungen an eine Lösung in Erfahrung zu bringen, zu strukturieren und festzuhalten. Ebenso relevant ist es, die Nutzerbedürfnisse und -erwartungen zu untersuchen und zu verstehen. Dazu ist ein enger Austausch zwischen den Fachabteilungen, Projektverantwortlichen, dem Design- und dem Entwicklungsteam notwendig. Alle Erkenntnisse und Informationen sind relevant für alle Projektbeteiligten, da auf dieser Basis in allen Disziplinen wesentliche Entscheidungen getroffen werden.
Research
In der Research-Phase werden Wettbewerbsbetrachtungen durchgeführt und erste Überlegungen angestellt, wie den kritischen Punkten der Herausforderung begegnet werden kann. Auch ein tieferes Verständnis für die Anwender oder Zielgruppen wird in dieser Phase geschaffen. So können bereits erste Annahmen über die Art und Weise sowie die Situationen getroffen werden, in denen ein Anwender mit der Lösung in Interaktion treten wird.
Concept
Das bis hierhin gewonnene Wissen wird in einem ganzheitlichen Konzept zusammengeführt, das die Grundzüge einer Lösung erstmalig erkennbar macht. Dabei können bereits die ersten groben Visualisierungen parallel zu weiteren Überlegungen zur Nutzerinteraktion entwickelt werden.
Da über ausreichendes Wissen verfügt wird, um erste Technologie-Entscheidungen zu treffen, wird parallel zu einem Designkonzept auch ein Realisierungskonzept entwickelt. So können erste Architekturentscheidungen getroffen und die wesentlichen Technologie-Stacks festgelegt werden.
Ideate, Define, Visualize
Um die Produktidee greifbar zu machen, wird das Ergebnis der Konzeptionsphase als Fundament zur Ideenfindung, Exploration und Visualisierung von Bedienoberflächen, der ersten Ableitung eines Bedienkonzeptes und inhaltlichen Architektur verwendet. Diese Ergebnisse werden hinsichtlich ihrer Zugänglichkeit und Nutzbarkeit fortwährend unter Einbindung von Anwendern bewertet und verfeinert.
In dieser Phase sollten die initialen Technologie-Entscheidungen gefallen, das erste technische Setup vollzogen und die als projektkritisch eingeschätzten Implementierungen verprobt worden sein.
Refine, Prototype
Um ein interaktives Nutzererlebnis zu simulieren, wird die Ausgestaltung der Bedienoberflächen so weit verfeinert, dass sie die nötige Reife haben, um in einen einfachen Prototyp überführt zu werden. So werden Annahmen und Entscheidungen in Zusammenarbeit mit der Anwenderschaft evaluiert und belastbare Design-Entscheidungen getroffen. Parallel dazu werden die neuen oder angepassten Design-Komponenten der Oberfläche spezifiziert und zur weiteren Realisierung aufbereitet.
In der Frontend-Umsetzung werden Architekturentscheidungen in die Tat umgesetzt und erste Ansichten und Komponenten in einer rohen Fassung realisiert. Auch mit der Implementierung der Frontend-Applikation wird auf Basis der fachlichen Anforderungen begonnen.
Im Backend werden ebenfalls die ersten Bestandteile auf Basis der konzipierten Fachlichkeit real implementiert. Auch die Schnittstellen zwischen Front- und Backend werden konzipiert und im Zuge eines technischen Durchstichs verprobt.
Build, Integrate, Deliver
In dieser meist umfangreichen Phase passiert quasi alles gleichzeitig. Alle Anforderungen für den aktuellen Zyklus liegen belastbar vor. Auf dieser Basis werden sowohl alle relevanten Design-Komponenten detailliert dokumentiert als auch in einer Design-Komponenten-Bibliothek zusammenfasst. Für neue Komponenten werden Spezifikationen erstellt.
In der Entwicklung werden die spezifischen Anforderungen implementiert, Design-Komponenten in Form einer Pattern Library abgebildet, externe Dienste integriert, Tests automatisiert und alle Produktbestandteile zur Inbetriebnahme vorbereitet.
Measure, Optimize
Measure, Optimize
Diese Phase liegt in der Regel nach dem Release des laufenden Zyklus und umfasst Reviews, Nutzertests und technische Analysen über das aktuelle Release. So werden Feedback und Metriken gewonnen, die im folgenden Zyklus Anpassungen an den aktuellen Ergebnissen ermöglichen. Um Aussagen auf einer fundierten Basis treffen zu können, ist es sinnvoll, bereits im Vorwege Hypothesen und Kennzahlen für verschiedene Testszenarien definiert zu haben.
Domänen und Disziplinen
User Experience Design
UX-Design beschäftigt sich in der Regel mit der Migration von Geschäftszielen, fachlichen Rahmenbedingungen und Nutzerbedürfnissen in eine Produktstrategie und -realisierung, um sicherzustellen, dass eine Lösung fachlich korrekt ist, die geschäftlichen sowie wirtschaftlichen Ziele erreichen kann und eine maximale Nutzerakzeptanz erfährt. Dazu sind umfassende Konzept- und Recherchearbeiten notwendig, um fundierte Annahmen treffen zu können, die in der weiteren Produktentwicklung als Basis für entsprechende Schlussfolgerungen dienen.
Wie Dinge aussehen – also welche Gestalt und Erscheinung sie haben – ist explizit nicht Inhalt eines UX-Design-Prozesses. Resultat ist vielmehr, wie ein Produkt funktionieren sollte, welche Struktur und Form ein Produkt annehmen muss, um spezifischen Anforderungen gerecht werden zu können.
UX-Research oder User-Research fokussiert sich darauf, Nutzerbedürfnisse zu ermitteln, zu strukturieren und daraus Anforderungen abzuleiten, die in einem Produktentwicklungszyklus Berücksichtigung finden müssen.
Daten- und Informationsarchitektur
Um die in einem Produkt oder Feature relevanten Informationen fachlich korrekt und im Sinne des Anwenders zielführend nutzen zu können, sind Kenntnisse über die Daten- und Informationsarchitektur sowie deren Bedeutung erforderlich. Nur dann kann eine Lösung diese anwendungsfallspezifisch präsentieren oder in Geschäftslogik migrieren.
Requirements Engineering (fachliche, kontextuelle und funktionale Anforderungen)
Requirements Engineering oder Anforderungsmanagement dient dazu, die geschäftlichen, fachlichen, rechtlichen und technischen Anforderungen für eine Produkt- oder Feature-Entwicklung zu erarbeiten und zu dokumentieren. Die so entstehenden Informationen über Rahmenbedingungen, aktuelle Ziele sowie relevante Einschränkungen sind wesentlich für den gesamten Prozess der aktuellen Entwicklungsphase.
Interaction Design
Interaction Design (IxD) betrachtet die generelle Beziehung zwischen einem Produkt und dessen Nutzer. Dabei wird recherchiert und definiert, wie und in welchen Situationen ein Anwender mit einer Lösung in Interaktion tritt. Das so gewonnene Wissen ist erforderlich, um zu bestimmen, welche Art von Interface – z.B. ein Graphical User Interface oder ein Conversional User Interface – dem Anwender den bestmöglichen Umgang mit dem Produkt bietet. Auch die physischen Anforderungen werden beleuchtet, um sicherzustellen, dass eine Lösung bestmöglich zugänglich ist. Soll ein Interface auch mit Schutzhandschuhen bedient werden können, muss dieses Wissen im weiteren Prozess berücksichtigt werden.
Usability Evaluation
Ab dem Zeitpunkt, zu dem die Form eines Produktes oder Features erkennbar wird, ist es erforderlich, regelmäßig zu prüfen, ob dieses durch die Anwender in einem realen Kontext eingesetzt werden kann. Dabei werden die Aspekte Bedienbarkeit und Nutzerfreundlichkeit beleuchtet und, wenn möglich, nach objektiven Kriterien bewertet.
Accessibility Evaluation
Existieren Anforderungen oder sogar verpflichtende Bedingungen für ein Produkt, für Anwender mit verschiedenen Einschränkungen geeignet oder optimiert zu sein, muss dieser Aspekt von Beginn an berücksichtigt werden. Dabei werden zur Bewertung existierende Standards wie die W3C WAI Web Content Accessibility Guidelines herangezogen, um einen objektiven Maßstab anlegen zu können. Auch direktes Nutzer-Feedback ist hier relevant, da sich nicht-visuelle Hürden in der Bedienung nur eingeschränkt ermitteln lassen.
User Interface Design
In einem UI-Design-Prozess wird definiert, visualisiert und verprobt, welche Gestalt ein Produkt annimmt und wie innerhalb einer Bedienoberfläche mit dem Produkt interagiert wird. Der Fokus liegt auf der Kreation der visuellen Präsentation eines Produktes für den Anwender. Dabei stehen funktionale Themen im Hintergrund, während die emotionale Nutzeransprache und eine eigenständige Ästhetik Kern des Prozesses sind.
Ein Produkt, das eine hohe Nutzerakzeptanz erreichen soll, muss erstklassig funktionieren, den Anwender in seinem Tun bestmöglich unterstützen und ihm eine Umgebung präsentieren, in der er agieren kann, ohne von der Lösung beeinträchtigt zu werden. Um diese Ziele zu erreichen, sind vollständige UX- und UI-Prozesse notwendig.
Visual Design ist die Disziplin, die den größten Einfluss auf das Erscheinen eines Produktes hat. Sie bestimmt, welche Anmutung eine Anwendung in Form, Farbe und Ansprache hat, und stellt eine emotionale Bindung zwischen Produkt und Anwender her. Ästhetik, eine subjektiv wahrgenommene Attraktivität und visuelle Eigenständigkeit sind die Schlüsselfaktoren für ein Produkt mit einer hohen Nutzeridentifikation.
Interface Design
Ebenso wie das Visual Design ist das Interface Design für eine hohe Nutzerakzeptanz verantwortlich. Hier steht allerdings nicht das Gesamterscheinen im Fokus, sondern die Ausgestaltung der einzelnen Bedienelemente und deren Komposition zu einer Bedienoberfläche. Den Vorgaben des UX-Prozesses folgend, werden die bereits erstellten und evaluierten Annahmen aus einem abstrakten Konzept in ein konkretes Bild überführt.
Interactive Design
In einem Interactive-Design-Prozess werden die konkreten Nutzerinteraktionen in Bezug auf eine Bedienoberfläche entworfen und getestet. Hier geht es im Gegensatz zu Interaction Design nicht um das generelle Verhältnis zwischen Produkt und Nutzer, sondern um die Interaktion und Kommunikation zwischen einer konkreten Bedienoberfläche und dem Anwender. So wird definiert, wie UI-Elemente Rückmeldung über Nutzeraktionen geben, Benachrichtigungen dargestellt oder komplexe Aktionsszenarien abgebildet werden.
Accessibility Design
Accessibility Design sorgt dafür, dass die Anwenderschaft die Funktionalitäten eines Produktes verwenden kann. Dabei spielen die Eigenschaften der Nutzer und die Situationen, in denen ein Produkt eingesetzt wird, genauso eine Rolle wie die Eigenschaften und die Ausfertigung des Produktes selbst. Auch die Geräte, mittels derer mit dem Produkt interagiert wird, sowie deren spezifische Eigenschaften beeinflussen das Design eines Produktes in Bezug auf die Zugänglichkeit.
Design Component Separation
Um eine Wiederverwendbarkeit der ausgearbeiteten Design- und Interaktionselemente zu gewährleisten, folgen wir einem Komponentenparadigma. Das bedeutet, dass ein bestimmtes UI-Element immer dieselbe interaktive und informelle Funktion abbildet. Auf diese Art lassen sich auf Basis der Semantik der Elemente Komponenten definieren, die ein konsistentes Verhalten und Aussehen implementieren. Aus diesen Elementen werden wiederum die einzelnen Bedienoberflächen aufgebaut. Die Elemente gegeneinander abzugrenzen, Verwandtschaften zu finden und zu entscheiden, welche Bestandteile eine Komponente ausprägen, ist die Aufgabe von Design Component Separation.
Component Library Creation
Verfügt man über eine Sammlung von Design-Komponenten, die nicht nur in einem Kontext und von einem Designer eingesetzt werden, wird eine zentrale Library angelegt, die alle Komponenten zusammenfasst, Änderungen versioniert und allgemein zur Verfügung steht und verteilt wird. So wird gewährleistet, dass das Team in einem Design-Prozess auf dieselben Ressourcen vertrauen kann. Updates der Library können direkt genutzt werden und fließen automatisch in die Design-Dokumente ein.
Design Guidelines
Um sicherzustellen, dass die Design-Ressourcen korrekt eingesetzt werden und nicht von verschiedenen Team-Mitgliedern unterschiedlich interpretiert werden, werden zum Umgang mit den Ressourcen und zum generellen Konzept Guidelines definiert. Diese dienen dazu, sowohl die grundsätzlichen Überlegungen nachvollziehbar zu machen als auch in der konkreten Anwendung Hilfestellung für die weitere Entwicklung zu bieten. Häufig werden parallel Design-Handoffs erstellt, die die Design-Komponenten aus der Perspektive eines Frontend-Entwicklers betrachten.
Frontend Engineering
Unter einem Frontend versteht man den für einen Anwender sichtbaren technischen Anteil eines digitalen Produktes. In der Regel handelt es sich um die programmatische Realisierung eines User Interfaces mithilfe verschiedener, meist endgerätespezifischer Technologien. So werden Anwendungen für den Betrieb im Browser oder auf einer nativen Plattform und für unterschiedliche Gerätetypen unter jeweils spezifischen Rahmenbedingungen umgesetzt.
Hier fließen die Ergebnisse eines UI-Design-Prozesses direkt ein. Dabei unterstützen sich diese Domänen, um von einem durchgängigen Wissens- und Ressourcentransfer zu profitieren. Wir nutzen spezielle Werkzeuge und Vorgehensmuster, um sicherzustellen, dass UI-Design und Frontend-Implementierung in einem gemeinsamen Fluss entstehen und reibungslos zu zügigen und belastbaren Ergebnissen führen, über die in kurzen Zyklen iteriert werden kann.
Die generelle Frontend-Architektur definiert auf hohem Niveau, welche Bestandteile innerhalb der Frontend-Implementierung existieren und welche Aufgaben diese wahrnehmen. Dabei können ebenso fachliche wie technische Abgrenzungskriterien definiert werden. Durch eine klare architektonische Trennung kann einfacher mit Abhängigkeiten umgegangen und mit mehreren Entwicklern in einem Projekt agiert werden.
Technology Selection and Setup
Nachdem die grundsätzliche Architektur definiert wurde, werden anhand der fachlichen und technischen Anforderungen sowie des Produktkonzepts die zur Realisierung geeigneten Technologien gewählt. Um zügig in die Entwicklung starten zu können, werden die benötigte Infrastruktur und Dienste – z.B. Versionskontrollsysteme, Basis-Setup Continuous Integration, Delivery und Deployment – eingerichtet und konfiguriert. Auch eine Entwicklungsumgebung sowie die enthaltenen Werkzeuge zur Qualitätssicherung werden definiert und allen Beteiligten zur Verfügung gestellt.
Frontend UI Component Development
Auf Basis der Interface-Design-Spezifikationen werden die benötigten Design-Komponenten in Form von Frontend-Komponenten implementiert. So findet eine nahtlose Transition von Design-Ressourcen zu Frontend-Ressourcen statt. Die so gewonnenen Frontend-Komponenten werden häufig in Form einer Pattern Library vorgehalten und über alle relevanten Bestandteile – wie verschiedene Micro-Frontends – des Produkts verteilt. So wird maximale Wiederverwendung und Konsistenz in der Nutzerinteraktion gewährleistet.
Frontend Application Development
Um die Fachlichkeit und technische Integration im Frontend abzubilden, werden in der Regel eine oder mehrere Frontend-Anwendungen benötigt, die gemeinsam mit einem Backend die Geschäftslogik implementieren. Die Anwendungen konsumieren die Frontend-UI-Komponenten, um daraus die benötigten Ansichten zu komponieren und diese zu präsentieren.
Test Development
Um möglichst fehlerarme Releases zu produzieren, werden die jeweiligen Versionen der Frontend-UI-Komponenten sowie der Frontend-Anwendungen getestet. Das geschieht in der Regel automatisiert im Zuge eines Continuous-Integration-Szenarios. Dabei kommen meist sowohl Unit-Tests als auch End-to-End-Tests zum Einsatz.
Backend Integration
Um eine Frontend-Anwendung in das Gesamtprodukt zu integrieren, muss sichergestellt werden, dass Frontend-Implementierung und Backend-Systeme über Schnittstellen kommunizieren können. Dabei werden in aller Regel standardisierte Protokolle wie RESTful JSON oder GraphQL eingesetzt. Auch Authentifizierung und Autorisierung sind relevante Aspekte der Backend-Integration.
Service Integration
Werden Dienste Dritter wie Geo-Referenzierung oder Tracking-Lösungen benötigt, um eine Funktionalität abzubilden, so sollten diese ebenfalls zu einem frühen Zeitpunkt eingebunden werden, um sicherzustellen, dass sie die relevanten Funktionen bereitstellen können, die den fachlichen und technischen Rahmenbedingungen entsprechen und sich der gewählten Architektur unterordnen.
Operations Priming, CI/CD
Um eine Frontend-Anwendung in einen betriebsfertigen Zustand zu versetzen, werden häufig verschiedene Anpassungen nötig. Dabei handelt es sich meist um Optimierungen in Bezug auf Laufzeit-Performanz und Betriebssicherheit. Um die Verteilung von Releases fehlerarm und kontrollierbar durchführen zu können, werden in der Regel Continuous-Delivery- oder Continuous-Deployment-Automatismen realisiert. So kann jedes Release oder jede Version ohne zusätzlichen Aufwand automatisch oder manuell veröffentlicht werden.
Backend Engineering
Im Backend wird meist auf Basis der Gesamt-Produkt-Architektur und der definierten fachlichen Anforderungen der wesentliche Teil der Geschäftslogik eines Produktes realisiert. Dabei handelt es sich um den rein technischen Anteil, der für den Anwender unsichtbar bleibt. Frontend und Backend kommunizieren meist über Schnittstellen, sogenannte APIs (Application Programming Interfaces), die vom Backend vorgehalten und vom Frontend konsumiert werden.
Auch die Themen Zugriffskontrolle, Rechtemanagement, Datenhaltung und Integration weiterer Services sind meist im Backend verortet und werden hier implementiert.
Die generelle Backend-Architektur definiert auf hohem Niveau, welche Bestandteile innerhalb des Backend-Systems existieren, welche Aufgaben diese wahrnehmen und wie diese verteilt sind. Dabei können ebenso fachliche wie technische Abgrenzungskriterien definiert werden. Durch eine klare architektonische Trennung kann einfacher mit Abhängigkeiten umgegangen und mit mehreren Entwicklern in einem Projekt agiert werden. Auch die Integration weiterer Services – z.B. Single-Sign-On-Dienste, Anbindung an Fremdsysteme – muss berücksichtigt werden.
Technology Selection and Setup
Die Wahl der geeigneten Technologien erfolgt in der Regel im Rahmen der architektonischen Überlegungen. Dabei spielen nicht nur Überlegungen zur Erfüllung der Anforderungen, sondern auch betriebliche Anforderungen eine wesentliche Rolle. Wenn verteilte Systembestandteile erforderlich sind oder durch die Architektur vorgegeben werden, muss die Integration der verschiedenen Systemfragmente berücksichtigt und verprobt werden. Alle Bestandteile werden eingerichtet, auf repräsentativer Infrastruktur bereitgestellt und es wird deren Funktionalität getestet.
Backend Application Development
Im Rahmen der Backend-Implementierung kommen häufig verschiedene – auch sehr spezielle – Technologien zum Einsatz, um die verschiedenen Aspekte eines Produktes abzubilden. Die Implementierung von Geschäftslogik über mehrere Technologien und Systeme erfordert ein äußerst strukturiertes und planvolles Vorgehen.
API-Design and Development
Um die Services eines Backends für das Frontend, aber auch weitere Konsumenten verfügbar zu machen, muss das Backend eine oder mehrere strukturierte, dokumentierte und verständliche Schnittstellen exponieren. Mittels dieser API-Implementierungen können Daten bezogen oder bereitgestellt werden, Prozesse angestoßen oder Prozeduren ausgeführt werden. Wie eine API ausgeführt wird und welchem Konzept die Ausführung folgt, hat erheblichen Einfluss darauf, wie komplex sich deren Integration darstellt.
Service Integration
Werden erweiterte Funktionalitäten oder Informationen aus Drittsystemen benötigt, werden diese in der Regel über Schnittstellen an das Backend angebunden. Dabei exponieren die Fremdsysteme eine Schnittstelle, die vom Backend konsumiert wird. Das bedeutet, dass das Backend unter Umständen verschiedene API-Protokolle und -Paradigmen als Client implementieren muss.
Test Development
Um fehlerarme Releases zu produzieren, werden die jeweiligen Versionen der Backend-Bestandteile intensiv getestet. Das geschieht in der Regel automatisiert im Zuge eines Continuous-Integration-Szenarios. Dabei werden je nach Technologie und Projektcharakter diverse Teststrategien eingesetzt – von Unit-Tests über Integrations- und Regressionstests bis hin zu API-Tests.
Operations Priming, CI/CD
Um eine aus mehreren Bestandteilen bestehende Backend-Anwendung in einen betriebsfertigen Zustand zu versetzen und in Produktion zu verteilen, sind häufig komplexe Build- und Deploy-Prozesse notwendig. Um die Verteilung von Releases kontrollierbar und automatisiert durchführen zu können, werden in der Regel Continuous-Delivery- oder Continuous-Deployment-Automatismen realisiert.
Eine Phase oder Methode wählen für weitere Details …
Finden Sie heraus, ob wir Ihr Projekt gemeinsam erfolgreich gestalten können.