Ausgangslage

Management und Marketingabteilung unseres Kunden beklagten sich, dass von der Idee für ein neues Finanzprodukt bis zu seiner Markteinführung viel zu viel Zeit verstreicht, und so der Markt zu spät bedient wird. Die Informatikentwicklungsabteilung machte hingegen geltend, dass neue Produkte nur vage spezifiziert würden und dadurch nur schleppend umzusetzen seien.

Eine Untersuchung zeigte, dass die Informatikabteilung ihre Systeme recht zügig zu ändern oder zu erweitern vermochte, wenn die Spezifikationen einmal präzise und detailliert genug war. Die Fachverantwortlichen wollten ihr Produkt nicht von der Informatik bestimmt haben, und die Informatiker schätzten es nicht, wenn die Fachspezialisten die Informatiklösungen vorwegnahmen. Durch stetigen Personalwechsel hatten die Fachabteilungen viel Wissen über ihre eigenen Produkte eingebüsst.

Eine gemeinsame Sprache für die Erarbeitung und Kommunikation von Anforderungen fehlte.

Lösung

Paranor schlug eine mehrstufige, modellgetriebene Spezifikationsarchitektur (Model-driven Architecture, MDA) vor, bei der drei Modellebenen mit unterschiedlichem Fokus und Inhalt erstellt und gepflegt werden: Geschäftsmodell; System- und Organisationsmodell; Designmodell.

Dem Product Manager wurde als Instrument eine Methode und eine eigene Sprache für die Geschäftsmodellierung in die Hand gegeben, mit denen er Produkte auf rein fachlicher Ebene beschreiben konnte. Seine Spezifikation war als strukturiertes Modell abgelegt.

Für die Informatik wurden eine Methode und zwei Sprachen für die Spezifikation resp. das Design ihrer Systeme geschaffen, welche auf die Geschäftsmodellierung abgestimmt waren und mit dieser ohne Medienbrüche kollaborierten. Systemspezifikation und Systemdesign wurden je als strukturierte Modelle abgelegt.

Dadurch wurde eine zusammenhängende Dokumentation von Geschäft und IT aufgebaut, welche am unteren Ende Quelle für Code-Generierung ist. Durch Validierung konnte sichergestellt werden, dass die erstellten Modelle den Mindestanforderungen genügten und ihre Inhalte kohärent waren.

Realisierung

Alle Modelle waren sog. Domain-specific Languages — im Jahre 2005 noch auf Basis von UML2 massgeschneiderte Sprachen für den jeweiligen Zweck. Alle Modelle hatten grafische wie textuelle Anteile, welche von Benutzer mit Tools aus der Familie des Rational Software Architect erstellt und bearbeitet wurden. Die Sprachen waren über UML-Metamodelle definiert, was automatisierte Validierungen und Transformationen ermöglichte.

Das Geschäftsmodell beschrieb und spezifizierte fachliche Konzepte und atomare fachliche Abläufe als geschäftliche Entitäten und Komponenten. Es war frei von IT-Konzepten und von konkreter organisatorischer Umsetzung. Nur so war es möglich, komplexe Produkte und Dienstleistungen übersichtlich aber dennoch präzise darzustellen und der Informatikabteilung resp. der Organisationsentwicklung ihren Spielraum zu lassen. Die Geschäftsmodellierung kam mit weniger als 20 UML-Stereotypen aus.

Das Systemmodell beschrieb und spezifizierte die firmeninternen und -externen IT-Systeme als Komponenten verschiedener Granularität, welche eine Service-orientierte Architektur (SOA) bildeten. Die Herleitung dieser Komponenten war mit dem Geschäftsmodell abgestimmt und Abbildungs¬transformationen waren definiert.

Das Designmodell war genau genommen ein Verbund von Designmodellen — eines pro Systemkomponente resp. Subsystem. Die Designmodelle mussten sich an die Interface-Vorgaben des Systemmodells halten, unterschieden sich aber sonst teilweise stark. Sie bildeten eine strukturierte Quelle für die Generierung von Programmcode.

Die Einführung dieser Modellkette stellte für viele Mitarbeiter eine grosse Herausforderung dar, da damit ein Kulturwandel weg von den oft vagen, in Word und Excel gehaltenen „Spezifikationen“ hin zu präzisen und detaillierten Modell vollzogen wurde. Es zeigte sich, dass der Aufbau einer Methode der einfachere Teil der Aufgabe war und dass mit der Einführung und der Umsetzung der Methode viel Erfahrung und Fingerspitzengefühl aufgebaut werden musste.