Neuigkeiten aus der tarent Gruppe und der Softwarewelt

Im März 2009 hat die tarent den Zuschlag für einen Rahmenvertrag mit dem Bundesministerium des Inneren erhalten. Das Ministerium greift damit auf die umfangreichen Erfahrungen der tarent in der Entwicklung und Pflege von Fachanwendungen zurück. Vorteil ist insbesondere die Möglichkeit der flexiblen Unterstützung: Der Leistungsumfang reicht von der Beratung, Analyse und Erstellung von Fachkonzepten über die Entwicklung von Individualsoftware bis zur Schulung von Mitarbeitern. Dokumentenzentrierte Fachverfahren gehören ebenso zu den bereits beauftragten Lösungen, wie die Implementierung eines Single Sign-On als Ergänzung bestehender Anwendungen.

Business-Process-Management (BPM) in die Praxis umzusetzen, gehört zu den größeren Herausforderungen für eine IT-Abteilung. Zehn Empfehlungen helfen, Projekte zu stemmen und das System zukunftssicher zu gestalten.

1. Barrieren überwinden

Prozess-Management setzt voraus, dass sich die fachliche und die technische Seite, zwei Bereiche mit unterschiedlicher Sprache, nicht nur verständigen, sondern im Klaren sind, dass sie Partner in einem Implementierungsprojekt mit weit reichenden Folgen für ihr Unternehmen sind. Das Team sollte alle Mittel nutzen, die Kommunikation zwischen den Abteilungen anzustoßen und lebendig zu halten, um genug gemeinsames Wissen zu gewinnen. Ein externer Partner kann in der Planungsphase eines Projekts helfen, vorausgesetzt er bringt nachweislich gute Kommunikations- und Organisationsfähigkeiten mit.

2. Die Fundamente bestimmen die Haltbarkeit

Ein Business-Process-Management-System (BPMS) besteht aus vielen Einzelkomponenten, die höchst unterschiedliche Aufgaben erfüllen, gleichwohl aber reibungslos zusammenarbeiten müssen. Das wird nur gelingen, wenn die IT-technische Entwicklung auf einem klaren Framework, einem funktionalen Konzept aufsetzt, das flexibel und erweiterungsfähig ist. Das Framework umfasst eine Prozess-Engine, die Aufgabenverwaltung auf dem Benutzer-Interface, eine Service-Registry für alle Zugangsinformationen und gegebenenfalls auch die Service-Infrastruktur der Basisdienste. Die Nagelprobe für die Qualität dieses Fundaments ist jeder Änderungswunsch. Von einem guten Konzept darf das Projekt-Management nicht mehr abweichen.

3. Offen sein für Neues

BPM-Umgebungen erleben durch neue oder angepasste Prozesse häufige Änderungen. Folglich sollte ein solches System darauf angelegt sein, den Aufwand für solche Änderungen klein zu halten und dadurch die Prozesstreue zu verbessern. Das setzt wiederum voraus, vorab denkbare Change-Szenarien zu analysieren, Erweiterungen einzuplanen und die Ergebnisse solcher Überlegungen in den Prozess der Entwicklung eines Frameworks einfließen zu lassen.

4. Klare Zuständigkeiten und Abläufe definieren

IT-Prozesse orchestrieren bestehende Basisfunktionen. Diese müssen klar strukturiert und definiert sein. Prozesse können Schwächen der Servicemodellierung an der Basis nicht ausgleichen. Vielmehr machen sich Probleme in diesem Bereich bei späteren Veränderungen der Prozesse bemerkbar und führen zu ineffektivem Prozess-Management. Das kann gegebenenfalls das Gesamtziel eines BPM-Systems gefährden.

5. Prozesse sollen von Dauer sein

BPM-Systeme haben eine überdurchschnittliche Lebensdauer. Insbesondere die aus bewährten Fachverfahren entwickelten Prozessdefinitionen überleben die üblichen Turnaround-Zyklen der IT. Daher müssen sie portabel angelegt werden, um die ihnen zugrunde liegende technische Infrastruktur einschließlich der Prozess-Engine mit möglichst geringem Aufwand austauschen zu können. Entsprechend ist für die Prozesse alles irrelevant, was nur kurzzeitige Bedeutung hat. Vielmehr sind diese so zu modellieren, dass sie universellen, grundsätzlichen Charakter haben und einen künftigen Bedarf abdecken.

6. Standards für die Evolution

Austauschbarkeit lässt sich konsequent nur realisieren, wenn IT-Verantwortliche sich, auch wenn es Mehraufwand bedeutet, an international anerkannte Standards halten. Nicht gemeint sind damit firmenspezifische Spezifikationen. Die wichtigsten unabhängigen Standards im Prozess-Management sind: XML und BPEL zur Beschreibung von Business-Prozessen in einer allgemein gültigen Notation, WSDL zur Beschreibung von SOA-Funktionen und deren Ort, XSD für die Beschreibung von Datenschemas, WS-Security als Architektur für SOA-Sicherheit, SOAP zur Beschreibung von SOA-Anfragen und Antworten sowie Xpath als Query-Sprache für XML-Datenmodelle.

7. Open Source gegen proprietäre Fallen

In allen IT-Lösungen, auch in herstellerspezifischen quelloffenen Systemen, lauern Fallen, deren Ergebnis eine Abhängigkeit von einem Anbieter wäre. Das kann den evolutionären Wandel der Infrastruktur sehr aufwändig machen kann. Vergleichen lässt sich das Problem mit den Unterschieden zwischen Unix-Derivaten, die trotz vieler Standards einen Wechsel zwischen Herstellern erschweren. Open-Source-basierende Lösungen haben den Vorteil, dass sich solche Punkte von erfahrenen BPM-Praktikern identifizieren lassen.

8. Eindeutig definieren und beschreiben

Die Basisdienste müssen klar definiert sein. Die Anwendungs-Programmier-Schnittstellen (APIs) sind sauber zu dokumentieren. Unterschiedliche Datenmodellierungen, etwa in Folge divergierender Beschreibungen einer Entität – beispielsweise eines Kunden – in verschiedenen Fachabteilungen, gilt es zu verhindern, weil sie aufwändige Transformationen notwendig machen. Starke Bindungen, in denen ein Dienst einen anderen voraussetzt, sind nicht immer auszuschließen, sollten aber auf ein Minimum reduziert werden. Technologieübergänge werden durch die Integration von Legacy-Systemen und Ähnlichem zwangsläufig auftreten. Bei SOA-inhärenter Technik, etwa in Form von Schema-Transformationen, sind sie zu vermeiden.

9. Von der Pilotinstallation bis zum Post-Deployment planen

Bei der Einführung eines so stark mit den Fachabteilungen verzahnten Systems ist von Anfang an mit vielen Korrekturen und Änderungen zu rechnen. Die Qualitätssicherung der Prozessdefinitionen ist in der Regel langwieriger als bei üblichen Softwarekomponenten und muss realistisch geplant werden. Änderungen lassen sich durch eine gut geplante Pilotphase reduzieren. Um Änderungen effizient zu verarbeiten, ist es notwendig, vorab spezielle Tools zum Fehler- und Change-Management zu implementieren.

10. An morgen denken

Prozess- und Software-Updates sind bei Prozess-Management-Systemen aufwändiger als bei anderen Unternehmensanwendungen. Denn bestehende Prozessinstanzen lassen sich oft nur mit größerem Aufwand auf eine neue Prozessversion migrieren. Unabhängig von der verwendeten technischen Infrastruktur muss das Design dem System auf jeder Ebene eine Zukunft von zehn Jahren und mehr eröffnen. Dazu sollte man mögliche Perspektiven für die Entwicklung des Anwenderunternehmens, seines gesellschaftlichen Umfelds (zum Beispiel in der Gesetzgebung) sowie des technischen Fortschritts in der Informations- und Kommunikationstechnik in Betracht ziehen.

Im it-sa Security-Newsletter Nr. 8 vom 17.09.2009 wurde ein Artikel unseres Kollegen Christian Kuester zum Thema “Android Sicherheitsmodell” veröffentlicht. Er erläutert, inwiefern sich das Sicherheitskonzept der Android-Plattform von denen anderer Mobile-Hersteller unterscheidet und wie die technischen Grundlagen aussehen. Den ganzen Artikel finden Sie unter diesem Link www.it-sa.de.

Die FrOSCon ist nun seit 10 Tagen vorbei, Zeit für ein Fazit:

Wir hatten auch in diesem Jahr wieder eine tolle Veranstaltung! Unser Stand, direkt am Eingang, wurde von jedem gesehen, der die Veranstaltung durch den Haupteingang betrat. Wie im vergangenen Jahr, waren wieder die Roboter unseres Freedroidz-Projektes mit dabei, die für viel Aufmerksamkeit und Spaß bei Besuchern und Beteiligten gleichermassen sorgten. Einige findige Kollegen funktionierten ihre Roboter schnell zu Boten um. Auf diese Weise konnten sie unsere mitgebrachten Kaubonbons bequem gegen Gummibärchen u. a. von den Nachbarständen tauschen.

In diesem Jahr waren unsere Mitarbeiter auch wieder zahlreich im Vortragsprogramm vertreten. Ob Jens Neumaier und Elmar Geese etwas zu “Identity und Access Management” erzählten, Patrick Cornelißen über “Portlet 2.0 Entwicklung” sprach oder Christian Küster zu “Android Security” referierte, die Vorträge waren gut besucht und wurden allgemein gelobt. Unterschlagen wollen wir auch nicht “Understanding and fixing cross-compilation requirements” von Robert Schuster, “Open Source Projekte starten und am Leben halten” wieder von Patrick Cornelißen und “Freie Software und SaaS (Software as a Service)” von mir.

Natürlich nutzten wir die FrOSCon auch wieder, um alte Bekanntschaften zu erneuern und neue Kontakte zu knüpfen. Wir stellten wieder einmal fest, dass sich Sankt Augustin während der Veranstaltung zu einem echten Community-Treffpunkt entwickelt hat.

Nicht zuletzt waren wir wieder auf der Suche nach motivierten und qualifizierten Menschen, die unser Team verstärken wollen. Auch in dieser Hinsicht wurden unsere Erwartungen voll erfüllt und wir freuen uns über und auf eine ganze Reihe neuer Kolleginnen und Kollegen.

Bis nächstes Jahr auf der FrOSCon 2010!