Software-EntwicklungTechnologie-Kompass

Inhalt2 Vorwort

3 Kontext

4 Benutzeroberflächen

6 Plattform

9 Daten

10 Integration

12 Dokumente

14 Analytics

16 Betrieb

Vorwort

DieITistsehrschnelllebigundwirdvonvielenneu-enTechnologietrendsbestimmt.JedesJahrveröf-fentlichen zahlreiche Trendforscher ihre Studien.Zurzeit heissen die prägenden IT-Trends MobileComputing,IT-as-a-Service,BigData,OpenSourceundCloud.DieseListe liessesichbeliebig verlän-gern.EineshabenaberalleTrendsgemeinsam:SiefolgendemMegatrend„immerschneller,günstigerundsicherer”.

Als ein führendes schweizerisches IT-Dienstleis-tungsunternehmen fragen wir uns im Rahmen un-seres Innovations-Managements regelmässig, wo-hin 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, Werkzeu-ge und Methoden auf ihre Einsatzfähigkeit bewerten, eine Auswahl treffen und uns gezielt auf diese kon-zentrieren. Davon profitieren die Applikationen un-serer Kunden, indem wir proaktiv und frühzeitig auf sichtbare Veränderungen reagieren. Gleichzeitig hal-ten wir das technische Know-how unserer Entwickler auf dem neusten Stand, ohne uns zu verzetteln.

Auf vielseitigen Wunsch stellen wir mit dem Techno-logie-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 Ent-scheidungsträger in der öffentlichen Verwaltung. Er zeigt und erklärt jährlich aktuelle Entwicklungen und Trends in den wichtigsten Gebieten der IT. Er gibt ei-nen Ausblick darauf, wie neue Applikationen ausse-hen werden und auf welche Aspekte bei der Beschaf-fung Wert gelegt werden sollte.

Erstellt wird der Kompass von den Experten der Be-dag auf Basis des internen Innovations-Management-Prozesses der Bedag, dem Technologie-Radar.

Gerne diskutieren wir mit Ihnen unsere Einschätzung der technologischen Herausforderungen in Ihrem Kontext.

Daniel BiemannLeiter Software-EntwicklungMitglied der Geschäftsleitung

Ferdinand HübnerCTO Software-Entwicklung

2

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 Mit-arbeiterinnen und Mitarbeiter als auch Kunden der Verwaltung durch die private Benutzererfahrung von Internet, E-Commerce, Tablet und Smartphone be-einflusst werden und dieselben Ansprüche an die IT der Verwaltung stellen. Ein wichtiges Stichwort ist „Mobilität“. Mitarbeiterinnen und Mitarbeiter arbei-ten vermehrt nicht nur ausschliesslich im Büro von neun bis fünf, sondern rund um die Uhr auch unter-wegs oder im Home Office. Gleichzeitig möchten Kun-den ihre Geschäfte mit der Verwaltung ebenfalls von einem beliebigen Ort zu einer beliebigen Zeit abwi-ckeln. Nach wie vor sind zahlreiche Prozesse in der Verwaltung papierbasiert. Die Digitalisierung wird ohne Zweifel rasant fortschreiten und ist ein wesent-liches 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.

Der Druck nach höherer Wirtschaftlichkeit, Digita-lisierung, Mobilität und Agilität stellt Verwaltungen vor grosse organisatorische Herausforderungen und verlangt eine höhere Innovationskraft der Lö-sungsanbieter. Beschaffer sind heute die Fachabtei-lungen, während die zentrale IT eine Governance-Rolle übernimmt. Kantone und Gemeinden schliessen sich zusammen, um gemeinsame Beschaffungen durchzuführen. Wenige grosse Anbieter werden zahl-reichen kleinen Anbietern vorgezogen. Man sucht vornehmlich Standardlösungen und weniger Indivi-dual-Software. Auch wenn Gesetze und Verordnun-gen 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 en-gere 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).

3

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 nachempfunde-nen Web-Applikationen der ersten Generation wer-den verschwinden und durch schlanke und moderne Web-Applikationen ersetzt. Dabei wird nicht nur die Technologie ausgetauscht, sondern auch die Bedi-enkonzepte: Die komplexen Masken mit dutzenden von Feldern, Abkürzungen und Tastaturkürzeln ver-schwinden. Moderne Applikationen interpretieren die Eingaben des Benutzers automatisch im Kontext und fragen nur die wirklich relevanten Informationen ab. Dadurch verkürzt sich insbesondere die Einarbei-tungszeit 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 er-gä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.

Das Entwickeln von nativen Apps für Smartphones und Tablets ist nicht bezahlbar, da die Mitarbeiter er-warten, den kompletten Funktionsumfang der Appli-kation auch unterwegs nutzen zu können. Erschwe-rend 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 Stich-wörter dazu sind „mobile first“ und „responsive De-sign“.

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 Ex-plorer auf Version 11 respektive Edge zu aktualisie-ren. Nicht portable Applikationen, die stark veraltete Browser voraussetzen, können via Citrix weiterhin angeboten werden. Die Portabilität zwischen den ver-schiedenen Browsern (Chrome, Firefox, Safari, Inter-net Explorer und Edge) ist mittlerweile sehr gut; eine starke Verbesserung zur Situation in den letzten fünf Jahren.

4

Beispiel:Suchen

Die Suche in den Applikationen funktioniert neu genau wie eine Internetsuche in Google. Der Anwender gibt die ihm be-

kannten 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?

5

Plattform

EndederApplikations-ServerGrosse, teure, zentral verwaltete Applikations-Ser-ver, 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 Fachappli-kationen in die zentral bereitgestellten Applikations-Server-Instanzen. Inkompatible Versionen, kleine Konfigurationsfehler und Unterschiede zwischen den Produkten der einzelnen Hersteller führen oft zu Ver-zö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 Ap-pliances zu betrachten, bei denen der Software-Her-steller einen fertig konfigurierten und bei ihm in ge-nau dieser Konfiguration durchgetesteten Container an den Betreiber liefert. Der Betreiber führt diesen dann bloss noch aus, das Management erfolgt durch den Software-Hersteller.

Entwicklung–OpenSourcestatt teureproprietäreProdukteDie Entwicklung von Fachapplikationen erfolgt heu-te weitgehend in und mit Open Source. Dies bedeutet nicht zwangsläufig, dass die Applikationen auch Open Source sind. Aber praktisch der gesamte nicht-fach-spezifische Code der Applikation besteht aus Open-Source-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 kom-plett Open Source. Die Vorteile für die Entwickler lie-gen 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 ausser-dem durchaus sehr guter professioneller Support von Drittanbietern verfügbar.

Microsoft ist durch diese Entwicklung unter Druck geraten und hat daher auch den Grossteil seiner Ent-wicklungsumgebung als Open Source verfügbar ge-macht.

Aus Sicht der Kunden führt diese Entwicklung zu qua-litativ besseren Anwendungen und zu tieferen Kosten. Wir empfehlen, bei der Beschaffung die Verwendung von Open Source als Bestandteil der Applikationen zu fordern.

6

Continuous Delivery und Scrum statt zu viel KonfigurierbarkeitGerade bei grossen Projekten im Rahmen von WTO-Ausschreibungen 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 ver-bunden – 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 An-forderungen an den Benutzer, der die Konfiguration durchführt, sehr hoch. Diese Konfiguration der An-wendung ist dann ähnlich komplex wie eine gängige Programmiersprache, nur dass sie schlechter do-kumentiert und mit weniger Tooling unterstützt ist. Diese Komplexität können Anwender respektive Ad-ministratoren 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 umset-zen könnte, vorgenommen werden.

Die Hauptursachen für den Wunsch nach Konfigurier-barkeit sind:• Lange Release-Zyklen:

Zwischen einem Änderungswunsch und der Aus-lieferung in der produktiven Software vergeht zu viel Zeit. Aufgrund der Erfahrung mit der bisheri-gen Software und deren langen Release-Zyklen (ein Jahr und mehr) soll in der neuen Software

alles direkt am laufenden System verändert wer-den können. Dies ist typischerweise aber nur in der Anfangsphase möglich, schon bald wird – aufgrund der fatalen Auswirkungen von Fehlkon-figurationen – die Konfiguration der Applikation ebenfalls streng reglementiert und verzögert. Das organisatorische Problem langer Release-Zyklen kann nicht mit technischen Mitteln gelöst werden, sondern muss mit einer Umstellung der gesamten Prozesse hin zu Agilität und Conti-nuous Delivery angegangen werden. Ein wichti-ges Element dabei sind komplett automatisierte Regressionstests, die unbedingt als Teil der Be-schaffung betrachtet werden sollen.

• Unklare Anforderungen: Die Anforderungen an die Anwendung sind zum Zeitpunkt der Ausschreibung noch nicht wirklich klar. Durch eine Forderung nach Konfigurier-barkeit soll die Anwendung dann an die später identifizierten Anforderungen angepasst wer-den. 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 Sze-narien 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 WTO-Ausschreibungen genutzt werden. Die dabei ent-stehende Software wird günstiger und besser zu bedienen sein als die hochkonfigurierbare Alter-native.

7

PolyglotteProgrammierung:

Es wird nicht nur eine einzige Programmiersprache für

eine Applikation verwendet, sondern mehrere gleich-

zeitig. Dabei wir jede Sprache für jene Aufgaben einge-

setzt, wozu sie am besten geeignet ist. So werden zum

Beispiel komplexe Backends in einer typisierten Spra-

che wie Java geschrieben, statistische Analysefunktio-

nen in R und die Benutzeroberfläche mit Javascript.

FunktionaleProgrammierung:

Die herkömmlichen, imperativen Sprachen wie Java

und C# werden zunehmend durch funktionale Sprachen

ergänzt. Diese erlauben einen einfacheren Umgang

mit Mehrprozessorsystemen und vermindern das Ri-

siko unerwünschter Seiteneffekte. Beispiele für solche

Sprachen sind Scala (für die Java-Plattform), F# (für die

.NET-Plattform) oder Haskell.

ProgrammiersprachenIm Bereich der Sprachen gibt es im Moment zwei vor-herrschende Trends:

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 Anforde-rungen sollen stattdessen auf Ebene der gewünsch-ten Zielplattform (zum Beispiel Linux, Windows, Datenbanken, Cloud) und der Schnittstellen/Intero-perabilität (REST, SOAP-Web-Services, Messaging) definiert werden.

8

Daten

FlexibilitätdurchereignisbasierteSystemeDie Entwicklung geht stark in die Richtung ereignisba-sierter Systeme (Stichwort „unified log processing“). Im Fokus steht dabei, anstatt wie üblich die „stati-sche“ Datenhaltung in der Applikation (zum Beispiel Attribute einer Person wie Name, Adresse oder die Daten zu einer Bestellung), die Sammlung der Ereig-nisse, die zu den betreffenden Daten geführt haben. In den Beispielen wären das Geburt, Umzug oder „Be-stellung abschliessen“. Die unternehmens- respekti-ve verwaltungsweit zusammengeführte Kette dieser Ereignisse bildet nun die Kerndaten der Unterneh-mung. 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 Ma-

nagement - 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 Ver-

gangenheit anwendbar, aus den gespeicherten Ereignissen können neue Daten erzeugt werden

Eingesetzt werden die ereignisbasierten Systeme bis-her vor allem von grossen eCommerce-Firmen wie Amazon, die damit bessere Einsicht in das Verhalten der Kunden und deren Bedürfnisse bekommen. Zen-

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.

RelationaleDatenbankenalsCommodityIm Bereich der relationalen Datenbanken zeichnet sich ein Wechsel weg von den teuren Produkten wie Oracle, Microsoft SQL Server oder DB2 hin zu Open-Source-Datenbanken wie PostgreSQL ab. Diese ste-hen 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 Commo-dity 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 Ser-vern war es wirtschaftlicher, in die freien Produkte zu investieren, als die teuren Lizenzen an Oracle ab-zuführen. Gerade in Bezug auf die Skalierbarkeit für ganz grosse Datenmengen und Zugriffszahlen haben die Open-Source-Produkte die kommerziellen Lösun-gen daher schon hinter sich gelassen.

9

Integration

Microservices–agilereITDas Trendwort im Bereich der Plattformen ist Micro-services. Anstatt als grosse, voll integrierte Appli-kationsmonolithen werden die Lösungen aus kleinen, in sich kompletten Diensten aufgebaut. Jeder Dienst ist dabei für genau eine klar abgegrenzte Geschäfts-funktion zuständig und hat seinen eigenen Lebenszy-klus. Etwas vereinfacht gesagt, entspricht ein Micro-service einer App auf einem Smartphone, nur eben auf Server-Seite. Jede solche „App“ erfüllt genau ei-nen Zweck (zum Beispiel WhatsApp, um Sofortnach-richten auszutauschen, oder Expensify, um Spesen zu erfassen).

Aus organisatorischer Sicht vermindern Microser-vices die „Diseconomies of scale“ bei der Software-Entwicklung. In der Software-Entwicklung gilt der Grundsatz, dass, je grösser die entwickelte Appli-kation, desto weniger effizient wird die Entwicklung erfolgen. Die notwendige Kommunikation und Koor-dination zwischen den Entwicklern und die negativen Auswirkungen von Fehlern in der Architektur oder bei den Anforderungen führen dazu, dass jeder zusätz-liche Entwickler immer weniger Ergebnisse produ-ziert. Die optimale Grösse einer Applikation ist, wenn sie von ungefähr sieben Entwicklern erstellt werden kann.

Mit dem Microservice-Ansatz wird die vormals gros-se Applikation in voneinander weitgehend unabhängi-ge Dienste aufgeteilt, für die jeweils ein kleines, hoch-produktives Team zuständig ist.

• Dezentrale Verwaltung: Jeder Microservice wird von einem eigenständigen Team mit einem eige-nen 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ärts-kompatibilität der Dienste investiert werden.

• Dezentrale Daten: Die Daten werden pro Micro-service isoliert gehalten, das heisst es ist kein direkter Datenzugriff über die Service-Grenzen möglich. Jeder Dienst hat seine eigene Daten-bank.

• Kleinere Granularität: Microservices haben typi-scherweise 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-

Microservices erinnern an die mittlerweile etablierte Service-orientierte Architektur (SOA), wobei der Be-griff SOA mittlerweile vor allem durch Tool-Hersteller so aufgeweicht worden ist, dass eine klare Einord-nung 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 ver-stecken. Auf Microservice basierte Architekturen verzichten bewusst darauf und setzen auf Infor-mationsaustausch auf der Basis einfacher Proto-kolle (meist REST) über simple Übertragungswe-ge (dump pipes).

10

Prozessen mit ein bis zwei Releases pro Jahr und einem Vorlauf für neue Funktionen von bis zu einem Jahr wegzukommen. Weder Unternehmen noch Ver-waltungen können es sich heute leisten, derart lange auf neue, wichtige Geschäftsfunktionen zu warten.Aus Sicht einer Verwaltung soll darauf geachtet wer-den, dass nicht grosse, monolithische Systeme er-stellt beziehungsweise beschafft werden, sondern auf eine modulare Architektur gesetzt wird.

API–eGovernmenteffizienterundgünstigerDas Problem der meisten existierenden eGovern-ment-Lösungen ist, dass sie entweder für den ein-zelnen 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 ge-eignet. Ein Beispiel hierfür sind die Web-Lösungen der Strassenverkehrsämter: Für grosse Transport-unternehmen sind diese unpraktisch, da sie sich nicht in ihre Systeme integrieren lassen. Dem gegenüber stehen Lösungen, die explizit für Unternehmen konzi-piert wurden. Diese lassen sich sehr gut integrieren und bieten zusätzliche Funktionen, allerdings zum Preis von komplizierten Schnittstellen und komple-xen Einrichtungsprozessen. Oft muss zuerst Soft-ware zertifiziert und es müssen Vereinbarungen ge-schlossen 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 zu-gängliche technische Dienste („Web Services“) und zwar unabhängig von konkreten Verwendungsszena-rien. 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. Optima-lerweise 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 bei-spielhaften Verwendungen:• Ein innovativer Softwarehersteller entwickelt

eine iPhone App mit der ein Bürger seine Autos verwaltet und diese auch gleich zur Prüfung an-melden 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 erwei-tert ihre Fahrzeugverwaltung um ein kleines Mo-dul, das das Anmelden von Autos direkt aus der Applikation heraus ermöglicht.

• Ein Software-as-a-Service-Angebot für Fahr-schulen 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. sedexmiteCH-StandardsFür den privaten Meldungsaustausch zwischen Be-hö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 et-was schwerfälligen Handhabung sowie des begrenz-ten Meldungsdurchsatzes, ist es der einfachste und zuverlässigste Weg. Als Format für die ausgetausch-ten Meldungen werden in fast allen Fällen Standards des Vereins eCH verwendet. sedex Pathfinders er-weitert sedex zusätzlich um eine Möglichkeit zur syn-chronen 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.

11

Dokumente

Dokumente–verborgeneDatenImmer wenn Mitarbeiterinnen und Mitarbeiter rou-tinemässig gleichartige Dokumente manuell verfas-sen, verschwinden dabei aus Sicht der Organisation Daten aus dem Nutzbereich. Mithilfe teurer und für die Anwender oft umständlicher Document Manage-ment Systeme (DMS) wird dann versucht, wenigstens einen Teil dieser Daten wieder nutzbar zu machen und eine Art Versionskontrolle sicherzustellen. Eben-falls viel Geld kostet es, diese Dokumente immer wie-der für neue Versionen von Microsoft Office lesbar zu machen.

Viel einfacher und zielführender ist, die Informatio-nen von Beginn weg in einer mindestens halbstruk-turierten Form zu erfassen und damit maschinenles-bar, -suchbar und -auswertbar zu machen. Sinnvolle Ansätze dazu sind die Integration in eine Fachlösung oder die Nutzung spezialisierter Systeme, die den Be-nutzer 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ätz-lich ist es so auch möglich, die Daten direkt elektro-nisch zu verarbeiten. Der Kunde könnte zum Beispiel seine Veranlagungsverfügung direkt wieder in seine Steuer-Software einlesen.

Formulare–immernochwieaufdemPapier?Elektronische Formulare werden vielfach stiefmüt-terlich behandelt. Ihre Möglichkeiten werden schlecht genutzt. Die folgenden Schwachstellen sind häufig:• Keine Anbindung an die Systeme: Nach der er-

folgten 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 sons-tige Fachapplikationen) überführt.

• Schlechte Benutzerführung: Elektronische For-mulare 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 er-klärende Texte vorhanden sein.

• Verwendung von PDF-Formularen: Diese ent-sprechen 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 soll-te 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 elek-tronische 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 ge-nügen den Sicherheitsanforderungen nicht. Viel sinn-voller 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

AblösenvoninternenAntragsformularen

Ein sehr einfach erreichbare Verbesserung, eine so-

genannte low-hanging fruit, ist, die internen Abläufe

zwischen mehreren Stellen, wie zum Beispiel ein Per-

sonaleintritt oder das Beantragen von Berechtigungen,

statt via E-Mail versandte Word-Dokumente in einem

Vorgangsverfolgungssystem wie Atlassian JIRA abzu-

bilden. Die Angaben werden strukturiert erfasst und

können trotzdem noch mit speziellen Bemerkungen

ergänzt werden. Auswertungen über die Bearbeitungs-

zeit, Engpässe und Art der Anfragen können einfach di-

rekt vom Manager selber erstellt werden.

12

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 Zeit-punkt 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.

DigitalDivide–nichtallesindimInternetGerade für Verwaltungen ist der Digital Divide eine grosse Herausforderung. Im Unterschied zu Unter-nehmen können sie nicht einfach aus Effizienzgrün-den 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 ach-ten, 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.

13

Analytics

EntscheidungshilfenstattReportsAn die Stelle fixer vorgefertigter Reports und un-flexibler 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 In-dicators. Weitere für die Entscheidungsfindung not-wendige 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, son-dern direkt vom Manager oder von der Controlling-Abteilung. 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 Er-eignisse – 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 Tech-nologien bildet Predictive Policing: Anstatt nur aus-zuwerten, wo wie viele Einbrüche passiert sind, er-rechnet das System selbständig, wo in nächster Zeit vermehrt mit Einbrüchen zu rechnen ist.

NeueMöglichkeitenmitBigDataErmöglicht wird dieser Blick in die Zukunft von Tech-nologien, 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 fil-tern.

• Echtzeit Verarbeitung (Velocity): Alle Daten sind sofort verfügbar, sie werden laufend ins System eingespiesen.

• Vielfalt der Formate (Variety): Nicht nur struktu-rierte 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 Maschi-nenlernen und Modellen versucht, neue Schlussfol-gerungen zu gewinnen. So werden Prognosen, Simu-lationen oder Risikobeurteilungen erstellt, um damit Entscheide mit Fakten zu unterstützen. Einsatzbei-spiele für Big Data in der Verwaltung können sein:• Erkennung von Betrug, zum Beispiel bei der Ab-

rechnung der Mehrwertsteuer. In Belgien wird dies mit grossem Erfolg bereits eingesetzt.

• Unterstützung beim Prüfen der Steuererklärun-gen durch eine automatische Risiko- und Kom-plexitätseinstufung mit vollautomatischer Ver-anlagung 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.

14

TechnologienfürBigDataDie momentan am häufigsten verwendete Technolo-gie ist Apache Hadoop. Sie bildet die Grundinfrastruk-tur 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 Daten-verlust führt. Klassische Storage-Systeme (SAN) und Backups sind für diese Datenmengen zu teu-er. Stattdessen werden Server mit vielen günsti-gen 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 Ver-arbeitung von grossen Datenmengen. Jeder Ser-ver analysiert „seine“ Daten, die Ergebnisse wer-den aggregiert.

Basierend auf diesen drei Basisdiensten ist eine Viel-zahl weiterer Lösungen entstanden, die zum Beispiel Abfragen mittels SQL-ähnlicher Sprache ermöglichen (Apache Hive), aber auch eine hochverfügbare Daten-bank (Apache Cassandra), eine Lösung für Machine

Learning (Apache Mahout) oder die Analyse von Da-tenströmen (Apache Spark). Während zu Beginn täg-lich 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 kleine-re Datenbestände können die oben aufgeführten An-wendungsfä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 aufkom-menden Möglichkeiten zu nutzen, aber zurückhaltend zu bleiben mit dem Einsatz von Big-Data-Technolo-gien. Erst wenn sich wirklich zeigt, dass die Daten-menge zu gross ist, lohnt es sich, die Mehrkosten und die Komplexität in Betrieb und Entwicklung in Kauf zu nehmen.

15

Betrieb

Cloud-TechnologienfürschnellereRelease-ZyklenDer Ü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

Die Cloud-Angebote lassen sich gemäss NIST nach Art

der Bereitstellung und Art der Dienstleistung einteilen.

Dienstleistung:

• Software-as-a-Service (SaaS): Der Kunde bezieht

eine komplette Applikation als Dienstleistung. Die-

se beinhaltet als Gesamtpaket sowohl Software,

Lizenzen, Updates, Betreuung als auch den Betrieb

und die Überwachung.

• Plattform-as-a-Service (PaaS): Der Kunde bezieht

eine Umgebung, in die er seine Applikationen ins-

tallieren kann. Die Plattform stellt dabei Basiskom-

ponenten (zum Beispiel Datenbank, Applikations-

server oder Netzwerkspeicher), das Patching und

Tools zur Überwachung zur Verfügung.

• Infrastructure-as-a-Service (IaaS): Der Kunde be-

zieht IT-Basiskomponenten wie CPU-Leistung,

Speicher und Netzwerkbandbreite. Er verwaltet

alles – von der Software bis zu den Betriebssyste-

men – selbst.

Bereitstellung:

• Public Cloud: Offen, für alle im Internet verfügbar.

Beispielsweise Amazon AWS oder Microsoft Azure.

• Private Cloud: Exklusiv für eine Verwaltungseinheit

oder ein Unternehmen verfügbare Cloud. Wird ent-

weder selbst oder vom Betriebspartner betrieben.

• Hybrid Cloud: Kombination unterschiedlicher

Cloud-Angebote; meist public und private.

• Community Cloud: Steht exklusiv einem Zusam-

menschluss von Organisationen 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 Ama-zon oder Microsoft Azure - Infrastructure-as-a-ser-vice 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 Ge-schäftsmodells sind Skaleneffekte durch die enorme Anzahl gleicher Systeme (pro Anbieter mehr als eine Million Server) und die sich ausgleichenden Bedarfs-spitzen vieler Kunden.Der Kunde erzielt durch das Verwenden einer IaaS-Cloud im Wesentlichen zwei Vorteile:• Geringere Kosten bei stark schwankendem Res-

sourcenbedarf: Wenn der Verbrauch während

des Jahres sehr stark schwankt, ist das Pay-Per-Use-Modell sehr attraktiv. Die Server kosten nur dann Geld, wenn sie tatsächlich gebraucht wer-den. Es müssen zwei Voraussetzungen erfüllt sein, damit diese dynamische Ressourcenanpas-sung ü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 Auf-wand 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. Heu-te weisen selbst die kleinsten Server-Einheiten

16

schon eine beträchtliche Leistung auf und können mehrere hundert Benutzer bedienen. Daher gibt es im Verwaltungsumfeld nur wenig Applikatio-nen, 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 sei-nes Betriebspartners installieren. Entweder ad-hoc oder aber als Virtual Appliance. Dabei muss darauf geachtet werden, dass der betreffende Hersteller die notwendige Betriebskompetenz hat: Monitoring, Patching, Absichern des Ser-vers und Backup müssen durch ihn sichergestellt werden.

Das Verwenden einer Public Cloud für Anwendungen, die durchgehend einen stabilen Kapazitätsbedarf ha-ben, lohnt sich bei exakter Kalkulation finanziell nur selten. Neben den Kosten für die eigentlichen Syste-me fallen zusätzlich auch Kosten für Datentransfer, Speicher und weitere Ressourcen an. Bei einer Pri-vate oder Community Cloud steht vor allen der Vorteil der schnelleren Installation der Applikationen im Vor-dergrund. Für eine Kosteneinsparung durch Skalen-effekte 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 da-rauf, 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 PaaS-Plattform ermöglicht, sowohl die Dauer als auch den Aufwand für den Aufbau und das Update von Syste-men 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 Automatisie-rung ermöglichten schnelleren Release-Takt, bis hin zu einem Continuous Delivery.Um eine PaaS effizient zu betreiben, ist eine Mindest-grösse in der Grössenordnung von Hunderten von Servern erforderlich. Ansonsten übersteigen die Auf-wä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 nach-trä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 all-fälliger Lizenzen – als Dienstleistung vom Anbieter bereitgestellt. Bekannte Beispiele dazu sind Sales-force, Dropbox oder Gmail. Durch den Betrieb vie-ler Instanzen respektive Mandanten der Applikation durch einen Anbieter entstehen bedeutende Ska-leneffekte. Der Anbieter ist häufig gleichzeitig auch der Software-Hersteller und kann dadurch kürzere Release-Zyklen und eine schnellere Reaktion bei Be-triebs- oder Sicherheitsproblemen bieten. Aus Kun-densicht muss aber darauf geachtet werden, dass der Betrieb professionell erfolgt. Gerade auf Basis der Public-Cloud-Angebote ist die Versuchung bei Soft-ware-Herstellern gross, selber ein SaaS-Angebot zu "basteln", ohne die dafür notwendigen Kompetenzen und Erfahrungen im Betrieb zu haben.

17

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üt-

zenswerte Daten

nur für Applikationen mit stark

schwankendem Ressourcen-

Bedarf und ohne schützenswer-

te Daten

nur durch ausgebildete System

Engineers

Private/Community Cloud nutzen wo verfügbar (Commu-

nity)

nutzen

erst ab min. 100 Servern wirt-

schaftlich betreibbar (private)

nicht wirtschaftlich

kann sinnvoll sein für Entwick-

lungsumgebungen

Hybrid Cloud Kombination mit interner

Software

Komplexität überwiegt Kosten-

einsparungen meistens

nicht wirtschaftlich, zu komplex

UnsereEmpfehlungenfürVerwaltungen

Open-Source-TechnologienalsRückgratIm Betrieb gibt es einen klaren Trend zur Verwen-dung von Open Source Software und Tools. Einerseits hängt dies damit zusammen, dass sie kostenlos ver-fü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 Ge-brauch in ihren eigenen Rechenzentren entwickelt haben und sie öffentlich verfügbar machen.

Das oben bereits erwähnte Kubernetes – die Grund-lage 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 Shift- Cloud-Produkt. Mittlerweile ist Kubernetes der De-Facto-Standard für Container-PaaS-Lösungen. Eine analoge Entwicklung hat im Bereich der IaaS-Lösun-gen bereits stattgefunden: Praktisch alle Angebote basieren auf der als Open Source verfügbaren Open-Stack-Plattform.

Auch für das Monitoring (Nagios, Graphite, InfluxDB und Prometheus), für das Konfigurations-Manage-ment (Puppet, Ansible) und für die Protokollierung (Logstash, Graylog und Elasticsearch) sind Open-Source-Lösungen die beliebtesten Tools.

18

SicherheitistzentralGerade im Verwaltungsumfeld verarbeiten die An-wendungen oft heikle Personendaten, welche ent-sprechend gut geschützt sein müssen. Immer häufi-ger sollen diese Anwendungen aber auch direkt über das Internet zugänglich sein, damit die Verwaltung ihre Aufgaben effizienter erfüllen kann und die Bür-ger 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 da-mit 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 Ba-sis bildet ein sehr guter Grundschutz im Betrieb, der auch entsprechend zertifiziert ist (ISO-27001). Im Un-terschied zu früher reicht es aber nicht länger aus, sich in der Sicherheitsfrage auf eine optimale Ab-schottung der Applikationen durch den Betreiber zu konzentrieren. Durch die Anforderung nach breiterer

Verfügbarkeit der Anwendungen lassen sich diese nicht mehr abschotten. Mittels Social-Engineering-Techniken machen Angreifer auch Mitarbeiterinnen und Mitarbeiter der Verwaltungen zu unfreiwilligen Komplizen und greifen so auch eigentlich gut abge-schottete Applikationen an.

Die Software-Hersteller müssen diese Herausfor-derung aktiv annehmen und ihre Applikationen von sich aus auf Sicherheitslücken überprüfen und mit schneller Bereitstellung von Patches aktiv reagie-ren. 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 Re-aktionszeit 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 Pat-ches selber zentral für alle Kunden ausrollen kann.

19

04/17

ÜberdieBedagInformatikAGDie Bedag ist mit einem Umsatz von über 100  Mio. Franken ein führendes schweizerisches IT-Dienstleis-tungsunternehmen. Mit ihren 400 Mitarbeiterinnen und Mitarbeitern – wovon über 20 Lernende – ver-fügt sie über ein breites und fundiertes Informatik-Know-how. Ihr Kerngeschäft ist die Entwicklung, die Wartung und der Betrieb von geschäftskritischen In-formatiklösungen. Damit ermöglicht sie ihren Kunden einen wirtschaftlichen und sorgenfreien Informatik-

einsatz. Mit einem Netz von hochsicheren Rechenzen-tren sowie Standorten in Bern, Aarau, Delémont, Lau-sanne und Wettingen ist sie regional stark präsent. Ihre Kunden sind hauptsächlich öffentliche Verwal-tungen 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 AGEngehaldenstrasse 12Postfach3001 Bern

Tel. 031 633 21 21info@bedag.chwww.bedag.ch