Statt einer umfassenden ERP-Lösung setzt Fuchs Gewürze für Stammdaten und Sales-/Order-Management modulare Microservices ein - und macht damit bislang gute Erfahrungen.
Der niedersächsische Gewürzhersteller Fuchs - gut eine halbe Millarde Euro Jahresumsatz, 3500 Mitarbeiter, 14 Produktionsstandorte auf drei Kontinenten - sah sich 2012 mit Kundenanforderungen konfrontiert, die mit der historisch gewachsenen ERP-Lösung für den Bereich Auftragsabwicklung - Cobol in einer Mainframe-Umgebung - nicht erfüllt werden konnten. Unter großem Zeitdruck setzte man deshalb schnell einzelne Funktionen um. "Das waren eigentlich schon Microservices", so Alexander Fuchs, CIO des Unternehmens aus Dissen am Teutoburger Wald, auch wenn sie erst später so bezeichnet wurden.
Drei Jahre später zieht der IT-Manager gegenüber der COMPUTERWOCHE eine positive Zwischenbilanz der Microservices bei Fuchs Gewürze: Zu einem vertretbaren Preis habe man stabile und leistungsfähige, dazu gut wartbare und entwicklungsfähige Software bekommen.
Bei Fuchs Gewürze stehen Microservices hoch im Trend. Bei uns erfahren Sie aus erster Hand, wie die Implementierung von statten ging. Foto: Sergey Nivens, Fotolia.de
Fuchs Gewürze: Der Status Quo 2015
Flexibel zusammengesetzte Teams aus insgesamt sieben internen und externen Entwicklern haben bei Fuchs Gewürze bis heute 25 Services entwickelt, davon zehn mit grafischer Benutzeroberfläche. Abgedeckt werden etwa die Stammdatenverwaltung mit Artikel- und Kundenstammdaten einschließlich Kundenservice, dazu Vertrieb und Auftragseingang sowie die Verwaltung der Konditionen, zu denen Fuchs mit einzelnen Kunden Geschäfte macht.
Als technische Basis wurden Ruby on Rails sowie mehrere Open-Source-Bibliotheken aus dem Rails-Umfeld eingesetzt, dazu Rabbit MQ als Messaging-Service und pro Service eine relationale Oracle-Datenbank. Der Entwicklungsprozess folgt den Prinzipien von Continuous Integration und Continuous Delivery. Jeder Service durchläuft dabei eine Karriere von der Code-Versionierung über die eigentliche Entwicklung, Funktions- und Integrationstests sowie die Bereitstellung der entsprechend konfigurierten Server (Provisioning) bis hin zum separaten Deployment.
Alexander Fuchs ist CIO des traditionsreichen Marktführers im Bereich Gewürze. Foto: Fuchs Gewürze GmbH
Schlanker und flexibler als full-blown ERP
Eine umfassende ERP-Einführung hatte man bei Fuchs ebenfalls evaluiert, aber frühzeitig ausgeschlossen. SAP - das ansonsten im Unternehmen, etwa in der Finanzbuchhaltung, bereits eingesetzt wird - hätte zwar mit weiteren Komponenten wie dem Vertriebsmodul SD weiter ausgerollt werden können. Schon in der Konzeptphase sah man jedoch, dass der Aufwand sehr hoch gewesen wäre und zwar für beide Alternativen: die Anpassung der Organisation auf die Standardsoftware, wie auch das Customizing der Standardsoftware.
Zudem erschien der typische serielle Verlauf von SAP-Projekten - mit langer Konzeptphase, folgender Implementierung, abschließenden Tests und Go-live als "Big Bang" - den IT-Entscheidern bei Fuchs zu risikoreich; man fürchtete Produktivitätsverluste. Die Strategie, für die man sich bei Fuchs stattdessen entschied, fasst der CIO rückblickend als "Aushöhlen" der alten Lösung und sukzessives Einführen neuer Komponenten zusammen. So konnte man das monolithische Legacy-System aufbrechen, um die Einführung von neuen Softwarelösungen zu ermöglichen - und das ohne "Big Bang", wie eine klassische ERP-Einführung ihn bedeutet hätte.
Weil man bei Fuchs Gewürze bereits über Erfahrungen mit agiler Softwareentwicklung verfügte, wurde dieser Weg weiterverfolgt. Am Anfang wird nur ein Minimalprozess mit den absolut unverzichtbaren Funktionen geplant, sehr schnell umgesetzt und produktiv geschaltet. Mit diesem unvollständigen Produkt-Inkrement sammelt man Erfahrungen, trifft auf deren Basis weitere Design-Entscheidungen und entwickelt die Software erst dann fertig.
8 Trends, die den Markt für Enterprise Software prägen werden
Hybrid Cloud wird zum Mainstream-Thema. Chris Wolf, Chief Technolgy Officer (CTO) bei VMware in den USA, hat im vergangenen Jahr eine Tendenz zu Multi-Cloud-Strategien beobachtet, die sich seiner Einschätzung nach 2015 verstärken wird. „CIOs wollen die Flexibilität nutzen, die Hybrid-Cloud-Umgebungen bieten“, sagt Wolf. „Und Senior IT-Entscheider werden in Hybrid-Cloud-Architekturen investieren, um ihre Anwendungen und Services zukunftssicher zu gestalten.“ Mit dieser Einschätzung ist der VMware-Manager nicht allein. Für Marc Malizia, CTO bei RKON Technologies, einem Anbieter von Managed-Cloud-Lösungen, wird sich der Trend nicht mehr umkehren: „Die Cloud ist nun schon seit einigen Jahren ein ganz heißes Thema. Unternehmen legen Anwendungen in die Wolke, um schneller zu werden, die Kosten zu senken und einen höheren Servicelevel zu erreichen.“ Malizia erwartet, dass sich 2015 sehr viele Firmen für ein Hybrid-Cloud-Modell entscheiden und dabei externe Cloud-Services mit ihrer hausinternen Private Cloud integrieren werden.
Enterprise Mobile Apps heben ab. Mobile CRM wird eines der Themen sein, die Enterprise-Software auf mobilen Endgeräten zum Durchbruch verhelfen. Dazu hat nicht zuletzt Salesforce.com beigetragen, das 2014 massiv in seine Mobile Apps investiert und auch seine Integrationspartner dazu gedrängt hat. Mark Seemann, CEO von Synety, einem Spezialisten für die Integration von VoIP-Telefonie in Business-Anwendungen, sieht „Mobile als das wichtigste Schlachtfeld für die großen CRM-Anbieter“. Die Funktionalität der zahlreichen Apps werde sich weiter der von klassischen Web-basierten CRM-Lösungen annähern. Michael DeFranco, Gründer und CEO von Lua, einem Anbieter von sicheren Messaging-Lösungen für Unternehmen, stimmt zu: “Die Mitarbeiter von Unternehmen halten sich immer seltener in ihren Büros und immer häufiger beim Kunden auf. Lösungen wie CRM oder BPM, die mobil einsetzbar sind, werden essenziell.“ Allerdings müsse deren Design optimal auf die Bedürfnisse und das Verhalten mobiler Nutzer abgestimmt sein. Die störungsfreie Kommunikation und Teamarbeit mit den Kollegen im Büro und unterwegs sei erfolgskritisch.
Enterprise Software wird im Abo bezogen. Anstatt Lizenzen zu kaufen, werden Anwender im großen Stil auf Subskriptionsmodelle wechseln. Das erwartet unter anderem Engin Kirda, Mitgründer und Chief Architect des Security-Anbieters Lastline. „Die Abrechnung von Pro-User- und Pro-Jahr-Gebühren kommt auch für Enterprise-Software und ersetzt Pauschalpreise für Lizenzen und teure Software-Preloads für proprietäre Hardware.“ Nicht nur Enduser-bezogene Anwendungen würden künftig so berechnet, sondern auch Enterprise-Software und -Services – beispielsweise Lösungen für das Data Center Management oder die Einbruchserkennung und –vorbeugung. Die neuen Pricing-Modelle seien besser kalkulierbar und skalierbar.
In-Memory Computing trennt Spreu und Weizen im ERP-Markt. „Plattformen wie SAP HANA oder Oracle In-Memory Application werden vor allem im Großkundenmarkt den Unterschied zur Konkurrenz ausmachen“, meint Glenn Johnson, Senior Vice President bei Magic Software Enterprises, einem Anbieter von Anwendungs-, Mobility- und Integrationslösungen. “In dem Maße, wie der Hype um Big-Data-Lösungen zunimmt, wird es für ERP-Unternehmen, die – anders als die ganz großen Player - keine In-Memory-Lösungen haben, schwieriger.“
ERP-Welten öffnen sich für tiefe Integration. „ERP wird flexibler und ermöglicht die Einbindung neuer Einkaufs-, HR- und Kundenservicelösungen“, beobachtet Michael Golz, Senior Vice President und CIO von SAP Americas. SAP habe einige strategische Übernahmen getätigt, darunter die des auf Reisekosten-Management spezialisierten Anbieters Concur. Solche Lösungen könnten ERP-Kunden helfen, den Wert ihres Systems zu erhöhen und den Rahmen auszuweiten. Damit verschwänden die Grenzen zwischen den Enterprise-Software-Systemen immer mehr, und der Wert von IT-Investitionen steige. „Historisch wurden ERP und CRM als zwei separate Systemwelten gesehen“, ergänzt Jeremy Roche, CEO von FinancialForce, einem Anbieter von ERP-Software auf der Salesforce-Plattform. Mittlerweile realisierten viele Unternehmen aber den großen Wert, der darin liege, die Trennung zwischen Front- und Back-Office-Prozessen aufzuheben und das ERP-System ähnlich wie die CRM-Welt weiter in den Vordergrund zu rücken. „Anstatt zu erlauben, dass wichtige Kundeninformationen irgendwo im Unternehmen verteilt herumliegen, gehen Unternehmen daran, CRM und ERP zu einem einzigen System of Engagement zu verschmelzen. So können sie die gesamte ‚Customer Journey‘ begleiten – von der Geschäftsanbahnung bis zur Auslieferung des Produkts und nachgelagerten Service-Prozessen.“
Open Source gewinnt weiter an Bedeutung. Data Warehousing und Business Intelligence waren lange die Domäne einiger weniger Anbieter von proprietärer Software. Das hat sich geändert. „In den vergangenen zehn Jahren haben sich Techniken wie Hadoop oder später auch Apache Spark als preiswerte Open-Source-Alternativen etabliert, die sowohl vom Maßstab als auch von der Raffinesse her alles mitbringen, um große Datenmengen analysieren zu können“, beobachtet Ali Ghodsi, Mitgründer von Databricks. 2015 werde diese und andere Open-Source-Software noch tiefere Spuren in der Enterprise IT hinterlassen. „Das Hadoop-Ökosystem soll bis 2020 einen Gesamtwert von 25 Milliarden Dollar erreichen“, beruft sich Ghodsi auf Marktforscher. Und Spark werde inzwischen von mehr als zehn Anbietern vermarktet, darunter Größen wie SAP, Oracle, Microsoft und Teradata. Alle großen BI-Tools wie Tableau, Qlik oder MicroStrategy würden unterstützt.
BI-Software wird visuell und einfacher zu nutzen. „2015 werden Business-Intelligence-Lösungen so gut aussehen wie sie funktionieren - und so gut funktionieren wie sie aussehen“, sagt James Richardson, Business-Analytics-Stratege bei Qlik, einem Anbieter von BI- und Datenvisualisierungswerkzeugen. „Unternehmenskunden verlangen BI-Lösungen, die einfach zu nutzen sind – Self-Service-Lösungen. Visualisierung ist der Schlüssel dafür. Indem Daten in einfach zu erfassende Graphen und Charts aufgelöst werden, können User die Inhalte schnell und auf natürliche Art erfassen. Damit werden die Barrieren zwischen den Menschen und ihren Daten beseitigt“, so der Qlik-Manager.
Social-Web-Analyse wird selbstverständlich. „2014 haben wir gesehen, dass die Unternehmen ernsthaft damit begonnen haben, Social Data zu analysieren“, sagt Ellie Fields, Managerin bei Tableau Software. Dieser Trend werde sich 2015 weiter verstärken. „Indem Konversationen im Social Web analysiert werden, können Unternehmen herausfinden, worüber ihre Kunden reden und wann ein Thema zu einem Trend wird.“ Social Intelligence sorge dafür, dass Firmen schneller würden und auf Kundenanforderungen, -wünsche und -beschwerden zeitnah reagieren könnten. Wer hier nicht aktiv werde, bringe sich gegenüber dem Wettbewerb ins Hintertreffen.
Prozesswissen effizient verarbeiten
Microservices schätzt man bei Fuchs mittlerweile als stabiles Fundament, um Eigenentwicklungen mit Standardsoftware in Systemlandschaften zu integrieren. "Bei Einführung neuer Software gibt es künftig immer eine Alternative mehr. Wir setzen Microservices verstärkt in Bereichen ein, wo wir mit Standardsoftware einen zu hohen Customizing-Bedarf erwarten", erläuter Alexander Fuchs. Agile Softwareentwicklung helfe, benötigtes Prozesswissen möglichst effizient zu erarbeiten und in lauffähige Software zu überführen. Es sei freilich nicht ausgeschlossen, dass einzelne Microservices später durch Standardsoftware abgelöst würden.
Knackpunkte in agilen Entwicklungsteams
Knackpunkte in agilen Entwicklungsteams Seit die Verfasser des "Agilen Manifests" im Jahr 2001 den klassischen Phasenmodellen wie Wasserfall und V-Modell den Kampf angesagt haben, erlebt die Softwareentwicklung eine tief greifende Veränderung. Mittlerweile ist Agilität fast zu einem Hype-Begriff geworden. Darüber gerät gelegentlich aus dem Blick, was die Methode tatsächlich leisten kann und an welchen Stellen das ursprüngliche Dokument von 2001 aufgrund von Projekterfahrungen aus mehr als einer Dekade präzisiert werden sollte.
Crossfunktionale Teams aus Spezialisten und Generalisten bilden
Teamübergreifende Governance sichern
Verantwortungsvolles und pro-aktives Handeln der agilen Teammitglieder
Ständige Kommunikation innerhalb und zwischen Sprint-Teams
An agiler Community aktiv teilnehmen und auf Best Practices setzen
Verständigung über technisches Rahmenwerk (Architektur) herstellen
Bereitstellung von Testdaten und Ausführung von Integrationstests sichern
Dokumentation im Hinblick auf Compliance nicht vernachlässigen
Komplexität einer verteilten Systemlandschaft
Bei allen positiven Erfahrungen: Es gibt durchaus Faktoren, die Microservices als Architekturmodell zu einer Herausforderung machen, wie sich in der Praxis beweist. "Man halst sich die Komplexität einer verteilten Systemlandschaft auf mit der Konsequenz, Konsistenz und Transaktionssicherheit herstellen zu müssen", räumt Alexander Fuchs ein. Infrastrukturlösungen in Form von Loadbalancing- und Monitoring-Werkzeugen existieren zwar am Markt. Die erforderlichen Skills freilich mussten am Teutoburger Wald seinerzeit aufgebaut werden. "Die Leute müssen im Team skalierbare, robuste SW entwickeln können, die hohen architektonischen Qualitätsansprüchen gerecht wird", so Fuchs. Außerdem sei die Fähigkeit zur Kommunikation mit den Fachbereichen gefordert. Kurzum: "Man muss sich als Microservices-Entwickler im agilen Umfeld wohlfühlen."
Zudem: Bei aller Agilität des Vorgehens ist gute Planung besonders im Microservices-Umfeld wichtig, insbesondere hinsichtlich der Architektur. Der Microservices-Ansatz birgt nämlich das Risiko, "fachliche Domänen nicht richtig zu zerlegen, also irrtümlich Dinge zu trennen die zusammengehören und damit vermeidbare Schnittstellenkomplexität zu erzeugen", warnt Fuchs und rät, im Zweifelsfall prophylaktisch Funktionalitäten zunächst zusammenzuhalten und Sie erst später bei Bedarf zu zerlegen.
Aus seinen Alltagserfahrungen im IT-Management leitet Alexander Fuchs als Wirtschaftsinformatiker auch theoretische Überlegungen ab, die sich auf die Trennschärfe der Begriffe Microservices und SOA (serviceorientierte Architektur) beziehen. Auf den ersten Blick ähneln sich die Ideen: In beiden Fällen handelt es sich um eine Architektur, die aus wiederverwendbaren und in unterschiedlichen Kontexten konfigurierbaren Services, beziehungsweise Funktionsmodulen, zusammengesetzt ist.
(Quelle: video2brain, Trainer: Christopher Janietz)
Viele SOA-Implementierungen haben jedoch einen zentralistischen Ansatz, erläutert Fuchs den Unterschied. SOA sei ein Konstrukt mit einem mächtigen Integrationswerkzeug, einer intelligenten Middleware, etwa einem ESB (Enterprise Service Bus). Der könne zwar unterschiedliche Komponenten "fest miteinander verdrahten" und sei in dieser Hinsicht flexibel. Weil er aber große Teile der Prozesslogik selbst enthalte, mache er sich unverzichtbar. "Das Ding in der Mitte wird man nie wieder los" warnt Fuchs. Das Ziel, Anwendungen voneinander zu entkoppeln, gerate in Gefahr, wenn der zentrale ESB sie mithilfe von Engines für Business-Prozesse und -Regeln sowie durch Routing, Mapping etc. miteinander verklebe. Bei Microservices dagegen stecke die Logik in den Endpunkten, weshalb sie als "Methode zur Komplexitätsbehandlung" weitaus besser geeignet seien.
Eine Systemlandschaft ganz aus Microservices kann sich der CIO - zumindest gegenwärtig - nicht vorstellen; dazu müssten alle Softwarehersteller ihre Anwendungen einzeln als umsetzungsfähige ("deploybare") Apps anbieten. Fuchs ruft damit nach einer umfassenden App-Economy, wie sie ja auch tatsächlich bereits prognostiziert wird. (fm)
Sieben Fragen zur SOA-Effizienz
7 Fragen zur SOA-Effizienz Das Potenzial für die Automatisierung der Geschäftsprozesse, das in einer Service-orientierten Architektur steckt, bleibt oft ungenutzt. Wenn das so ist, ändert auch eine Modernisierung nichts daran.
1. Ist die SOA kompatibel mit Geschäftsmodell und IT-Landschaft? Zunächst wird man vorbehaltlos rekapitulieren müssen, ob die ursprüngliche Entscheidung für SOA vor dem Hintergrund der aktuellen Bedingungen eigentlich noch die richtige ist. War der Bedarf für wiederverwendbare IT-Services so groß wie erwartet? Ist die Systemlandschaft tatsächlich so heterogen, dass sie eines ESB bedarf? Von entscheidender Bedeutung ist auch, ob sich in den fachlichen Prozessen die Servicequalität verbessern lässt, wie das SOA-Konzept es verspricht.
2. Verwirklicht die SOA konsequent eine Architekturentscheidung? Schon der Name Service-oriented Architecture zeigt an, dass es um eine IT-Architektur und eine grundsätzliche Entscheidungen in IT-Fragen geht. Nötig sind deshalb klare Vorgaben, für welche Einsatzgebiete der ESB beziehungsweise eine Orchestrierung in BPEL und BPMN (Business Process Model and Notation) zu verwenden sind.
3. Werden die Potenziale zur Effizienzsteigerung genutzt? Eine IT-Architektur ist kein Selbstzweck. Die bloße Möglichkeit, flexible IT-Services aufsetzen zu können, rechtfertigt die Investitionen nicht. Nur wenn die Service-orientierte Architektur hilft, die Effizienz im Unternehmen zu steigern, zahlt sich der Aufwand aus.
4. Behindert eventuelles Silodenken den effizienten SOA-Einsatz? Die Kopplung einzelner Systeme zu übergreifenden Prozessketten ist eher eine organisatorische Herausforderung als ein IT-Poblem. SOA-Potenziale lassen sich oft nur ausschöpfen, wenn vorher eine Silo-übergreifende Prozessoptimierung stattgefunden hat.
5. Liefern die Services aussagekräftige Kennzahlen? Bei der Orchestrierung und in den Services sind standardisierte Messpunkte zu setzen, die sich für die Auswertung durch ein Business-Activity-Monitoring eignen. Zudem liefern diese Messpunkte die Grundlagen für die KPI-Überwachung (Key Performance Indicators) sowie die kontinuierliche Prozessoptimierung.
6. Funktioniert die IT-Governance? Als strategische Entscheidung bestimmt SOA, wie Prozesse in der IT abgebildet werden. Deshalb hängt sie eng mit der IT-Governance zusammen. Wenn es keine gibt oder die vorhandene nicht funktioniert, ist das häufig ein Grund für das Versanden von SOA-Projekten.
7. Welche SOA-Infrastruktur passt in das Unternehmen? Erst nachdem die bisherigen SOA-Initiativen hinterfragt wurden, stellt sich die Frage nach einer Migration oder Modernisierung. Auch hier gilt: Die Komponenten müssen zur Strategie des Unternehmens und der dort vorherrschenden IT-Systemlandschaft passen.