Software-Entwicklung Technologie-Kompass

Software-Entwicklung
Technologie-Kompass
Inhalt
2Vorwort
3Kontext
4
Benutzeroberflächen
6Plattform
9Daten
10Integration
12Dokumente
14
Analytics
16Betrieb
2
Vorwort
Die IT ist sehr schnelllebig und wird von vielen neuen Technologietrends bestimmt. Jedes Jahr veröffentlichen zahlreiche Trendforscher ihre Studien.
Zurzeit heissen die prägenden IT-Trends Mobile
Computing, IT-as-a-Service, Big Data, Open Source
und Cloud. Diese Liste liesse sich beliebig verlängern. Eines haben aber alle Trends gemeinsam: Sie
folgen dem Megatrend „immer schneller, günstiger
und sicherer”.
Als ein führendes schweizerisches IT-Dienstleistungsunternehmen fragen wir uns im Rahmen unseres Innovations-Managements regelmässig, wohin die Reise in unserem Markt gehen wird. Dazu
verfassen wir jährlich unseren Technologie-Radar,
in welchem wir für unsere Software-Entwickler und
Systemspezialisten wichtige Technologien, Werkzeuge und Methoden auf ihre Einsatzfähigkeit bewerten,
eine Auswahl treffen und uns gezielt auf diese konzentrieren. Davon profitieren die Applikationen unserer Kunden, indem wir proaktiv und frühzeitig auf
sichtbare Veränderungen reagieren. Gleichzeitig halten wir das technische Know-how unserer Entwickler
auf dem neusten Stand, ohne uns zu verzetteln.
Auf vielseitigen Wunsch stellen wir mit dem Technologie-Kompass eine zusammengefasste Version des
Technologie-Radars zur Verfügung. Darin gehen wir
weniger auf einzelne Technologien und Werkzeuge
ein, sondern beschreiben IT-Trends und Prinzipien für
Entscheidungsträger in der öffentlichen Verwaltung,
die wir als wichtig erachten.
Der Bedag-Technologie-Kompass richtet sich an Entscheidungsträger in der öffentlichen Verwaltung. Er
zeigt und erklärt jährlich aktuelle Entwicklungen und
Trends in den wichtigsten Gebieten der IT. Er gibt einen Ausblick darauf, wie neue Applikationen aussehen werden und auf welche Aspekte bei der Beschaffung Wert gelegt werden sollte.
Erstellt wird der Kompass von den Experten der Bedag auf Basis des internen Innovations-ManagementProzesses der Bedag, dem Technologie-Radar.
Gerne diskutieren wir mit Ihnen unsere Einschätzung
der technologischen Herausforderungen in Ihrem
Kontext.
Daniel Biemann
Ferdinand Hübner
Leiter Software-Entwicklung
Mitglied der Geschäftsleitung
CTO Software-Entwicklung
Kontext
Die Rahmenbedingungen für die IT in der öffentlichen
Verwaltung werden wieder vermehrt vom Stichwort
„Kosten sparen“ geprägt. Viele Kantone stehen unter
hohem finanziellen Druck. Gleichzeitig wachsen die
Ansprüche der Nutzer. Die „Consumerization“ hält
immer mehr Einzug. Dies bedeutet, dass sowohl Mitarbeiterinnen und Mitarbeiter als auch Kunden der
Verwaltung durch die private Benutzererfahrung von
Internet, E-Commerce, Tablet und Smartphone beeinflusst werden und dieselben Ansprüche an die IT
der Verwaltung stellen. Ein wichtiges Stichwort ist
„Mobilität“. Mitarbeiterinnen und Mitarbeiter arbeiten vermehrt nicht nur ausschliesslich im Büro von
neun bis fünf, sondern rund um die Uhr auch unterwegs oder im Home Office. Gleichzeitig möchten Kunden ihre Geschäfte mit der Verwaltung ebenfalls von
einem beliebigen Ort zu einer beliebigen Zeit abwickeln. Nach wie vor sind zahlreiche Prozesse in der
Verwaltung papierbasiert. Die Digitalisierung wird
ohne Zweifel rasant fortschreiten und ist ein wesentliches Mittel, um dem Kostendruck bei gleichzeitig
höherem Arbeitsvolumen durch neue Regulierungen
und wachsende Bevölkerung zu begegnen. Wie in
der Privatwirtschaft werden Wertschöpfungsketten
aufgebrochen und Arbeiten als „Self Service“ an die
Kundschaft zurückgegeben.
3
Der Druck nach höherer Wirtschaftlichkeit, Digitalisierung, Mobilität und Agilität stellt Verwaltungen
vor grosse organisatorische Herausforderungen
und verlangt eine höhere Innovationskraft der Lösungsanbieter. Beschaffer sind heute die Fachabteilungen, während die zentrale IT eine GovernanceRolle übernimmt. Kantone und Gemeinden schliessen
sich zusammen, um gemeinsame Beschaffungen
durchzuführen. Wenige grosse Anbieter werden zahlreichen kleinen Anbietern vorgezogen. Man sucht
vornehmlich Standardlösungen und weniger Individual-Software. Auch wenn Gesetze und Verordnungen aus Datenschutzgründen derzeit noch eine lokale
Datenverarbeitung verlangen, so ist doch absehbar,
dass zentrale und Cloud-basierte Lösungen „aus der
Steckdose“ die selber betriebene Software ablösen
werden.
Die Anpassung der eingesetzten Lösungen an sich
ändernde Gesetze, verbesserte Prozesse oder engere Zusammenarbeit mit Partnern muss schneller
geschehen. Es kann nicht ein Jahr auf den nächsten
Release der Software gewartet werden. Gefordert
sind agilere Entwicklung, zügige Verifikation und eine
laufende Auslieferung (Continuous Delivery).
Benutzeroberflächen
Im Bereich der Benutzeroberflächen wird sich der
für die Anwender sichtbarste Wandel vollziehen: Die
heute noch dominierenden Desktop-Applikationen
(FatClient, RichClient) und die ihnen nachempfundenen Web-Applikationen der ersten Generation werden verschwinden und durch schlanke und moderne
Web-Applikationen ersetzt. Dabei wird nicht nur die
Technologie ausgetauscht, sondern auch die Bedienkonzepte: Die komplexen Masken mit dutzenden
von Feldern, Abkürzungen und Tastaturkürzeln verschwinden. Moderne Applikationen interpretieren die
Eingaben des Benutzers automatisch im Kontext und
fragen nur die wirklich relevanten Informationen ab.
Dadurch verkürzt sich insbesondere die Einarbeitungszeit für neue Mitarbeiter.
Auch die Mobilität hat einen zentralen Stellenwert.
Der Sachbearbeiter wird zwar seine tägliche Arbeit
nach wie vor stationär an einem grossen Bildschirm
mit Tastatur und Maus erledigen, dies wird aber ergänzt durch einen nahtlosen Übergang auf mobile
Geräte. Zu einem Termin mit dem Bürger bringt die
Mitarbeiterin ihr Tablet mit und kann damit auf alle
Informationen zugreifen und diese auch ergänzen.
Auch das Management greift jederzeit von unterwegs
oder aus Sitzungen mit seinem Mobiltelefon auf das
Dashboard mit den aktuellen Kennzahlen zu.
4
Das Entwickeln von nativen Apps für Smartphones
und Tablets ist nicht bezahlbar, da die Mitarbeiter erwarten, den kompletten Funktionsumfang der Applikation auch unterwegs nutzen zu können. Erschwerend kommt hinzu, dass Apps dann für mindestens
zwei Plattformen (iOS und Android) verfügbar sein
müssen. Daher sollen die Fachapplikationen selber
komplett mobile-fähig sein; die technischen Stichwörter dazu sind „mobile first“ und „responsive Design“.
Der Verhinderer von modernen Web-Applikationen
bei Verwaltungen und Unternehmen ist vielfach die
Ausstattung der Clients mit veralteten Browsern.
Wir empfehlen aus Sicherheits- und Kostengründen
dringend, allfällige noch vorhandene alte Internet Explorer auf Version 11 respektive Edge zu aktualisieren. Nicht portable Applikationen, die stark veraltete
Browser voraussetzen, können via Citrix weiterhin
angeboten werden. Die Portabilität zwischen den verschiedenen Browsern (Chrome, Firefox, Safari, Internet Explorer und Edge) ist mittlerweile sehr gut; eine
starke Verbesserung zur Situation in den letzten fünf
Jahren.
5
Beispiel: Suchen
Die Suche in den Applikationen funktioniert neu genau wie eine Internetsuche in Google. Der Anwender gibt die ihm bekannten Informationen einfach alle in natürlicher Sprache in ein Textfeld ein und erhält bereits während der Eingabe die
relevantesten Ergebnisse angezeigt. Warum soll es auch komplexer sein oder länger dauern, in seiner Fachanwendung
nach Informationen zu suchen?
Plattform
Ende der Applikations-Server
Grosse, teure, zentral verwaltete Applikations-Server, wie zum Beispiel Websphere, Weblogic oder auch
JBoss, werden verschwinden. Stattdessen werden
die Applikationen mit eingebundenen Web-Servern
ausgestattet und in (Docker-) Container verpackt.
Damit entfällt der mühsame und fehlerträchtige, oft
manuelle Prozess der Installation der Fachapplikationen in die zentral bereitgestellten ApplikationsServer-Instanzen. Inkompatible Versionen, kleine
Konfigurationsfehler und Unterschiede zwischen den
Produkten der einzelnen Hersteller führen oft zu Verzögerungen von Tagen oder sogar Wochen, bis neue
Applikationen endlich für die Anwender nutzbar sind.
Auch die Update-Planung wird zum Albtraum was
meistens dazu führt, dass veraltete Software auf
veralteten Systemen betrieben wird. Die wiederum
führt zu höheren Kosten und Sicherheitsproblemen.
Die versprochenen Verfügbarkeits-, Skalierungs- und
Spareffekte der zentralen Applikations-Server haben
sich leider nie erfüllt.
Der neue Ansatz ist, Applikationen entweder direkt
als Software-as-a-Service anzubieten oder als Appliances zu betrachten, bei denen der Software-Hersteller einen fertig konfigurierten und bei ihm in genau dieser Konfiguration durchgetesteten Container
an den Betreiber liefert. Der Betreiber führt diesen
dann bloss noch aus, das Management erfolgt durch
den Software-Hersteller.
6
Entwicklung – Open Source statt teure proprietäre
Produkte
Die Entwicklung von Fachapplikationen erfolgt heute weitgehend in und mit Open Source. Dies bedeutet
nicht zwangsläufig, dass die Applikationen auch Open
Source sind. Aber praktisch der gesamte nicht-fachspezifische Code der Applikation besteht aus OpenSource-Bibliotheken. Typischerweise beträgt der
Anteil dieser Bibliotheken am Umfang der Software
mehr als 80 Prozent. Auch alle verwendeten Tools
und die Programmiersprache selbst sind fast komplett Open Source. Die Vorteile für die Entwickler liegen auf der Hand: Geringere Kosten, direkter Zugang
zum Code, um Probleme zu diagnostizieren, eine
breitere Entwicklerbasis und ein oft besserer und
schnellerer Support durch die Community als durch
Hersteller. Behauptete Nachteile von Open Source
Software, zum Beispiel fehlender professioneller
Support, fehlendes Marketing und sehr technische
Dokumentationen, sind für Entwickler nicht relevant.
Im Gegenteil: Sie schätzen den direkten Zugang zu
anderen Entwicklern. Für viele Produkte ist ausserdem durchaus sehr guter professioneller Support von
Drittanbietern verfügbar.
Microsoft ist durch diese Entwicklung unter Druck
geraten und hat daher auch den Grossteil seiner Entwicklungsumgebung als Open Source verfügbar gemacht.
Aus Sicht der Kunden führt diese Entwicklung zu qualitativ besseren Anwendungen und zu tieferen Kosten.
Wir empfehlen, bei der Beschaffung die Verwendung
von Open Source als Bestandteil der Applikationen zu
fordern.
7
Continuous Delivery und Scrum statt zu viel
Konfigurierbarkeit
Gerade bei grossen Projekten im Rahmen von WTOAusschreibungen beobachten wir, dass vermehrt die
Forderung nach Anpassbarkeit der Systeme durch
die Anwender als Kriterien aufgeführt wird. Dies ist
grundsätzlich eine sinnvolle Anforderung, denn eine
qualitativ hochstehende Lösung zeichnet sich auch
durch eine gewisse Flexibilität aus.
Jede Konfigurierbarkeit ist aber unweigerlich mit
einer Steigerung der Komplexität der Software verbunden – sie wird dadurch teurer in Entwicklung
und Wartung sowie aufwändiger zu testen. Wenn
Benutzeroberflächen oder komplexere Prozesse
konfiguriert werden sollen, dann sind auch die Anforderungen an den Benutzer, der die Konfiguration
durchführt, sehr hoch. Diese Konfiguration der Anwendung ist dann ähnlich komplex wie eine gängige
Programmiersprache, nur dass sie schlechter dokumentiert und mit weniger Tooling unterstützt ist.
Diese Komplexität können Anwender respektive Administratoren ohne massive Unterstützung durch den
Lieferanten nicht mehr selbst bewältigen. Dies führt
typischerweise dazu, dass Anpassungen entweder
gar nicht mehr oder nur durch den Lieferanten, der
sie günstiger direkt im Code der Applikation umsetzen könnte, vorgenommen werden.
Die Hauptursachen für den Wunsch nach Konfigurierbarkeit sind:
• Lange Release-Zyklen:
Zwischen einem Änderungswunsch und der Auslieferung in der produktiven Software vergeht zu
viel Zeit. Aufgrund der Erfahrung mit der bisherigen Software und deren langen Release-Zyklen
(ein Jahr und mehr) soll in der neuen Software
alles direkt am laufenden System verändert werden können. Dies ist typischerweise aber nur in
der Anfangsphase möglich, schon bald wird –
aufgrund der fatalen Auswirkungen von Fehlkonfigurationen – die Konfiguration der Applikation
ebenfalls streng reglementiert und verzögert.
Das organisatorische Problem langer ReleaseZyklen kann nicht mit technischen Mitteln gelöst
werden, sondern muss mit einer Umstellung der
gesamten Prozesse hin zu Agilität und Continuous Delivery angegangen werden. Ein wichtiges Element dabei sind komplett automatisierte
Regressionstests, die unbedingt als Teil der Beschaffung betrachtet werden sollen.
•
Unklare Anforderungen:
Die Anforderungen an die Anwendung sind zum
Zeitpunkt der Ausschreibung noch nicht wirklich
klar. Durch eine Forderung nach Konfigurierbarkeit soll die Anwendung dann an die später
identifizierten Anforderungen angepasst werden. Wir empfehlen in diesem Fall, entweder die
Anforderungen vor der Ausschreibung zu klären
oder – was gerade Verwaltungen noch zu wenig
nutzen – ein agiles Vorgehen zu wählen. Agile
Methoden, wie zum Beispiel Scrum, sind für Szenarien optimiert, bei denen die Anforderungen
vorher nicht abschliessend bekannt sind oder im
Projektverlauf noch ändern können. Durch „agile
Verträge“ können diese Methoden auch bei WTOAusschreibungen genutzt werden. Die dabei entstehende Software wird günstiger und besser zu
bedienen sein als die hochkonfigurierbare Alternative.
8
Programmiersprachen
Im Bereich der Sprachen gibt es im Moment zwei vorherrschende Trends:
Polyglotte Programmierung:
Funktionale Programmierung:
Es wird nicht nur eine einzige Programmiersprache für
Die herkömmlichen, imperativen Sprachen wie Java
eine Applikation verwendet, sondern mehrere gleich-
und C# werden zunehmend durch funktionale Sprachen
zeitig. Dabei wir jede Sprache für jene Aufgaben einge-
ergänzt. Diese erlauben einen einfacheren Umgang
setzt, wozu sie am besten geeignet ist. So werden zum
mit Mehrprozessorsystemen und vermindern das Ri-
Beispiel komplexe Backends in einer typisierten Spra-
siko unerwünschter Seiteneffekte. Beispiele für solche
che wie Java geschrieben, statistische Analysefunktio-
Sprachen sind Scala (für die Java-Plattform), F# (für die
nen in R und die Benutzeroberfläche mit Javascript.
.NET-Plattform) oder Haskell.
Beide Entwicklungen fordern ein Umdenken von den
Entwicklern. Es reicht nicht länger, nur eine einzige
Sprache zu beherrschen.
Aus Sicht der Beschaffer soll auf die Einschränkung
des Lieferanten bezüglich Implementierungsdetails
wie eingesetzte Programmiersprachen und verwen-
deter Frameworks verzichtet werden. Die Anforderungen sollen stattdessen auf Ebene der gewünschten Zielplattform (zum Beispiel Linux, Windows,
Datenbanken, Cloud) und der Schnittstellen/Interoperabilität (REST, SOAP-Web-Services, Messaging)
definiert werden.
Daten
Flexibilität durch ereignisbasierte Systeme
Die Entwicklung geht stark in die Richtung ereignisbasierter Systeme (Stichwort „unified log processing“).
Im Fokus steht dabei, anstatt wie üblich die „statische“ Datenhaltung in der Applikation (zum Beispiel
Attribute einer Person wie Name, Adresse oder die
Daten zu einer Bestellung), die Sammlung der Ereignisse, die zu den betreffenden Daten geführt haben.
In den Beispielen wären das Geburt, Umzug oder „Bestellung abschliessen“. Die unternehmens- respektive verwaltungsweit zusammengeführte Kette dieser
Ereignisse bildet nun die Kerndaten der Unternehmung. Die klassische Entitäten-/Attributesicht, wie
sie in relationalen Datenbanksystemen wie Microsoft
SQL Server oder Oracle gespeichert wird, bildet nur
noch eine von mehreren möglichen Sichten auf diese
Ereignisse.
Diese Architektur bietet klare Vorteile:
• ganzheitliche Sicht auf das Geschäft
• Echtzeit-Reports und Dashboards für das Management - ermöglicht kürzere Reaktionszeiten
• weniger Schnittstellen zwischen den Systemen erhöht die Stabilität und senkt die Kosten
• neue Systeme und Logiken sind auch auf die Vergangenheit anwendbar, aus den gespeicherten
Ereignissen können neue Daten erzeugt werden
Eingesetzt werden die ereignisbasierten Systeme bisher vor allem von grossen eCommerce-Firmen wie
Amazon, die damit bessere Einsicht in das Verhalten
der Kunden und deren Bedürfnisse bekommen. Zen-
9
tral ist die Fähigkeit, neue Analysen wie „was führt
zu Bestellabbrüchen?“ jederzeit auch über bereits
getätigte respektive abgebrochene Bestellungen zu
generieren.
Relationale Datenbanken als Commodity
Im Bereich der relationalen Datenbanken zeichnet
sich ein Wechsel weg von den teuren Produkten wie
Oracle, Microsoft SQL Server oder DB2 hin zu OpenSource-Datenbanken wie PostgreSQL ab. Diese stehen den kommerziellen Produkten weder in Bezug
auf Funktionalität noch auf Stabilität in Nichts nach,
haben aber tiefere TCO (Total Cost of Ownership).
Die relationale Datenbank ist komplett zur Commodity geworden. Die Produkte können sich nicht mehr
durch Features positionieren, sondern sind komplett
austauschbar. Für die modernen Fachapplikationen
spielt es keine Rolle mehr, auf welchem Produkt ihre
Datenbank betrieben wird.
Die Ursache dieser Entwicklung liegt vor allem in
den grossen Investitionen, die Firmen wie Facebook,
Amazon und Yahoo in die Open-Source-Datenbanken
PostgreSQL und MySQL getätigt haben. Für diese
Grossfirmen mit ihren hunderttausenden von Servern war es wirtschaftlicher, in die freien Produkte
zu investieren, als die teuren Lizenzen an Oracle abzuführen. Gerade in Bezug auf die Skalierbarkeit für
ganz grosse Datenmengen und Zugriffszahlen haben
die Open-Source-Produkte die kommerziellen Lösungen daher schon hinter sich gelassen.
10
Integration
Microservices – agilere IT
Das Trendwort im Bereich der Plattformen ist Microservices. Anstatt als grosse, voll integrierte Applikationsmonolithen werden die Lösungen aus kleinen,
in sich kompletten Diensten aufgebaut. Jeder Dienst
ist dabei für genau eine klar abgegrenzte Geschäftsfunktion zuständig und hat seinen eigenen Lebenszyklus. Etwas vereinfacht gesagt, entspricht ein Microservice einer App auf einem Smartphone, nur eben
auf Server-Seite. Jede solche „App“ erfüllt genau einen Zweck (zum Beispiel WhatsApp, um Sofortnachrichten auszutauschen, oder Expensify, um Spesen
zu erfassen).
Microservices erinnern an die mittlerweile etablierte
Service-orientierte Architektur (SOA), wobei der Begriff SOA mittlerweile vor allem durch Tool-Hersteller
so aufgeweicht worden ist, dass eine klare Einordnung schwer fällt. Die relevantesten Abgrenzungen
zwischen Microservices und SOA sind aber folgende:
• Schlaue Endpunkte statt Enterprise Service Bus
(ESB): In einer klassischen SOA wird oft versucht,
die Komplexität in einem zentralen ESB zu verstecken. Auf Microservice basierte Architekturen
verzichten bewusst darauf und setzen auf Informationsaustausch auf der Basis einfacher Protokolle (meist REST) über simple Übertragungswege (dump pipes).
Aus organisatorischer Sicht vermindern Microservices die „Diseconomies of scale“ bei der SoftwareEntwicklung. In der Software-Entwicklung gilt der
Grundsatz, dass, je grösser die entwickelte Applikation, desto weniger effizient wird die Entwicklung
erfolgen. Die notwendige Kommunikation und Koordination zwischen den Entwicklern und die negativen
Auswirkungen von Fehlern in der Architektur oder bei
den Anforderungen führen dazu, dass jeder zusätzliche Entwickler immer weniger Ergebnisse produziert. Die optimale Grösse einer Applikation ist, wenn
sie von ungefähr sieben Entwicklern erstellt werden
kann.
•
Mit dem Microservice-Ansatz wird die vormals grosse Applikation in voneinander weitgehend unabhängige Dienste aufgeteilt, für die jeweils ein kleines, hochproduktives Team zuständig ist.
Dezentrale Verwaltung: Jeder Microservice wird
von einem eigenständigen Team mit einem eigenen Release-Prozess gepflegt. Damit wird der
Koordinationsaufwand massiv verringert. Auch
die Release-Zyklen werden so auf Tage bis wenige
Wochen verringert. Allerdings muss stattdessen
mehr Aufwand in den Test und in die Rückwärtskompatibilität der Dienste investiert werden.
• Dezentrale Daten: Die Daten werden pro Microservice isoliert gehalten, das heisst es ist kein
direkter Datenzugriff über die Service-Grenzen
möglich. Jeder Dienst hat seine eigene Datenbank.
• Kleinere Granularität: Microservices haben typischerweise einen kleineren (Funktions-)Umfang
als ein Service im Sinne von SOA.
Getrieben werden die Microservice-Architekturen von
der Notwendigkeit, von den langen, trägen Release-
11
Prozessen mit ein bis zwei Releases pro Jahr und
einem Vorlauf für neue Funktionen von bis zu einem
Jahr wegzukommen. Weder Unternehmen noch Verwaltungen können es sich heute leisten, derart lange
auf neue, wichtige Geschäftsfunktionen zu warten.
Aus Sicht einer Verwaltung soll darauf geachtet werden, dass nicht grosse, monolithische Systeme erstellt beziehungsweise beschafft werden, sondern
auf eine modulare Architektur gesetzt wird.
API – eGovernment effizienter und günstiger
Das Problem der meisten existierenden eGovernment-Lösungen ist, dass sie entweder für den einzelnen Bürger oder aber für grössere Unternehmen
ausgelegt sind. Angebote für den Bürger haben eine
einfach zu bedienende Benutzeroberfläche, sind aber
für die Erfassung grösserer Datenmengen nicht geeignet. Ein Beispiel hierfür sind die Web-Lösungen
der Strassenverkehrsämter: Für grosse Transportunternehmen sind diese unpraktisch, da sie sich nicht
in ihre Systeme integrieren lassen. Dem gegenüber
stehen Lösungen, die explizit für Unternehmen konzipiert wurden. Diese lassen sich sehr gut integrieren
und bieten zusätzliche Funktionen, allerdings zum
Preis von komplizierten Schnittstellen und komplexen Einrichtungsprozessen. Oft muss zuerst Software zertifiziert und es müssen Vereinbarungen geschlossen werden, bevor die Dienste genutzt werden
können.
Als Lösungskonzept zur Überbrückung dieses Gaps
eignen sich öffentliche API (Application Programming
Interface): Die Verwaltungssysteme veröffentlichen
all ihre Geschäftsfunktionen als vom Internet her zugängliche technische Dienste („Web Services“) und
zwar unabhängig von konkreten Verwendungsszenarien. Der Zugriff wird selbstverständlich geschützt,
so dass jeder Bürger und jedes Unternehmen nur
auf seine Daten zugreifen kann. Alle Dienste werden
dokumentiert und mit Beispielen versehen. Optimalerweise werden genau dieselben Dienste auch intern
– also vom Amt selbst oder von anderen Ämtern –
ebenfalls verwendet. Technologisch handelt es sich
typischerweise um REST-Services (siehe unten).
Das API-Konzept ermöglicht nun die folgenden beispielhaften Verwendungen:
• Ein innovativer Softwarehersteller entwickelt
eine iPhone App mit der ein Bürger seine Autos
verwaltet und diese auch gleich zur Prüfung anmelden kann.
• Ein grosses Transportunternehmen erweitert
sein ERP-System so, dass die Daten direkt mit
denen des Strassenverkehrsamts abgeglichen
und Prüfungstermine vollautomatisch vereinbart
werden.
• Eine kleine Garage mit technischem Flair erweitert ihre Fahrzeugverwaltung um ein kleines Modul, das das Anmelden von Autos direkt aus der
Applikation heraus ermöglicht.
• Ein Software-as-a-Service-Angebot für Fahrschulen ermöglicht Fahrlehrern und Fahrschülern, direkt Prüfungstermine zu vereinbaren.
All diese Angebote verwenden die identischen
Schnittstellen des Amts, ohne das ein zusätzlicher
Verwaltungs- oder Implementierungsaufwand für
den Staat entsteht.
sedex mit eCH-Standards
Für den privaten Meldungsaustausch zwischen Behörden wird sich sedex noch weiter etablieren. sedex
bietet eine sichere und zuverlässige Plattform zum
Austausch von Meldungen zwischen Organisationen.
Trotz der technisch einfach ausgelegten Schnittstelle
auf Dateisystemebene und der damit verbundenen etwas schwerfälligen Handhabung sowie des begrenzten Meldungsdurchsatzes, ist es der einfachste und
zuverlässigste Weg. Als Format für die ausgetauschten Meldungen werden in fast allen Fällen Standards
des Vereins eCH verwendet. sedex Pathfinders erweitert sedex zusätzlich um eine Möglichkeit zur synchronen Kommunikation mittels Web Services.
Innerhalb einer Organisationseinheit – zum Beispiel
eines Amts – sollte sedex nicht verwendet werden.
Es empfiehlt sich ausserdem, sedex nicht direkt an
die Applikationen anzubinden, sondern die Anbindung
zentral via ein Messaging-System vorzunehmen, da
sonst der Integrationsauswand mehrfach anfällt.
Dokumente
Dokumente – verborgene Daten
Immer wenn Mitarbeiterinnen und Mitarbeiter routinemässig gleichartige Dokumente manuell verfassen, verschwinden dabei aus Sicht der Organisation
Daten aus dem Nutzbereich. Mithilfe teurer und für
die Anwender oft umständlicher Document Management Systeme (DMS) wird dann versucht, wenigstens
einen Teil dieser Daten wieder nutzbar zu machen
und eine Art Versionskontrolle sicherzustellen. Ebenfalls viel Geld kostet es, diese Dokumente immer wieder für neue Versionen von Microsoft Office lesbar zu
machen.
Viel einfacher und zielführender ist, die Informationen von Beginn weg in einer mindestens halbstrukturierten Form zu erfassen und damit maschinenlesbar, -suchbar und -auswertbar zu machen. Sinnvolle
Ansätze dazu sind die Integration in eine Fachlösung
oder die Nutzung spezialisierter Systeme, die den Benutzer bei der Erfassung der Daten unterstützen. Als
Endprodukt kann dabei immer noch ein Blatt Papier
entstehen. Allerdings ist dieses dann aus den Daten
generiert und nicht der primäre Datenträger. Zusätzlich ist es so auch möglich, die Daten direkt elektronisch zu verarbeiten. Der Kunde könnte zum Beispiel
seine Veranlagungsverfügung direkt wieder in seine
Steuer-Software einlesen.
Ablösen von internen Antragsformularen
Ein sehr einfach erreichbare Verbesserung, eine sogenannte low-hanging fruit, ist, die internen Abläufe
zwischen mehreren Stellen, wie zum Beispiel ein Personaleintritt oder das Beantragen von Berechtigungen,
statt via E-Mail versandte Word-Dokumente in einem
Vorgangsverfolgungssystem wie Atlassian JIRA abzubilden. Die Angaben werden strukturiert erfasst und
können trotzdem noch mit speziellen Bemerkungen
ergänzt werden. Auswertungen über die Bearbeitungszeit, Engpässe und Art der Anfragen können einfach direkt vom Manager selber erstellt werden.
12
Formulare – immer noch wie auf dem Papier?
Elektronische Formulare werden vielfach stiefmütterlich behandelt. Ihre Möglichkeiten werden schlecht
genutzt. Die folgenden Schwachstellen sind häufig:
• Keine Anbindung an die Systeme: Nach der erfolgten Erfassung entsteht ein Medienbruch. Die
Daten werden per E-Mail übermittelt oder sogar
ausgedruckt und nicht direkt in das zuständige
System (Ticketing, Fall-Management oder sonstige Fachapplikationen) überführt.
• Schlechte Benutzerführung: Elektronische Formulare eignen sich optimal, um den Benutzer
bei der Erfassung der Daten anzuleiten und zu
führen. Im Kontext nicht benötigte Felder sollen
ausgeblendet und die Erfassung auf mehrere
Schritte aufgeteilt werden. Ausserdem sollen erklärende Texte vorhanden sein.
• Verwendung von PDF-Formularen: Diese entsprechen in etwa einem Papierformular, das mit
der Schreibmaschine ausgefüllt wird. Weder wird
der Anwender durch die Erfassung geführt, noch
sind die erfassten Daten automatisch verwertbar.
Was ausserdem oft vergessen geht: Vielfach sind die
Daten beim Anfrager, also beim Bürger oder beim
Unternehmen, bereits in einem System vorhanden.
Dadurch führt alleine das Ausfüllen des Formulars
durch den Anfrager zu einem ersten Medienbruch
und zu potenziellen Fehlern. Zu jedem Formular sollte immer auch ein entsprechender API-Service (vgl.
unter „Integration“) existieren, damit die Daten auch
maschinell eingeliefert werden können.
Eng verbunden mit dem Thema Formulare sind elektronische Signaturen. Diese bestätigen die Integrität
der Daten und identifizieren den Absender. Allerdings
sind sie oft entweder umständlich in der Handhabung
durch die Anwender (Beispiel SuisseID) oder sie genügen den Sicherheitsanforderungen nicht. Viel sinnvoller ist im Kontakt mit Bürgern die Verwendung
eines Login-Verfahrens. Ein Login stellt – genau wie
eine Signatur – die Identität des Absenders fest. Die
13
Integrität der ausgetauschten Daten wird durch das
Verschlüsseln des Transportkanals (meistens mittels
SSL/TLS) ebenfalls sichergestellt. Der Zusatznutzen
einer Signatur liegt darin, zu einem späteren Zeitpunkt dem Absender zweifelsfrei belegen zu können,
dass er diese Daten genauso übermittelt hatte und
nicht das Amt diese verändert hat, was häufig nicht
erforderlich ist.
Digital Divide – nicht alle sind im Internet
Gerade für Verwaltungen ist der Digital Divide eine
grosse Herausforderung. Im Unterschied zu Unternehmen können sie nicht einfach aus Effizienzgründen jene Kunden ohne Zugang zum Internet von ihren
Dienstleistungen ausschliessen. Sie haben die Pflicht,
sämtliche Bürger zu bedienen. Das bedeutet, dass
Papierprozesse weiterhin erhalten bleiben müssen.
Die Effizienz soll aber trotzdem gesteigert werden.
Ein erfolgversprechender Ansatz ist, die kompletten
Prozesse zu digitalisieren, dabei aber darauf zu achten, dass saubere, maschinennutzbare Schnittstellen
definiert werden (Vergleiche hierzu das Kapitel zu
API unter Integration). Auf Basis dieser Schnittstellen
kann an einer zentralen Stelle ein gezielter Übergang
von/zu Papier oder auch mündlicher Kommunikation
erfolgen. Dieser muss weiter gehen, als einfach nur
die Papiere zu scannen, da dies alleine die Daten noch
nicht verwertbar macht. Vielmehr werden die Daten
von einem Datenerfassungsteam zu einem Aufruf der
Standard-API aufbereitet. Allfällige Korrekturen und
Nachfragen werden direkt von dort durchgeführt.
14
Analytics
Entscheidungshilfen statt Reports
An die Stelle fixer vorgefertigter Reports und unflexibler Kennzahlen tritt ein integriertes System,
das die Entscheidungsträger direkt bei ihrer Arbeit
unterstützt. Als Einstieg dient ein übersichtliches
Dashboard mit den wichtigsten Key Performance Indicators. Weitere für die Entscheidungsfindung notwendige Daten lassen sich direkt von dort aus für das
konkrete Szenario zusammenstellen und ad-hoc neu
kombinieren. Die Resultate lassen sich einfach und
optisch ansprechend visualisieren. Diese Arbeiten
werden nicht von einem Spezialisten erledigt, sondern direkt vom Manager oder von der ControllingAbteilung. Die Bedienung ist nicht komplexer als bei
Excel. In einzelnen Bereichen ist dies bereits Realität,
allerdings ist es noch ein weiter Weg, bis sämtliche
Daten der Verwaltung so auswertbar sind.
Als nächster Schritt wird der Blick statt nur in die
Vergangenheit – also der Analyse vergangener Ereignisse – vermehrt auch in die Zukunft gerichtet. Die
Anwendung extrapoliert aus den Daten mithilfe von
Modellen automatisch mögliche Zukunftsszenarien.
Ein Beispiel für eine erste Anwendung solcher Technologien bildet Predictive Policing: Anstatt nur auszuwerten, wo wie viele Einbrüche passiert sind, errechnet das System selbständig, wo in nächster Zeit
vermehrt mit Einbrüchen zu rechnen ist.
Neue Möglichkeiten mit Big Data
Ermöglicht wird dieser Blick in die Zukunft von Technologien, die gemeinhin unter dem Stichwort "Big
Data" zusammengefasst werden. Big Data wird oft
anhand der folgenden Charakteristika definiert:
•
•
•
•
Grosse Datenmenge (Volume): Es werden alle
verfügbaren Daten gesammelt, ohne diese zu filtern.
Echtzeit Verarbeitung (Velocity): Alle Daten sind
sofort verfügbar, sie werden laufend ins System
eingespiesen.
Vielfalt der Formate (Variety): Nicht nur strukturierte Daten werden verarbeitet, sondern auch
Texte, Bilder, Videos, Pläne etc.
Richtigkeit (Veracity): Sind die Daten korrekt und
aussagekräftig? Können daraus die richtigen
Schlussfolgerungen gezogen werden?
Aus diesen gesammelten Daten wird mittels Maschinenlernen und Modellen versucht, neue Schlussfolgerungen zu gewinnen. So werden Prognosen, Simulationen oder Risikobeurteilungen erstellt, um damit
Entscheide mit Fakten zu unterstützen. Einsatzbeispiele für Big Data in der Verwaltung können sein:
• Erkennung von Betrug, zum Beispiel bei der Abrechnung der Mehrwertsteuer. In Belgien wird
dies mit grossem Erfolg bereits eingesetzt.
• Unterstützung beim Prüfen der Steuererklärungen durch eine automatische Risiko- und Komplexitätseinstufung mit vollautomatischer Veranlagung für die Masse weniger komplexer Fälle.
• Besserer Personaleinsatz durch die genauere
Vorhersage über zu erwartende Gesuche und
Anfragen.
• Einbruchsvorhersage (Predictive Policing), wie
bereits oben erwähnt.
15
Technologien für Big Data
Die momentan am häufigsten verwendete Technologie ist Apache Hadoop. Sie bildet die Grundinfrastruktur für den Umgang mit sehr grossen Datenmengen
(Petabytes):
• HDFS (Hadoop File System): Erlaubt, die Daten
persistent auf günstigem Speicher abzulegen.
Die Daten werden mehrfach vorgehalten, so dass
der Ausfall eines Servers nicht zu einem Datenverlust führt. Klassische Storage-Systeme (SAN)
und Backups sind für diese Datenmengen zu teuer. Stattdessen werden Server mit vielen günstigen Harddisks verwendet.
• YARN: Verwaltet die Ressourcen (Speicher- und
Rechenleistung) im viele Server (hunderte bis
tausende) umfassenden Cluster.
• Map/Reduce: die Basis für die hochparallele Verarbeitung von grossen Datenmengen. Jeder Server analysiert „seine“ Daten, die Ergebnisse werden aggregiert.
Basierend auf diesen drei Basisdiensten ist eine Vielzahl weiterer Lösungen entstanden, die zum Beispiel
Abfragen mittels SQL-ähnlicher Sprache ermöglichen
(Apache Hive), aber auch eine hochverfügbare Datenbank (Apache Cassandra), eine Lösung für Machine
Learning (Apache Mahout) oder die Analyse von Datenströmen (Apache Spark). Während zu Beginn täglich oder ad-hoc ausgeführte Batch-Verarbeitungen
im Vordergrund standen, fokussiert die Entwicklung
mittlerweile vor allem auf die Realtime-Analyse von
Daten.
Nicht für alle oben aufgeführten Szenarien ergibt der
Einsatz von Big-Data-Technologien Sinn. Die minimale
Datenmenge für einen sinnvollen Einsatz liegt bei ca.
10 TB zusammen auszuwertender Daten. Für kleinere Datenbestände können die oben aufgeführten Anwendungsfälle mit einfacheren Analysewerkzeugen
deutlich kostengünstiger auf einem einzelnen Server
mit viel Arbeitsspeicher implementiert werden. Auch
in diesem Umfeld entstehen viele Produkte, die den
Big-Data-Technologien in nichts nachstehen, aber
weniger komplex im Betrieb und deutlich schneller
sind. Wir empfehlen daher, die mit Big Data aufkommenden Möglichkeiten zu nutzen, aber zurückhaltend
zu bleiben mit dem Einsatz von Big-Data-Technologien. Erst wenn sich wirklich zeigt, dass die Datenmenge zu gross ist, lohnt es sich, die Mehrkosten und
die Komplexität in Betrieb und Entwicklung in Kauf zu
nehmen.
16
Betrieb
Cloud-Technologien für schnellere Release-Zyklen
Der Übergang in die Cloud ist ein zentrales Thema der
IT geworden und beschäftigt wohl jeden CIO. Häufig
fokussiert die Betrachtung vor allem auf mögliche
Kostensenkungen im Betrieb. Damit werden aber die
eigentlich wichtigeren Aspekte der Cloud-Ansätze
nicht berücksichtigt.
Cloud-Begriffe
•
Infrastructure-as-a-Service (IaaS): Der Kunde be-
Die Cloud-Angebote lassen sich gemäss NIST nach Art
zieht IT-Basiskomponenten wie CPU-Leistung,
der Bereitstellung und Art der Dienstleistung einteilen.
Speicher und Netzwerkbandbreite. Er verwaltet
alles – von der Software bis zu den Betriebssyste-
Dienstleistung:
•
men – selbst.
Software-as-a-Service (SaaS): Der Kunde bezieht
Bereitstellung:
eine komplette Applikation als Dienstleistung. Die-
•
se beinhaltet als Gesamtpaket sowohl Software,
Beispielsweise Amazon AWS oder Microsoft Azure.
Lizenzen, Updates, Betreuung als auch den Betrieb
•
Public Cloud: Offen, für alle im Internet verfügbar.
•
Private Cloud: Exklusiv für eine Verwaltungseinheit
und die Überwachung.
oder ein Unternehmen verfügbare Cloud. Wird ent-
Plattform-as-a-Service (PaaS): Der Kunde bezieht
weder selbst oder vom Betriebspartner betrieben.
eine Umgebung, in die er seine Applikationen ins-
• Hybrid
tallieren kann. Die Plattform stellt dabei Basiskom-
Cloud:
Kombination
unterschiedlicher
Cloud-Angebote; meist public und private.
ponenten (zum Beispiel Datenbank, Applikations-
•
Community Cloud: Steht exklusiv einem Zusam-
server oder Netzwerkspeicher), das Patching und
menschluss von Organisationen zur Verfügung.
Tools zur Überwachung zur Verfügung.
Zum Beispiel eine Schweizer Verwaltungs-Cloud.
Die klassische Cloud-Betrachtung bezieht sich auf
das Beziehen von virtuellen Maschinen und Speicher
aus einer öffentlichen Cloud, wie zum Beispiel Amazon oder Microsoft Azure - Infrastructure-as-a-service oder kurz IaaS. Binnen weniger Minuten können
dort fast beliebig viele Maschinen gestartet werden.
Bezahlt werden sie nur, solange sie auch verwendet
werden. Der ökonomische Hintergrund dieses Geschäftsmodells sind Skaleneffekte durch die enorme
Anzahl gleicher Systeme (pro Anbieter mehr als eine
Million Server) und die sich ausgleichenden Bedarfsspitzen vieler Kunden.
Der Kunde erzielt durch das Verwenden einer IaaSCloud im Wesentlichen zwei Vorteile:
• Geringere Kosten bei stark schwankendem Ressourcenbedarf: Wenn der Verbrauch während
des Jahres sehr stark schwankt, ist das Pay-PerUse-Modell sehr attraktiv. Die Server kosten nur
dann Geld, wenn sie tatsächlich gebraucht werden. Es müssen zwei Voraussetzungen erfüllt
sein, damit diese dynamische Ressourcenanpassung überhaupt möglich ist: Die Applikation muss
damit umgehen können (Cloud-ready sein) und
der Spitzenverbrauch muss so hoch sein, dass
mehrere Server zusätzlich benötigt werden. Ist
die Applikation nicht oder nur mit grossem Aufwand fähig horizontal skaliert zu werden - also
auf mehre Server verteilt zu werden - hilft es
nichts, dass die Basis-Infrastruktur dies könnte.
Ein erheblicher Teil der Applikationen ist heute
noch nicht problemlos horizontal skalierbar. Heute weisen selbst die kleinsten Server-Einheiten
17
schon eine beträchtliche Leistung auf und können
mehrere hundert Benutzer bedienen. Daher gibt
es im Verwaltungsumfeld nur wenig Applikationen, bei denen die dynamische Anpassung an die
aktuelle Last überhaupt Sinn macht. Neben den
reinen Serverkosten müssen auch der Aufwand
und das Risiko einer dynamischen Skalierung in
die Nutzenabwägung miteinbezogen werden.
• Schnellere Installation von Applikationen, direkt
durch den Lieferanten: Die von einer Verwaltung
verwendeten Softwareprodukte sind vielfältig
und ihre Installation oft komplex. Mithilfe einer
geeigneten Private-Cloud-Umgebung kann der
Software-Lieferant diese selbstständig auf der
Infrastruktur des Kunden beziehungsweise seines Betriebspartners installieren. Entweder adhoc oder aber als Virtual Appliance. Dabei muss
darauf geachtet werden, dass der betreffende
Hersteller die notwendige Betriebskompetenz
hat: Monitoring, Patching, Absichern des Servers und Backup müssen durch ihn sichergestellt
werden.
Das Verwenden einer Public Cloud für Anwendungen,
die durchgehend einen stabilen Kapazitätsbedarf haben, lohnt sich bei exakter Kalkulation finanziell nur
selten. Neben den Kosten für die eigentlichen Systeme fallen zusätzlich auch Kosten für Datentransfer,
Speicher und weitere Ressourcen an. Bei einer Private oder Community Cloud steht vor allen der Vorteil
der schnelleren Installation der Applikationen im Vordergrund. Für eine Kosteneinsparung durch Skaleneffekte oder sich ausgleichende Bedarfsspitzen sind
die Umgebungen meist deutlich zu klein, diese fallen
erst ab mehreren Hundert Servern ins Gewicht.
Ein Plattform-as-a-Service Angebot (PaaS) zielt darauf, Applikationen möglichst effizient, schnell und
fehlerfrei installieren (und entwickeln) zu können. Es
werden die Basisdienste, wie zum Beispiel relationale
Datenbank, Messaging-System oder Objekt-Speicher,
standardisiert bereitgestellt, und die Applikationen
werden in einem Standard-Format angeliefert. Neue
Umgebungen können so auf Knopfdruck aufgebaut
werden. Die PaaS-Angebote sind noch sehr vielfältig,
erst mit den Technologien Docker und Kubernetes
beginnt sich langsam ein Standard in diesem Bereich
abzuzeichnen. Eine erfolgreich eingeführte PaaSPlattform ermöglicht, sowohl die Dauer als auch den
Aufwand für den Aufbau und das Update von Systemen massiv zu reduzieren. Die Kostenersparnisse
entstehen durch die Einheitlichkeit der betriebenen
Applikationen. Der grössere Nutzen für das Geschäft
entsteht aber häufig aus dem durch die Automatisierung ermöglichten schnelleren Release-Takt, bis hin
zu einem Continuous Delivery.
Um eine PaaS effizient zu betreiben, ist eine Mindestgrösse in der Grössenordnung von Hunderten von
Servern erforderlich. Ansonsten übersteigen die Aufwände für Aufbau, Verstehen und Aktualisierung der
PaaS die erzielten Skaleneffekte.
Auf der Basis von Docker können viele nicht für PaaS
entwickelte Applikationen durch den Betreiber nachträglich "PaaS-ready" gemacht werden und so die
Vorteile genutzt werden.
Im Rahmen von Software-as-a-Service (Saas) wird
die komplette Applikation – inklusive Betrieb und allfälliger Lizenzen – als Dienstleistung vom Anbieter
bereitgestellt. Bekannte Beispiele dazu sind Salesforce, Dropbox oder Gmail. Durch den Betrieb vieler Instanzen respektive Mandanten der Applikation
durch einen Anbieter entstehen bedeutende Skaleneffekte. Der Anbieter ist häufig gleichzeitig auch
der Software-Hersteller und kann dadurch kürzere
Release-Zyklen und eine schnellere Reaktion bei Betriebs- oder Sicherheitsproblemen bieten. Aus Kundensicht muss aber darauf geachtet werden, dass der
Betrieb professionell erfolgt. Gerade auf Basis der
Public-Cloud-Angebote ist die Versuchung bei Software-Herstellern gross, selber ein SaaS-Angebot zu
"basteln", ohne die dafür notwendigen Kompetenzen
und Erfahrungen im Betrieb zu haben.
18
Unsere Empfehlungen für Verwaltungen
Bereitstellung/Dienstleistung
Software-as-a-Service
Platform-as-a-Service
Infrastructure-as-a-Service
Public Cloud
Nutzen wo verfügbar
Sicherheitsstandards, Zugriff
fremde Staaten berücksichtigen
nur für nicht besonders schützenswerte Daten
nur für Applikationen mit stark
schwankendem RessourcenBedarf und ohne schützenswerte Daten
nur durch ausgebildete System
Engineers
Private/Community Cloud
nutzen wo verfügbar (Community)
nutzen
erst ab min. 100 Servern wirtschaftlich betreibbar (private)
nicht wirtschaftlich
kann sinnvoll sein für Entwicklungsumgebungen
Hybrid Cloud
Kombination mit interner
Software
Komplexität überwiegt Kosteneinsparungen meistens
nicht wirtschaftlich, zu komplex
Open-Source-Technologien als Rückgrat
Im Betrieb gibt es einen klaren Trend zur Verwendung von Open Source Software und Tools. Einerseits
hängt dies damit zusammen, dass sie kostenlos verfügbar sind. Der wirkliche Treiber ist aber, dass diese
Lösungen schlicht besser und moderner sind und die
Anforderungen besser abdecken. Viele dieser Tools
kommen aus dem Umfeld der grossen Internetfirmen
wie Google, Twitter oder Netflix, die diese für den Gebrauch in ihren eigenen Rechenzentren entwickelt
haben und sie öffentlich verfügbar machen.
Das oben bereits erwähnte Kubernetes – die Grundlage eines PaaS – wurde zum Beispiel von Google als
Weiterentwicklung der internen Cloud-Lösung Borg
als Open Source entwickelt.
Auch Red Hat beteiligt sich sehr aktiv an der Entwick
lung und benutzt Kubernetes als Basis für ihr Open ShiftCloud-Produkt. Mittlerweile ist Kubernetes der DeFacto-Standard für Container-PaaS-Lösungen. Eine
analoge Entwicklung hat im Bereich der IaaS-Lösungen bereits stattgefunden: Praktisch alle Angebote
basieren auf der als Open Source verfügbaren OpenStack-Plattform.
Auch für das Monitoring (Nagios, Graphite, InfluxDB
und Prometheus), für das Konfigurations-Management (Puppet, Ansible) und für die Protokollierung
(Logstash, Graylog und Elasticsearch) sind OpenSource-Lösungen die beliebtesten Tools.
19
Sicherheit ist zentral
Gerade im Verwaltungsumfeld verarbeiten die Anwendungen oft heikle Personendaten, welche entsprechend gut geschützt sein müssen. Immer häufiger sollen diese Anwendungen aber auch direkt über
das Internet zugänglich sein, damit die Verwaltung
ihre Aufgaben effizienter erfüllen kann und die Bürger direkten Zugriff auf ihre Daten haben. Auf der
Gegenseite stehen professionelle Angreifer, die nicht
nur mit ausgezeichnetem technischem Know-how,
sondern auch mit entsprechenden Finanzmitteln
ausgestattet sind. Je nach Fachgebiet muss sogar damit gerechnet werden, dass ein anderer Staat gezielt
Angreifer auf gewisse Daten ansetzt.
Klar, dass da auch der Schutz der Applikationen auf
einem ausgezeichneten Niveau sein muss. Die Basis bildet ein sehr guter Grundschutz im Betrieb, der
auch entsprechend zertifiziert ist (ISO-27001). Im Unterschied zu früher reicht es aber nicht länger aus,
sich in der Sicherheitsfrage auf eine optimale Abschottung der Applikationen durch den Betreiber zu
konzentrieren. Durch die Anforderung nach breiterer
Verfügbarkeit der Anwendungen lassen sich diese
nicht mehr abschotten. Mittels Social-EngineeringTechniken machen Angreifer auch Mitarbeiterinnen
und Mitarbeiter der Verwaltungen zu unfreiwilligen
Komplizen und greifen so auch eigentlich gut abgeschottete Applikationen an.
Die Software-Hersteller müssen diese Herausforderung aktiv annehmen und ihre Applikationen von
sich aus auf Sicherheitslücken überprüfen und mit
schneller Bereitstellung von Patches aktiv reagieren. Ein grosser Teil der Applikationen besteht wie
erwähnt aus Code, der nicht vom Hersteller selber
entwickelt wurde, sondern von extern bezogen wird,
meist in Form von Open-Source-Bibliotheken. Oft
sind innert weniger Tage fixfertige "Angriffs-Kits" im
Internet erhältlich, mit denen solche Lücken auch von
Nicht-Experten ausgenutzt werden können. Die Reaktionszeit ist hier zentral. Es kann in den meisten
Fällen nicht ein Vierteljahr auf den nächsten Release
gewartet werden. SaaS-Angebote haben hier klare
Vorteile, da der Hersteller die entsprechenden Patches selber zentral für alle Kunden ausrollen kann.
Über die Bedag Informatik AG
Die Bedag ist mit einem Umsatz von über 100 Mio.
Franken ein führendes schweizerisches IT-Dienstleistungsunternehmen. Mit ihren 400 Mitarbeiterinnen und Mitarbeitern – wovon über 20 Lernende
– verfügt sie über ein breites und fundiertes Informatik-Know-how. Ihr Kerngeschäft ist die Entwicklung,
die Wartung und der Betrieb von geschäftskritischen
Informatiklösungen. Damit ermöglicht sie ihren Kunden einen wirtschaftlichen und sorgenfreien Informa-
tikeinsatz. Mit einem Netz von hochsicheren Rechenzentren sowie Standorten in Bern, Aarau, Delémont,
Genf, Lausanne und Wettingen ist sie regional stark
präsent. Ihre Kunden sind hauptsächlich öffentliche
Verwaltungen und Betriebe, Unternehmen im Gesundheits- und Versicherungswesen sowie UN-Organisationen. Die Bedag wurde 1990 gegründet und
befindet sich im Eigentum des Kantons Bern.
www.bedag.ch
Bedag Informatik AG
Engehaldenstrasse 12
Postfach
3001 Bern
Tel. 031 633 21 21
[email protected]
www.bedag.ch
07/16