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.

Excel-Anwendungen im Unternehmen – Gefahr oder Segen?

Excel bietet mehr als Tabellenkalkulationen: Charts, komplexe Berechnungen oder umfangreiche Formulare sind nur einige Beispiele. Excel ist weit verbreitet und der Quasi-Standard. Es braucht wenig Zeit, um eine Excel-Anwendung zu erstellen.

Neben Excel gibt es die Möglichkeit, massgeschneiderte, firmenspezifische Anwendungen zu entwickeln. Eine solche Anwendung bietet bei gewissen Einsatzgebieten Vorteile. Die Vor- und Nachteile der Ansätze werden gegenübergestellt. Eine Checkliste hilft, die richtige Wahl zu treffen.

 

Excel Anwendung

Checkliste

Die Features beziehen sich auf typische Anwendungen in KMU’s. Die Checkliste ermöglicht eine erste Einschätzung, ob eine Excel-, Desktop oder Webanwendung Sinn macht.

Feature Excel Desktop Webanwendung
Benutzer-führung / Usability Möglich
kann sehr aufwendig sein
Ja
Wizzard: Benutzer füllt Daten in vordefinierter Reihenfolge aus
Navigation: Hilft für  Überblick
Ja
Wizzard: Benutzer füllt Daten in vordefinierter Reihenfolge aus
Navigation: Hilft für  Überblick
Validierung Eingabedaten Möglich

kann sehr aufwendig sein

Ja

Z.B. mit Tooltips, Fehler-meldungen

Ja

Z.B. mit Tooltips, Fehler-meldungen

Benutzer muss jederzeit Zugriff haben Kaum möglich

Zugriff von privat meist unmöglich

Zugriff von mobilen Geräten meist nicht möglich

Kaum möglich

Zugriff von privat meist unmöglich

Zugriff von mobilen Geräten gar nicht möglich

Ja

Zugriff von privat OK

Zugriff von mobilen Geräten OK

Mehrsprachig Kaum möglich

Keine Unterstützung

Ja

Wird von allen gängigen Programmier-sprachen unterstützt

Ja

Wird von allen gängigen Programmier-sprachen unterstützt

Daten von Schnittstellen (extern) holen Kaum möglich Ja

Muss programmiert werden

Ja

Muss programmiert werden

Nachvollzieh-barkeit: Wer hat wann welche Eingaben gemacht Kaum möglich Ja

Muss programmiert werden

Ja

Muss programmiert werden

Integration in Office-Anwendungen Optimal Möglich

Muss programmiert werden

Möglich

Muss programmiert werden

Schutz von Firmen-Wissen Gering

Wer das Excel hat, kennt die Logik

Hoch

Quellcode ist für Aussenstehende nicht verfügbar

Hoch

Quellcode ist für Aussenstehende nicht verfügbar

Modularität: Gleiche Funktionalität nur 1x vorhanden Schwierig

Meist sind die einzelnen Excel-Files isoliert

Möglich

Muss vom Entwickler umgesetzt werden

Möglich

Muss vom Entwickler umgesetzt werden

Immer die neuste Version der Anwendung verwenden Nicht garantiert

Es zirkulieren alte Excel-Sheets

Garantiert.

Benutzer muss Update machen.

Garantiert

Passiert automatisch

Kompatibilität Aufwand gering

Aufwand für verschiedene Excel-Versionen

Aufwand gering

Aufwand für verschiedene Betriebssysteme

Aufwand mittel

Aufwand für verschiedene Browser

Aufwand für erstmalige Entwicklung Gering

Schnelle Fortschritte

Je umfang-reicher desto schwieriger

Mittel

Es braucht Abklärungen bez. Architektur / Struktur

Eher hoch

Es braucht Abklärungen bez. Architektur / Struktur

Hosting

Aufwand für Weiterent-wicklung Mittel

Ab einer gewissen Grösse / Komplexität unübersichtlich

Gering

Voraussetzung: Struktur passt

Gering

Voraussetzung: Struktur passt

Begriffserklärung für diesen Blog

Firmenspezifische Anwendung

Eine Anwendung ist ein Computerprogramm. Eine firmenspezifische Anwendung liefert auf spezifische Anwendungsfälle der Firma eine massgeschneiderte Lösung.

Mit welcher Technologie (Excel, Desktop, Webanwendung) die firmenspezifische Anwendung umgesetzt wird, spielt aus Sicht der Anwender keine Rolle.

Excel-Anwendung

Eine Excel-Anwendung besteht aus einem Excel-File (.xlsx oder .xls). Häufig braucht es Makros, welche mit VBA (Visual Basic for Applications) programmiert werden. Damit die Excel-Anwendung verwendet werden kann, muss Excel auf dem Gerät installiert sein.

Desktop Anwendung

Eine Desktopanwendung wird auf einem bestimmten Gerät (PC, Laptop) installiert. Eine Windows-Anwendung wird typischerweise als Desktopanwendung (exe-File) geliefert und muss vom Benutzer installiert werden.

Webanwendung

Eine Webanwendung braucht keine Installation. Es braucht lediglich einen Browser. Auf Webanwendungen kann auch von mobilen Geräten zugegriffen werden.

Zusammenfassung

Die Checkliste gibt eine erste Einschätzung. Fällt diese klar zugunsten einer Anwendungsart aus, sind keine weiteren Abklärungen nötig. Bei Unsicherheit kann es Sinn machen, zuerst die Excel-Anwendung (als Prototyp) zu erstellen. Zu einem späteren Zeitpunkt kann diese durch eine Desktop- oder Webanwendung ersetzt werden.

IT im KMU – top oder flop?

Gestern ein neuer Release einer Anwendung, heute funktioniert nichts –  diese Erfahrung haben wohl schon viele gemacht – und die IT am liebsten in die Wüste geschickt. Die IT als Kostenfaktor und undurchsichtiges Gebilde? Fehler können nicht vermieden, aber minimiert werden. Voraussetzung ist ein Team aus Fachleuten – IT-Spezialisten,  IT-Generalisten und Business-Verantwortlichen, das mitdenkt, interdisziplinär arbeitet und über den eigenen Tellerrand blickt.

Es ist unbestritten, dass ohne IT nichts mehr läuft und die IT (eine Menge) Geld kostet. Durch die rasante Entwicklung (Stichwort Mobile Geräte) wird es immer schwieriger, den Überblick zu behalten. Grundlegend ist die Kenntnis über den Lebenszyklus einer Anwendung.

Lebenszyklus einer Anwendung

  • Wirtschaftlichkeitsbetrachtung: Was soll die Anwendung tun, welches sind die Hauptfunktionalitäten? Was darf die Anwendung kosten? Daraus werden die einzelnen Anwendungsfälle (Use Cases) abgeleitet.
  • Anforderungsdefinition: Welches sind die Anforderungen an die Anwendung aus Sicht der IT? Ein wesentlicher Schritt ist das ‘Übersetzen’  resp. Transformieren der Business-Anforderungen in IT-Anforderungen. Häufig können aus Kostengründen nicht alle Anforderungen gleichzeitig umgesetzt werden und müssen priorisiert werden.
  • Design: Damit die Anwendung längerfristig rentiert und betrieben werden kann, wird sie in einzelne Bauteile (Komponenten) zerlegt. Die Flexibilität zur Erweiterung der existierenden Bauteile sowie zur Entwicklung neuer Bauteile muss vorhanden sein. Zudem werden die eingesetzten Technologien und Programmiersprachen festgelegt sowie die Schnittstellen definiert. Mit grosser Wahrscheinlichkeit werden für gewisse Funktionalitäten Fremdkomponenten eingesetzt (das Rad muss nicht neu erfunden werden).
  • Entwicklung: Anhand der Design-Vorgaben wird die Anwendung entwickelt.
  • Test: Zuerst werden die einzelnen Komponenten und Subkomponenten  separat getestet. Danach erfolgt der Test auf Anwendungs-Ebene, d.h. es werden die Use Cases aus der Wirtschaftlichkeitsbetrachtung verifiziert.
  • Bereitstellung (Einführung oder Update): Nach erfolgreichen Tests wird die Anwendung bereitgestellt (erstmalige Einführung oder Update).

Je nach Grösse des KMU’s können einzelne Phasen ausgelagert werden (outsourcing).  Die Wirtschaftlichkeitsbetrachtung sowie der Test der Anwendung sollten inhouse gemacht werden: das KMU muss selbst definieren, was die Anwendung tun soll – und dies auch verifizieren.

Fehler frühzeitig vermeiden

Fehler und Fehlerquellen

Fehlerquellen gibt es innerhalb sowie beim Übergang zwischen den einzelnen Phasen. Fehler in den einzelnen Phasen haben unterschiedliche Konsequenzen. Wenn z.B. die Anforderungen falsch oder unvollständig sind, kann das erhebliche Schwierigkeiten zur Folge haben. Wird dies erst in der Testphase bemerkt, muss möglicherweise die gesamte Anwendung umgebaut werden – ein enormer Aufwand mit entsprechenden Kosten. Ein Fehler in der Entwicklung hat meist keinen grösseren Einfluss auf die gesamte Anwendung; vorausgesetzt, das Design ist korrekt.

Zusammenarbeit und Kommunikation

Bei einer Zusammenarbeit mit einem externen Partner ist es wichtig, dass beide Seiten die gleiche Sprache sprechen. Der externe Partner muss genau verstehen, was die Anwendung tun soll. Auf Seite KMU muss jemand das nötige technische Wissen haben, um mit dem externen Partner diskutieren zu können.

Für ein KMU ist es unumgänglich, mindestens einen IT-Generalisten zu haben, der den Lebenszyklus einer Anwendung versteht und mit einem externen Partner zusammen arbeiten kann. Wird die Entwicklung inhouse gemacht, braucht es erfahrene Entwickler, die mitdenken. Es ist nicht möglich, die Vorgaben so genau zu beschreiben, dass kein Interpretationsspielraum besteht.

Um unangenehme Situationen, wie eingangs beschrieben, zu vermeiden, ist es wichtig, dass jedes Teammitglied die Bedürfnisse der anderen versteht. Kommunikation untereinander ist vielfach wichtiger als die verwendeten Technologien.

Zitat Michael Anton: “Ein Programm sollte nicht nur Hand und Fuß, sondern auch Herz und Hirn haben.”