© Excellent backgrounds/Shutterstock.com
Java Magazin
BPM abgespeckt - ein Praxisbericht

Vom gescheiterten BPMS zum Open-Source-Eigenbau

Business Process Management (BPM) ist schon lange kein Hype mehr, sondern zählt in vielen Softwareentwicklungsabteilungen bereits zum täglich Brot. Nur leider haben sich viele BPM-Systeme am Markt etabliert, die den modellgetriebenen Ansatz nicht nur für die Prozessmodelle verfolgen, sondern auch für den Rest der Geschäftslogik. Dieser „Zero-Code-Ansatz“ mag in manchen Fällen gut funktionieren, jeder Entwickler weiß aber, dass ab einem bestimmten Komplexitätsgrad schnell die eine oder andere Codezeile notwendig wird. Doch es können auch noch ganz andere Probleme auftreten.

Michael Scholz


Wir befinden uns in der IT-Abteilung eines deutschen Automobilzulieferers vor einigen Jahren. Zur Erarbeitung der IT-Strategie für die nächsten Jahre wurde ein großes Beratungshaus konsultiert. Eine der Empfehlungen lautete: Automatisierung von Geschäftsprozessen mit BPM. Zur Umsetzung wurden drei kommerzielle BPM-Systeme (BPMS) als geeignet und strategisch sinnvoll empfohlen. Eines davon wurde danach per PoC (Proof of Concept) und Entscheidungsmatrix sorgfältig ausgewählt. Die ersten umzusetzenden Prozesse stammten aus dem Bereich Materialwirtschaft und überspannten mehrere Fachbereiche und IT-Systeme (BS2000 Mainframe, E-Sourcing und MDM sowie Engineering-Systeme). Mit der Entwicklung wurde ein Entwicklerteam beauftragt – zusammengesetzt aus Consultants des Herstellers und auf Kundenseite dem Autor des Artikels, der bisher hauptsächlich Erfahrungen mit Java (EE) hatte. Später wurden weitere interne Kollegen hinzugezogen, um für einen langsamen Wissenstransfer zu sorgen und den Consultingaufwand schrittweise zurückfahren zu können. Unglücklicherweise kamen mit diesem System nach und nach immer mehr Probleme auf. Deren übergreifende Ursache war letztendlich die Komplexität der Gesamtlösung.

Die Probleme häufen sich

Das gekaufte BPMS war über Jahre gewachsen und aus verschiedenen Einzelprodukten und Komponenten zusammengeschweißt: einer Prozess-Engine, einem System zur Aufgabenverwaltung, einem Enterprise Service Bus, einem Portal und weiteren. Natürlich waren diese Komponenten miteinander auf verschiedene Art und Weise über diverse Schnittstellen und Technologien verbunden. Doch es fehlte ein zentrales Konzept. Das führte einerseits zu einem wirren Konfigurations­dschungel und andererseits oftmals zu Inkompatibilitäten nach dem Einspielen von Patches oder Updates für einzelne Komponenten oder auch des Gesamtsystems. Das Patchmanagement musste deshalb schließlich sogar per Outtasking dem Hersteller übergeben werden.

Nahezu jede Komponente des Stacks arbeitete mit eigenen Entwicklungstools, die teils unterschiedliche Ideen bezüglich Coding, Testen, Versionierung, Build Management und Deployment verfolgten. Einige Tools erlaubten nur „Live Editing“ auf einem gemeinsamen Development-Server – es gab also keine isolierte Umgebung für den einzelnen Entwickler. Das ließ natürlich kaum einen kontrollierten Entwicklungsprozess zu. Eine gemeinsame Versionierung oder ein gemeinsamer Build der diversen Einzelartefakte war ebenso nicht oder nur eingeschränkt möglich, wa...

Java Magazin
BPM abgespeckt - ein Praxisbericht

Vom gescheiterten BPMS zum Open-Source-Eigenbau

Business Process Management (BPM) ist schon lange kein Hype mehr, sondern zählt in vielen Softwareentwicklungsabteilungen bereits zum täglich Brot. Nur leider haben sich viele BPM-Systeme am Markt etabliert, die den modellgetriebenen Ansatz nicht nur für die Prozessmodelle verfolgen, sondern auch für den Rest der Geschäftslogik. Dieser „Zero-Code-Ansatz“ mag in manchen Fällen gut funktionieren, jeder Entwickler weiß aber, dass ab einem bestimmten Komplexitätsgrad schnell die eine oder andere Codezeile notwendig wird. Doch es können auch noch ganz andere Probleme auftreten.

Michael Scholz


Wir befinden uns in der IT-Abteilung eines deutschen Automobilzulieferers vor einigen Jahren. Zur Erarbeitung der IT-Strategie für die nächsten Jahre wurde ein großes Beratungshaus konsultiert. Eine der Empfehlungen lautete: Automatisierung von Geschäftsprozessen mit BPM. Zur Umsetzung wurden drei kommerzielle BPM-Systeme (BPMS) als geeignet und strategisch sinnvoll empfohlen. Eines davon wurde danach per PoC (Proof of Concept) und Entscheidungsmatrix sorgfältig ausgewählt. Die ersten umzusetzenden Prozesse stammten aus dem Bereich Materialwirtschaft und überspannten mehrere Fachbereiche und IT-Systeme (BS2000 Mainframe, E-Sourcing und MDM sowie Engineering-Systeme). Mit der Entwicklung wurde ein Entwicklerteam beauftragt – zusammengesetzt aus Consultants des Herstellers und auf Kundenseite dem Autor des Artikels, der bisher hauptsächlich Erfahrungen mit Java (EE) hatte. Später wurden weitere interne Kollegen hinzugezogen, um für einen langsamen Wissenstransfer zu sorgen und den Consultingaufwand schrittweise zurückfahren zu können. Unglücklicherweise kamen mit diesem System nach und nach immer mehr Probleme auf. Deren übergreifende Ursache war letztendlich die Komplexität der Gesamtlösung.

Die Probleme häufen sich

Das gekaufte BPMS war über Jahre gewachsen und aus verschiedenen Einzelprodukten und Komponenten zusammengeschweißt: einer Prozess-Engine, einem System zur Aufgabenverwaltung, einem Enterprise Service Bus, einem Portal und weiteren. Natürlich waren diese Komponenten miteinander auf verschiedene Art und Weise über diverse Schnittstellen und Technologien verbunden. Doch es fehlte ein zentrales Konzept. Das führte einerseits zu einem wirren Konfigurations­dschungel und andererseits oftmals zu Inkompatibilitäten nach dem Einspielen von Patches oder Updates für einzelne Komponenten oder auch des Gesamtsystems. Das Patchmanagement musste deshalb schließlich sogar per Outtasking dem Hersteller übergeben werden.

Nahezu jede Komponente des Stacks arbeitete mit eigenen Entwicklungstools, die teils unterschiedliche Ideen bezüglich Coding, Testen, Versionierung, Build Management und Deployment verfolgten. Einige Tools erlaubten nur „Live Editing“ auf einem gemeinsamen Development-Server – es gab also keine isolierte Umgebung für den einzelnen Entwickler. Das ließ natürlich kaum einen kontrollierten Entwicklungsprozess zu. Eine gemeinsame Versionierung oder ein gemeinsamer Build der diversen Einzelartefakte war ebenso nicht oder nur eingeschränkt möglich, wa...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang