Das Grundproblem der polizeilichen IT-Entwicklung

3. Juni 2013 | Von | Kategorie: POLYGON TECHNOLOGIE UND PRODUKTE

Seit Jahren kämpft die Führung in den Polizeibehörden von Bund und Ländern um eine Standardisierung der IT-Werkzeuge und schrittweise erzielt man Erfolge.
Die Datenhaltungssysteme sind inzwischen standardisiert, bei den Vorgangsbearbeitungssystemen haben sich zumindest einige Lager gebildet in den Bundesländern. Auch das Thema „Fallbearbeitung“ ist durch und auch da gibt es zwei mehr oder minder große Lager. Auf der Landkarte erkennt man das Ergebnis: Einen bunten Flickenteppich von IT-Systemen, die – wenn überhaupt – mehr schlecht als Recht Informationen miteinander austauschen können. Und auch den Fachanwender machen sie nicht rundum glücklich. Denn wirklich spezifische fachliche Unterstützung kann nicht erwartet werden von Vorgangsbearbeitungssystemen, die für die Bearbeitung von Massenvorgängen beschafft wurden. Und Fallbearbeitungssysteme verfolgen doch eher den Ansatz des „Universal-Werkzeugs“, das vor allem die Anforderungen von 80% der Anwender erfüllt.
Reichmann_Schären_komp

… und das Dilemma der fachlichen Anforderungen

Die Anwender, die zu den restlichen 20% gehören und deren fachspezifischen Anforderungen nicht berücksichtigt wurden, sind nicht gerade glücklich Sie arbeiten z.B. im Staatsschutz oder sind zuständig für die Rocker-Kriminalität. Oder gehören zu den wenigen hundert Kriminaltechnikern im Lande. „No Way!“, tönt es aus dem Ministerium, wenn wieder mal die Forderung nach fachspezifischer Unterstützung kommt: „So unterschiedlich können die fachlichen Anforderungen doch gar nicht sein!“ „Standardisieren Sie endlich Ihre Prozesse“ bzw. „Individuelle Entwicklungen sind nicht zu finanzieren!“ [Das letzte Argument ist umso nachvollziehbarer, wenn man marktübliche Softwarepreise kennt …!]

Der Standpunkt der Entscheider ist ja auch nicht von der Hand zu weisen: Bei jeder weiteren Tagung auf Bund-Länder-Ebene, haben sie die oben schon erwähnten Flickenteppiche erneut vor Augen. Wenn es bisher schon solche Mühen macht, polizeiliche IT-Systeme zum Informationsaustausch zu bewegen, wäre es doch völlig kontraproduktiv, noch weitere Informationsinseln zu schaffen – so lautet die gängige Auffassung. Auch vom Zentraldienst für Technik kommt hinhaltender Widerstand. Verständlich aus deren Sicht: Denn sie haben leidvoll erlebt, dass jedes neue System, das sie bisher beschafft haben, einen Rattenschwanz an Logistik und Folgeaufwand nach sich zog. Und nicht zuletzt fürchten sie – ebenso verständlich – die zunehmende Komplexität.

Es waren genau diese beschriebenen Probleme und Aufgaben, …

die uns zur Entwicklung von POLYS und den POLYS-Fachanwendungen veranlasst haben. Doch worin bestanden die Probleme bzw. Aufgaben eigentlich?! Was also musste vermieden werden?!

Notwendigkeit 1: Das generische Datenmodell

Unabdingbar war ein Datenmodell, das jegliche Information aufnimmt, ohne dass es aufgabenspezfiisch geändert bzw. angepasst werden muss. Das hatten wir schon! Denn der Kern von POLYGON ist „das generische Datenmodell“. Eine Datenbank mit dieser Tabellenstruktur kann Information von jeder Bedeutung und jeglicher Struktur (also Verknüpfung zwischen den Informationen) aufnehmen und außerdem beliebige Texte, Bilder, und sonstige „Dokumente“. Das generische Datenmodell von POLYGON ist übrigens patentiert. Und da Patente bekanntlich offengelegt werden, kann jedermann – und jeder Betreiber – genau nachlesen, wie das alles funktioniert. Was wiederum die Abhängigkeit vom Hersteller reduziert, die mitunter so dramatisch beklagt wird. [Nur am Rande sei übrigens erwähnt, das auch Inpol-Fall und Crime nach Darstellung der Bundesregierung mit dem generischen Datenmodell arbeiten – doch eine Vertiefung dieses Themas würde hier zu weit führen.] Der Nutzen des generischen Datenmodells ist: Nie wieder Aufwand für Entwicklungs- und Anpassungskosten für Tabellenstruktur und Programme, die auf diese Tabellenstruktur zugreifen!

Notwendigkeit 2: Das harmonisierte Informationsmodell

Ferner notwendig ist ein harmonisiertes Informationsmodell für den polizeilichen Einsatz. Darin ist festgelegt, welche „Art von Informationen“ in einem generischen Datenmodell gespeichert werden können. Dazu zählen z.B. die „Objekttypen“: Das sind für den kriminalistischen Einsatzbereich Personen, Firmen und Organisationen, Adressen, TK-Anschlüsse, und die diversen Sachen, die eben bei Ermittlungen eine Rolle spielen. „Harmonisiert“ heißt, dass alle Programme („Fachanwendungen“), die diese Datenbank nutzen, das gleiche Informationsmodell nutzen sollten. Was die praktische Auswirkung hat, dass Informationen über eine Person, die als „Gewalttäter Sport“ in einer Anwendung erfasst wurde, mühelos weitergegeben werden können an die Kollegen aus dem Staatsschutz oder Rocker-Bereich. Zumindest in POLYGON: Denn alle arbeiten mit dem gleichen harmonisierten POLYGON-Informationsmodell Polizei.
Und damit entfällt ein zweiter großer Block, der sonst hohe Kosten verursacht: Die spezifische Entwicklung eines solchen Informationsmodells. [Nur am Rande sei erwähnt, dass das POLYGON-Informationsmodell Polizei kompatibel ist zum Informationsmodell von Inpol-Fall bzw. IMPII (genau, dem Informationsmodell-Polizei, das den neuen Bund-Länder-Anwendungen zugrunde liegen wird. Sodass Informationen aus POLYGON problemlos weitergegeben werden kann / bzw. ausgetauscht werden können mit Informationssystemen, die Inpol-Fall oder IMP verwenden. Auch das ist in der Praxis längst erwiesen …]

Notwendigkeit Nr. 3: Keine (!) „Programmierung“ der Fachanwendung …

Keine ganz einfache Aufgabe, denn woher sollen Programmfunktionen kommen, wenn man sie nicht „programmiert“?! Ein Blick über den Zaun brachte uns auf die richtige Idee: Denn auch die Web-Browser, wie z.B. Internet Explorer oder Firefox, zeigen beliebige Informationen (von der Webseite, die man aktuell aufgerufen hat), ohne dass der Browser irgendetwas „weiß“ über die Art oder Struktur dieser Information. Und daraus entstand die Idee von POLYS als einem Datenbank-Browser. Es war also notwendig, die Definition von Programmfunktionen und -darstellung zu entkoppeln vom eigentlichen Browser. Dazu haben wir in der POLYGON-Datenbank Speicher (so genannte Repositories) eingerichtet und dort in einfachen Listen hinterlegt, wie die Masken und Felder, Bäume und Reports aussehen und sich verhalten sollen, die der Anwender sieht.
Die Aufgabe von POLYS, dem Datenbank-Browser ist es, nach dem Logon bei der POLYGON-Datenbank und dem Aufruf einer Fachanwendung zu „lesen“ was im entsprechenden Anwendungsspeicher steht und eine entsprechende Bedienoberfläche zu präsentieren.
POLYS und die Fachanwendungen sind nunmehr seit mehreren Jahren im Einsatz und haben die Erwartungen bestätigt, die wir mit der Entwicklung verbunden hatten: Die „Entwicklungszeit“ für neue Fachanwendungen beträgt ein Bruchteil der konventionellen Entwicklung. Ein und dieselbe Komponente, z.B. die Maske zur Erfassung von Personen-Informationen, ist in diversen Fachanwendungen verwendbar. Das freut den Techniker, der auf Modularität und Wiederverwendbarkeit achtet, es reduziert die Entwicklungszeit und erhöht die Qualität: Denn sollte ein Fehler auftreten, so wird er an einer zentralen Stelle repariert. Und auch für den zentralen IT-Dienstleister hat das Verfahren große Vorteile: Denn es minimiert den Software-Verteilaufwand ganz beträchtlich: Solange die aktuelle Version von POLYS auf dem PC eines Nutzers irgendwo im Land ist, wird der auch mit seiner aktuellen Fachanwendung arbeiten können. Die wiederum wird zentral am Server eingespielt und kann somit auch nach Neuentwicklungen bzw. Erweiterungen und natürlich auch nach Fehlerkorrekturen kurzfristig und zeitnah an jedem Arbeitsplatz im Land wieder genutzt werden.

Die Frage der Kosten

Für POLYS musste das Land Brandenburg nichts investieren. Das Recht zur Nutzung auf beleibig vielen Arbeitsplätzen in der Polizei des Landes ist Teil der „Polygon-Landeslizenz“. Eine Reihe von Fachanwendungen, darunter insbesondere auch die SABAA-Fallbearbeitung, wurde ebenfalls ohne Kosten für das Land zur Verfügung gestellt. Und die Kosten für andere, seitdem von Brandenburg erworbene Fachanwendungen, wie z.B. AD Rocker oder AD KFZ, beliefen sich – einschließlich Schulung – auf die Größenordnung eines kleinen Mittelklassefahrzeugs.

Was noch zu tun bliebe …

Eine Kleinigkeit bleibt aber, die wirklich verbessert werden könnte. Denn unsere Firma bietet schon seit Jahren, fast schon wie „sauer Bier“ an, dass Kleinigkeiten am Repository vom Betreiber selbst geändert werden können.. Zu denken wäre da an Kataloge, wie den neuen Dienststellenkatalog nach der letzten Strukturreform. Dazu wäre ein wenig Schulung und die Verfügbarkeit von ein bis zwei Mitarbeitern in der fachlichen Systemadministration, die solche Arbeiten ab und an miterledigen könnten. Das wäre es dann, was das Land vollkommen autoark machte vom Hersteller und was den Wunschvorstellungen so mancher strategischer Denker doch eigentlich ziemlich nahe käme.

.

Kommentare sind geschlossen