MS-Access ade! Aus alt mach neu.

1.      Gründe / Ausgangslage

Mit MS-Access konnten vor 15 Jahren auf komfortable Art und Weise Anwendungen entwickelt werden, welche eine Datenbank, Logik und eine Benutzeroberfläche beinhalteten. MS-Access als Basis-Technologie wird von Microsoft nicht mehr unterstützt. Mit Windows 10 funktioniert es bereits heute nicht mehr. Offizielle Abkündigung von MS-Access 2010 ist im Oktober 2020.

Alte Datenbank MS-Access

Solche Anwendungen gibt es einige, sie sind viele Jahre alt, meist gibt es keine Dokumentation. Mit MS-Access war es schwierig, unterschiedliche Kundenwünsche unter einen Hut zu bringen. Eine gängige Lösung war, pro Kunde eine eigene MS-Access Lösung zu entwickeln. Was zur Folge hatte, dass der Aufwand in Bezug auf Releaseplanung und Durchführung überproportional stieg.

2.      Vorgehen

Die bestehende Anwendung ist ziemlich sicher noch im Einsatz und kann somit aus funktionaler Sicht (Use Cases) analysiert werden. Dabei geht es um die Hauptfunktionalitäten. Es wird sich kaum lohnen, sämtliche Funktionen bis ins Detail anzuschauen. Denn vielfach bietet sich die Gelegenheit, nicht (mehr) benötigte Funktionalitäten wegzulassen.

Ein Quervergleich mit dem Programmcode ist sinnvoll. Letztendlich liegt die Wahrheit im Programmcode! Eine kurze Analyse gibt zugleich einen Einblick bezüglich Komplexität. Allzu viel Zeit sollte nicht aufgewendet werden.

Danach macht es Sinn, ein Pflichtenheft zu erstellen. Wichtige technische Punkte sind Architektur (Web- oder Desktop-Anwendung) und Technologien (Java / .NET / PHP etc).

Die Kosten müssen auch berücksichtigt werden. Ist der Kunde bereit, zusätzliche Kosten zu tragen? Wie sieht die Konkurrenz aus? Parallel zur Erstellung des Pflichtenheftes kann eine Aufwandschätzung mit 10% Genauigkeit gemacht werden. Spätestens bei Vollendung des Pflichtenheftes muss klar sein, ob sich die Neuentwicklung lohnt.

Cloud Datenbank

3.      Checkliste

Folgende Checkliste hilft, dass keine wesentlichen Informationen verloren gehen:

  • Gibt es Dokumente (Handbuch, Benutzeranleitung, Code-Beschreibung).
  • Bei welchen Kunden kann die Anwendung im realen Betrieb angeschaut werden.
  • Läuft die komplette Anwendung inkl. Datenbank auf einem Entwicklungsrechner und kann dort analysiert werden.
  • Ist bekannt, bei welchen Kunden welche Version installiert ist.
  • Ist der Sourcecode für die verschiedenen Kunden vorhanden.
  • Welche Hauptfunktionalitäten gibt es, welche werden von den Kunden genutzt.
  • Welche Hauptfunktionalitäten braucht es nicht mehr.
  • Ist es möglich, die bestehenden Daten zu übernehmen / migrieren.
  • Gibt es Kunden, welche als Erste die neue Anwendung nutzen wollen / müssen. Eventuell muss nicht die gesamte Funktionalität von Anfang an entwickelt werden.
  • Braucht es einen Mockup, um möglichst früh ein Feedback der bestehenden Kunden einzuholen.
  • Müssen Mitarbeiter geschult werden, damit die Neuentwicklung selbst gemacht werden kann.

4.      Fazit

  • Eine Neuentwicklung bietet die Gelegenheit, die Kundenzufriedenheit zu erhöhen.
  • Architektur und Technologien sind wichtige Punkte für den längerfristigen Erfolg, siehe https://hyperformers.com/architektur-die-erfolgsbasis/.
  • Ev. ist eine interne Weiterbildung der Mitarbeiter nötig, weil das Wissen in Bezug auf die neuen Technologien noch nicht vorhanden ist. Das ist gleichzeitig die Chance, die Mitarbeiter auf den neusten Stand zu bringen, siehe https://hyperformers.com/weiterbildung-im-digitalen-zeitalter/.
  • Nach Möglichkeit einen Pilotkunden auswählen, der nicht die gesamte Funktionalität von Anfang an braucht.

Rasanter Technologiewandel – .NET Core mit Angular

Die Technologien ändern schneller und die Vielfalt nimmt zu. Muss man immer auf dem neusten Stand sein? Am Beispiel der Microsoft .NET Core Technologie im Zusammenspiel mit Angular werden konkrete Antworten für eine Webanwendung aufgezeigt.

Webanwendung Heute

Eine mögliche Architektur auf dem neusten Stand der Technik sieht wie folgt aus:

  • Benutzeroberfläche mit Angular 4
  • Geschäftslogik, Datenhaltung mit .NET Core 2
  • Einsatz eines Frameworks für den Datenbank-Zugriff, z.B. Dapper
  • Test der Schnittstellen zwischen Angular und .NET Core mit Postman
  • Vollständige Entkopplung zwischen Benutzeroberfläche und Logik

.NET Core ist open source und Plattform unabhängig (läuft z.B. auf Windows, Linux und Mac). Angular ist die am weitesten verbreitete Technologie für Benutzeroberflächen von Webanwendungen.

VR-Technologie

Der Lauf der Zeit

Vor 4-5 Jahren sah die Vorgänger-Architektur so aus:

  • Benutzeroberfläche mit Razor Views (Einsatz eines JavaScript-Frameworks wie jQuery)
  • Geschäftslogik, Datenhaltung mit ASP.NET MVC (Model View Control) 5
  • Einsatz eines Frameworks für den Datenbank-Zugriff, z.B. Dapper
  • Vollständige Entkopplung zwischen Benutzeroberfläche und Logik

Im Jahr 2013/2014 gab es Angular 1 bereits, steckte noch in den Kinderschuhen. Ab 2015 war AngularJS verfügbar. D.h. vor 4-5 Jahren war Angular im Zusammenspiel mit ASP.NET MVC kein Thema.

Muss es immer das (Aller)Neuste sein?

Diese Frage hängt von der Konstellation ab:

1) Entwicklung einer neuen Anwendung

Hier lohnt sich der Einsatz der neusten Technologien. Damit wird die Zeit bis zum nächsten Wechsel maximal verzögert. Zu beachten sind folgende Punkte:

  • Technologie / eingesetzte Version muss stabil sein
  • Es müssen auf Fremdprodukte vorhanden sein. Konkretes Beispiel: NHibernate war Anfang 2018 nicht für .NET Core 2 verfügbar.
  • Neben der Entwicklung muss auch das Hosting angeschaut werden. .NET Core ist viel komplizierter als ASP.NET MVC

2) Weiterentwicklung einer bestehenden Anwendung

Meist werden noch andere Fremdprodukte / Bibliotheken eingesetzt. Solange der Support für diese Produkte und Technologien gewährleistet ist, muss nicht auf die neuste Technologie gewechselt werden. Dies ist meist für einige Jahre gewährleistet. Ausser es gibt neue Funktionen, die von der Anwendung gebraucht werden.

Technologie Wandel

Technologie Wechsel

In unserem Beispiel betrifft der Wechsel zwei Technologien:

1) Razor Views -> Angular

Es sind komplett verschiedene Technologien. Der bestehende Code kann nicht verwendete werden. Die Benutzeroberfläche muss neu entwickelt werden. Das bedeutet meistens viel Aufwand.

2) ASP.NET MVC -> .NET Core

Das Grundkonzept der Controller (Ablauflogik) kann übernommen werden. Der Startup-Code und die Konfiguration sind verschieden. Ein Teil des bestehenden Codes kann verwendet werden.

Im Normalfall ist der Controller-Teil eher klein. Darum ist es nicht so wichtig, wie viel davon wiederverwendet werden kann.

Wichtig ist, dass die Geschäftslogik nicht im Controller integriert ist.

Fazit

  • Wird eine Anwendung neu entwickelt, lohnt sich der Einsatz der neusten Technologien. Es sollen stabile Versionen eingesetzt werden. Weiter muss geprüft werden, ob es die nötigen Fremdprodukte zu dieser Technologie gibt.
  • Bei einer bestehenden Anwendung gibt es keinen zeitlichen Druck, die neusten Technologien einzusetzen.
  • Bei einem Technologiewechsel muss meist die Benutzeroberfläche neu entwickelt werden. Das ist mit viel Aufwand verbunden.
  • Die Geschäftslogik MUSS technologie-neutral sein. In unserem Fall: Programmierung in C# ohne Verweise / Referenzen auf Angular oder spezifische .NET Core Bibliotheken. Auf diese Weise kann die Geschäftslogik mit jeder Technologie eingesetzt werden, auch für ein App.

Links

Architektur – DIE Erfolgsbasis

Software Architektur ist von zentraler Bedeutung und kann einfach erklärt werden. Ein Vergleich mit der Überbauung einer Siedlung ermöglicht Parallelen zur Software Architektur. Auch als technischer Laie können Sie die richtigen Fragen stellen und verstehen die groben Zusammenhänge.

Ein Blick in die Überbauung einer Siedlung

Als konkretes Beispiel betrachten wir die Überbauung einer neuen Siedlung mit Einfamilienhäusern (EFH) auf der grünen Wiese. Der Käufer kann zwischen 3 Varianten wählen:

  • 5 Zimmer EFH mit Flachdach, ohne Garage
  • 5 Zimmer EFH mit Giebeldach und Garage
  • 5 Zimmer EFH mit Giebeldach, Garage und Solaranlage für die Stromerzeugung

Architektur-Gebauede

Als Architekt stellt sich die Frage, ob diese 3 Varianten fix geplant werden oder ob ein Modulbaukasten besser wäre:

  • Auswahl Anzahl Zimmer (5 oder 6.5)
  • Mit / ohne Garage
  • Flachdach oder Giebeldach
  • Mit / ohne Solaranlage

Vergleich der beiden Varianten:

3 fixe Varianten Modulbaukasten
Einfacher komplexer
Schneller realisiert (falls keine Zusatzwünsche) Mehr Aufwand zu Beginn (= teurer)
Nicht flexibel: Neue Anforderungen führen zu neuen Varianten Einfacher erweiterbar, z.B. Anzahl Nasszellen wählbar

Mehr Varianten

Gefahr von zu vielen Varianten im Laufe der Zeit Gefahr von zu vielen (kleinen) Modulen, die Übersicht geht verloren

 

Der Architekt muss entscheiden, welche Flexibilität nötig ist resp. welche Rahmenbedingungen gegeben sind:

  • Soll der Kunde kaufen, was vordefiniert ist (Auswahl aus genau 3 Varianten)
  • Wie viele EFH sollen insgesamt gebaut resp. verkauft werden
  • Wann muss das erste EFH verkauft sein, wie lange darf es max. dauern, bis alle EFH verkauft sind
  • Wie viel darf ein EFH kosten: Ein Konkurrenzvergleich liefert wichtige Informationen

Die Zukunft kann niemand voraussagen. Die Wahl der richtigen / besseren Variante ist immer verbunden mit einer subjektiven Einschätzung der Zukunft.

Von den Bauwerken zur Software Architektur

Als Vergleich wird die Entwicklung einer Buchhaltungs-Software herangezogen. Die Siedlung entspricht der Buchhaltungs-Software, das EFH einem Kunden (privat oder geschäftlich).

Es gibt wieder 3 Varianten:

  • Light: Einfache Buchhaltung, nicht mandantenfähig, ohne MWSt, keine Schnittstellen zu anderen Systemen
  • Simple: Doppelte Buchhaltung, mandantenfähig, mit MWSt, keine Schnittstellen zu anderen Systemen
  • Advanced: Doppelte Buchhaltung, mandantenfähig, mit MWSt, Schnittstellen zu anderen Systemen

Buchhaltung

Als Modulbaukasten gibt es folgende Konfigurationsmöglichkeiten:

  • Einfache oder doppelte Buchhaltung
  • Mit / ohne MWSt
  • Mandantenfähig
  • Schnittstellen (z.B. Export von Buchungen im csv-Format)

Marketing / Verkauf müssen folgende Fragen beantworten:

  • Wie lange darf es max. dauern, bis eine erste Variante verkauft werden kann und wie hoch dürfen die Entwicklungskosten dafür sein
  • Welche Variante ist es: Light oder Simple? Die komplizierteste Variante wird selten als Erste umgesetzt.
  • Wann müssen die anderen Varianten bereit sein und wie hoch dürfen die Entwicklungskosten dafür sein
  • Sind weitere Varianten denkbar: Doppelte Buchhaltung, nicht mandantenfähig, ohne MWSt

Danach muss die Technik entscheiden, ob die fixen Varianten oder der Modulbaukasten umgesetzt werden.

Wechsel der Architektur

Ein Wechsel der Architektur ist kostspielig. Die Architektur der Software widerspiegelt sich in der Grundstruktur der Anwendung:

  • Eingesetzte Tools und Technologien
  • Struktur der Kernfunktionalitäten (Module, Ablauf, Daten)
  • Definition der Schnittstellen

Bei einem Wechsel müssen nicht alle Punkte betroffen sein. Jeder einzelne Punkt für sich alleine betrachtet kann mit Aufwand verbunden sein.

Technisch ist ein Wechsel machbar. Je später der Wechsel erfolgt desto teurer wird es. Sind z.B. schon Lizenzen für das Buchhaltungsprogramm verkauft worden, muss der technische Support sichergestellt werden. Diese Kunden sind nicht bereit, für eine neue Version, die keine neuen Funktionen beinhaltet, Geld zu bezahlen. Eine Migration dieser Kunden auf die neue Architektur kostet auf jeden Fall Zeit (und somit auch Geld).

Ein paar Tipps

  • Im Zweifelsfall einfach als kompliziert: Eine einfache Architektur ist übersichtlicher und leichter verständlich.
  • Nicht zu sehr in die Zukunft schauen: Es ist besser, nicht alle Eventualitäten von Anfang an zu berücksichtigen. Meist kommt es anders als zu Beginn gedacht. Was nicht von Anfang an gebraucht wird aber schon realisiert ist, kostet mehr und macht die Architektur komplizierter.
  • Sind die Module beim Modulbaukasten zu klein, besteht die Gefahr, dass die Architektur zu kompliziert ist. Jedes Modul hat Schnittstellen und kommuniziert mit den anderen Modulen. Je mehr Module es gibt, desto komplexer wird es. Vor lauter Bäumen sehen Sie den Wald nicht mehr. In diesem Fall können mehrere Module zu einem einzigen zusammengefasst werden.

Fazit

  • Parallelen zum Bauwesen erlauben, die Grundzüge einer Software Architektur besser zu verstehen und die richtigen Fragen als Laie zu stellen.
  • Es ist besser, mit einer (zu) einfachen Architektur zu starten und diese zu verfeinern als mit einer (zu) komplizierten.
  • Ein Wechsel der Architektur ist immer mit (hohen) Kosten verbunden und sollte vermieden werden.

Effiziente Software Begutachtung im Detail

Die 3 Kernbereiche Architektur, Schnittstellen und Fremdprodukte werden detaillierter untersucht. Als Grundlage dient der Überblick.

Dieser Teil ist Technik lastig und setzt Programmierkenntnisse voraus.

Geschäftslogik

Die Geschäftslogik muss in sich gekapselt sein. Dies bedeutet, dass sie nicht weiss, wie die Daten gespeichert werden. Sie weiss nur, dass es eine interne Schnittstelle zur Speicherung gibt. Wie die konkrete Umsetzung aussieht (File, Datenbank), darf die Geschäftslogik nicht wissen. Somit kann auf einfache Weise eine Oracle-Datenbank durch eine mySQL-Datenbank ersetzt werden.

Die Geschäftslogik darf auch nicht wissen, ob sie von einer Webanwendung oder einer Mobile App verwendet wird. Oder ob es beides miteinander gibt. Ist diese Trennung garantiert, kann die Benutzeroberfläche ausgetauscht oder es können neue Benutzeroberflächen hinzugefügt werden.

Diese Abhängigkeiten können einfach geprüft werden: Gibt es einen technischen Verweis (Import) zur Datenhaltung oder Benutzeroberfläche? Falls ja, gibt es ein Problem.

Business Logik

Datenhaltung

Die Datenhaltung kümmert sich nur um das Speichern, Suchen und Lesen von Daten. Je nach Anwendung können folgende Punkte wichtig sein:

  • Schnelle Suche von Daten in grossen Tabellen oder in mehreren Tabellen (sog. Joins)
  • Schnelle Speicherung von mehreren tausend Datensätzen auf einmal (sog. Bulk Insert)

Es ist möglich, dass die Geschäftslogik (teilweise) in der Datenbank in Form von Stored Procedures vorhanden ist. Aus Sicht der Wiederverwendbarkeit und des einfacheren Verständnisses bevorzugt der Autor eine Lösung im Programmcode (Java, C#).

Benutzeroberfläche

Jede Art der Benutzeroberfläche hat ihre Eigenheiten. Gemeinsam ist, dass es für jede Art Fremdprodukte gibt, welche die Entwicklungszeit verkürzen und die Qualität steigern. Wenn es sich nicht um eine ganz einfache Benutzeroberfläche handelt, sollte ein Fremdprodukt eingesetzt werden. Sonst wird das Rad nochmals erfunden.

Je nach eingesetztem Fremdprodukt drängt sich eine gewisse technische Struktur auf. Es ist wichtig, diese Struktur festzulegen und einzuhalten. Bei einer Webanwendung mit Angular ist eine Unterteilung in Module, Komponenten, Modelle und Services zwingend. Sonst ist der Code schwer verständlich und kaum erweiterbar.

Schnittstelle Programm

Schnittstellen

Folgende Punkte sind zu beachten:

  • Versionierung: Im Lauf der Zeit gibt es Erweiterungen der Schnittstelle. Jede Erweiterung kann zu Inkompatibilitäten bei den Benutzern (meist andere Programme) führen. Ändert die Datenstruktur, weil es z.B. zusätzliche Daten gibt oder bestehende Daten wegfallen, hat das Auswirkungen bei den Benutzern. Deshalb ist eine Versionierung der Schnittstelle wichtig: Mehrere Versionen werden gleichzeitig unterstützt. So entscheiden die Benutzer selber, wann sie die neue Version verwenden. Ohne Versionierung müssen alle Benutzer gleichzeitig wechseln.
  • Robustheit / Fehlertoleranz: Beim Bezug von Daten muss damit gerechnet werden, dass der Inhalt stark variieren kann. Manchmal gibt es Fehler und es werden nicht alle Daten geliefert. Wichtig ist, dass versucht wird, möglichst alle Daten heraus zu bekommen. Fehler sollen möglichst genau dem Benutzer gemeldet und in ein Logfile geschrieben werden.
  • Kapselung: Bei Problemen mit der Schnittstelle darf nicht die gesamte Anwendung betroffen sein (und nicht mehr funktionieren). Die Datenstruktur der Schnittstelle darf z.B. in der Geschäftslogik nicht bekannt sein. Sonst führen Anpassungen in der Datenstruktur auch zu Anpassungen in der Geschäftslogik. Daten und Methoden der Schnittstelle müssen gekapselt sein.

Komplexe Fremdprodukte

Die einfachen Fremdprodukte werden nicht analysiert, weil diese zu wenig wichtig sind.

Wird ein Fremdprodukt an vielen Stellen in der Anwendung eingesetzt, macht eine Kapselung Sinn. Das kann z.B. ein eigenes Modul fürs Lesen und Erstellen von Excel-Files sein. Innerhalb dieses Moduls wird das Fremdprodukt eingesetzt. Anpassungen (z.B. neue Version) beschränken sich nur auf das eine Modul. Das Fremdprodukt kann auf diese Weise einfacher ausgewechselt werden.

Zusammenfassung

Je nach Komplexität der Anwendung dauert die detaillierte Analyse 1-3 Wochen. Das Resultat sind konkrete Aussagen, was gut ist und was verbessert werden soll. Die Verbesserungsvorschläge beinhalten eine grobe Aufwandschätzung. Das ist für die Planung und das weitere Vorgehen wichtig.

Effiziente Software Begutachtung im Überblick

Haben Sie Ärger mit ihrem Software-Lieferanten oder möchten eine Aussage bezüglich Qualität ihrer Software? Mit ein paar Tagen Aufwand und der Pareto-Regel resultiert eine aussagekräftige Begutachtung. So wird’s gemacht.

Code Review

Die 3 wichtigsten Bereiche sind:

Architektur

Die Architektur resp. Struktur der Software ist von zentraler Bedeutung. Die meisten Anwendungen haben eine Benutzeroberfläche, bilden Firmenprozesse ab und speichern Daten. Dies ist eine sog. 3-Schichten-Architektur:

  • Benutzeroberfläche: Führt den Benutzer zielgerichtet zum gewünschten Ergebnis (Webanwendung, Desktop-Anwendung und/oder mobile Anwendung)
  • Geschäftslogik: Bildet die Firmenprozesse ab. Das Firmen-Wissen steckt in dieser Schicht. Dies ist der wichtigste Teil und muss wieder verwendbar sein.
  • Datenhaltung: Die Daten werden persistent gespeichert (Filesystem, Datenbank).

Die Struktur gibt einen ersten Hinweis auf die Granularität: Ist die Anwendung unterteilt in (zu) viele Unterprojekte oder gibt es ein riesiges Projekt, das alles beinhaltet.

Schnittstellen

Braucht die Anwendung Informationen von fremden Systemen oder liefert sie Informationen an fremde Systeme? Schnittstellen sind heikel. Es ist wichtig, dass diese gekapselt sind, damit Änderungen nicht die gesamte Anwendung betreffen. Und die Software muss robust resp. fehlertolerant sein.

Time for Code Review

Fremdprodukte

Um das Rad nicht neu zu erfinden, werden Fremdprodukte eingesetzt. Die Anzahl eingesetzter Fremdprodukte gibt einen Anhaltspunkt bez. Komplexität der Anwendung. Dabei unterscheide ich 2 Arten:

  • Komplexe Produkte wie z.B. eine Bibliothek zur Erstellung der Benutzeroberfläche oder zur Erstellung von Excel-Files ohne die Installation von Office.
  • Einfache Produkte wie z.B. ein Mapper (kopiert Daten von einem Objekt ins andere, hat keine Logik).

Für beide Arten gilt: Im Lauf der Zeit wird es neuere Versionen geben. Irgendwann muss auf eine neuere Version gewechselt werden. Dabei kann es passieren, dass die neue Version nicht mehr kompatibel ist und es zu einem ungeplanten Mehraufwand kommt. Oder ein Fremdprodukt wird abgekündigt und ein Ersatz muss gesucht werden.

Zusammenfassung

Je nach Grösse und Komplexität der Anwendung ist die grobe Analyse obiger Punkte in 1-3 Tagen gemacht. Das Resultat ist eine Liste mit Punkten zur detaillierten Abklärung.

Die technischen Details sind hier.