Warum MACH?

Der Aufbau der MACH-Architektur kann mit einem Baukastensystem, das aus einzelnen, voneinander unabhängigen Microservices besteht, verglichen werden. Microservices sind einzelne Komponenten, die bestimmte Funktionen in der Gesamtlösung erfüllen. Durch deren Unabhängigkeit ist es möglich, dass die (Weiter-)Entwicklung einzelner Microservices losgelöst von anderen fachlichen Bereichen möglich ist. Konkret bedeutet das, dass fachliche Kompetenz simultan von mehreren cross-funktionalen Teams in einem agilen Arbeitsumfeld in innovative Features überführt wird und die Lösungen autark zum Kunden ausgeliefert werden können ("Continuous Integration & Continuous Delivery” [CI/CD]). Weitere Vorteile von Microservices sind, dass sie je nach Bedarf frei miteinander kombiniert werden können und dass deren Betrieb und Support auf geteilter Infrastruktur erfolgt, um eine hohe Synergie und Effizienz der einzelnen Bereiche zu erreichen.

APIs (Application Programming Interface) sind technische Schnittstellen einer Softwarelösung, um die Integrationen von weiteren Systemen (“Best-of-Breed-Ansatz”) reibungslos zu ermöglichen. Die Dokumentation unserer API ist öffentlich zugänglich und beschreibt u.a. für Partner und Entwickler genau, wie Funktionen der Plattform nutzbar und welche Datenformate vorgesehen sind. Die fulfillmenttools API ist dabei Client agnostisch. Das bedeutet, dass die Plattform prinzipiell mit jeder Art von Clients funktioniert und durch verbreitete Standards die Einstiegshürde für die Verwendung niedrig hält. Bei fulfillmenttools laufen auch die bereitgestellten Clients 100% auf den offiziell betriebenen und veröffentlichten APIs.

In der MACH-Architektur bedeutet der Begriff „Cloud-native“, dass nicht nur die Daten der Softwarelösungen in der Cloud gespeichert werden, sondern dass auch die Datenverarbeitung in der Cloud stattfindet. So wird die kostspielige Nutzung von lokalen On-Premise Systemen überflüssig und die Lösungen lassen sich grenzenlos skalieren. Händlern wird auf diese Weise die Flexibilität geboten, ihre Kapazitäten den Markt- und Kundenanforderung entsprechend anzupassen und gleichzeitig die Betriebskosten möglichst gering zu halten. Auch die fulfillmenttools Plattform wird in der Cloud mit modernsten Technologien betrieben. Die Datenverarbeitung und -speicherung aller verwendeten Komponenten findet in Belgien und Deutschland statt, kann aber auf Wunsch auch in anderen Regionen betrieben werden. Außerdem folgen alle Plattform-Komponenten dem Best-of-Breed-Ansatz und erlauben unabhängige und kosteneffiziente Skalierung. Der Betrieb und Support der Cloud-Infrastruktur wird durch unsere In-House Site Reliability Engineers abgedeckt – bei der Skalierung unserer Services setzen wir auf unseren Hyperscaler, die Google Cloud Plattform.

Ist bei einem System bzw. einer Lösung die unterliegende Funktionalität in erster Linie über eine API abrufbar, spricht man von einer Headless-Architektur. Die Microservices, d.h. die Geschäftslogiken, können so über APIs flexibel an ein beliebiges Frontend, egal ob Eigenentwicklung oder anderweitig verfügbare Kanäle, angebunden werden. Dies ist möglich, weil die Systemarchitektur von Anfang an darauf ausgelegt ist, dass auf technischer Ebene alle Systeme und Frontends miteinander funktionieren. Außerdem wird eine Machine-to-Machine Kommunikation, die die absolute Basis für Automatisierungen jeglicher Art ist, sichergestellt. Bei fulfillmenttools gilt Headless “Plus”. Das heißt, dass unsere Plattform zu 100% Headless betrieben werden kann – für einen Teil unseres Systems (z.B. das operative Abarbeiten von Kundenbestellungen) können aber von fulfillmenttools entwickelte Anwendung, bspw. von uns bereitgestellte Apps oder Webanwendungen, hilfreich sein. Wir liefern hier standardmäßig Lösungen aus, die Kunden nutzen können – aber nicht müssen!