Best Practice Softwareentwicklung für einen zentralen IT-Betrieb

kayomo 30. Mai 202214. Juni 2022 0 Comments development, entwicklung, it-betrieb, software

Die Ära von „Administration by Turnschuh“ neigt sich langsam aber sicher dem Ende zu und das ist längst überfällig. Die Anforderungen an einen modernen IT-Betrieb zielen auf Standardisierung und Automatisierung ab. Der Wegfall von Lösungen mit Goldlöckchen und die Reduzierung von manuellen, administrativen Tätigkeiten bedingt aber, dass sich Softwareprodukte auch dazu eignen, in die Systemlandschaft von zentralisierten IT-Organisationen aufgenommen zu werden und sich Softwareentwicklung an einem IT-Betrieb ausrichtet.

In diesem Artikel beschäftigen wir uns damit, dass es für Softwarehersteller auch im Jahr 2022 nicht selbstverständlich ist, diese Anforderungen zu berücksichtigen. Wir zeigen typische Problembereiche aus über 13 Jahren Projekterfahrung in der Bereitstellung und Migration von IT-Verfahren, Fachanwendungen und Client-Applikationen auf und stellen Lösungsansätze für diese vor.

Was ist ein zentraler IT-Betrieb?

Von einem zentralen IT-Betrieb spricht man, wenn eine Abteilung oder Organisation IT-Dienste (Services) für viele Nutzer bzw. Anwender erbringt. Dabei spielt es grds. keine Rolle, ob es sich um eine interne oder externe IT-Organisation handelt. Auch spielen die Größen der leistungsnehmenden und leistungserbringenden Organisationen keine maßgebliche Rolle, da das Verhältnis immer ähnlich ist. Ob Sie in Ihrer Organisation 10 Nutzer und einen Admin haben oder bei 1.000 Nutzern 50 Administratoren, es ist immer das Verhältnis „wenige erbringen für viele“ IT-Leistungen.

Die von einem IT-Betreiber angebotenen Services sind vielfältig und können sich in Art und Umfang, je nach Nutzerbedarfen, unterscheiden. Typische Services sind:

Bereitstellung einer Basis-Infrastruktur
Bereitstellung von Arbeitsplätzen (Notebook, Desktop, Monitor, Drucker, Telefon, etc.)
Benutzermanagement (Nutzerkonten, Emailkonten)
Bereitstellung von Standard-Software (Email, Browser, Grafikprogrammen, Office-Suites, etc.)
Bereitstellung von Web-, Anwendungs- und Datenbankservern für Fachverfahren
und vieles mehr…

Diese Leistungen basieren auf Betriebsstandards und Sicherheitsstandards, die der zentrale IT-Betrieb vorgibt.

Die Leistungen werden gegenüber den Kunden (Nutzern) üblicherweise in Form eines Servicekatalogs angeboten, die dafür einen standardisierten Preis bzw. Verechnungspreis bezahlen. Das ganze Konstrukt basiert darauf, dass standardisierte Leistungen erbracht werden.

Die Softwareentwicklung für einen zentralen IT-Betrieb ist daher extrem praxisrelevant für Hersteller und Betreiber.

Warum sind Betriebsstandards wichtig?

Betriebsstandards sind wichtig, weil deren Einhaltung einen stabilen, sicheren und automatisierbaren IT-Betrieb überhaupt erst ermöglichen. Mehr gibt es dazu eigentlich nicht zu sagen!

Wenn diesen auf der anderen Seite aber nicht die (internen) Kunden und deren Bedürfnisse entgegenstehen würden. Insbesondere betrifft dies das Thema der clientseitigen Anwendungen und serverbasierten Fachverfahren.

Selbstverständlich haben Nutzer die gerechtfertigte Anforderung, dass ihnen fachlich unterstützende Software und Anwendungen durch den IT-Betrieb bereitgestellt werden. Und selbstverständlich hat ein zentraler IT-Betrieb auch die grundsätzliche Pflicht dafür zu sorgen, dass Nutzern fachlich benötigte Software zur Verfügung gestellt wird. Nutzer und IT-Betrieb haben aber das gemeinsame Problem, dass sie sich dazu aus dem Angebot von Standardsoftware von Dritten (Herstellern) bedienen müssen. Es sei denn, es wird gezielt eine passgenaue Individualentwicklung beauftragt.

Und genau diese am Markt erhältliche Standardsoftware, also Produkte, die von einem Hersteller seit Jahren angeboten und gepflegt wird, bereiten im IT-Betrieb häufig Probleme und sind Gegenstand dieses Artikels. Die Softwareentwicklung für einen zentraler IT-Betrieb muss sich ebenfalls an diesen Standards orientieren.

Praxisbericht Standardsoftware am Markt

In der Praxis des IT-Betriebs zeigen sich regelmäßig Probleme beim Einsatz „standardisierter“ Softwareprodukte. In der Konsequenz verletzten diese die vorgegebenen Betriebs- und Sicherheitsstandards und sind daher nicht oder nur mit großem Aufwand in die standardisierte Systemlandschaft des IT-Betreibers zu integrieren.

Jetzt könnte man argumentieren „na dann sind die Standards zu spezifisch oder zu hoch“, aber dieses Argument greift nicht. Betriebs- und Sicherheitsstandards orientieren sich gerade an Standardvorgaben, die zum Beispiel vom BSI (Bundesamt für Sicherheit in der Informationstechnik) empfohlen werden. Und wenn sich ein IT-Betrieb daran orientiert bzw. orientieren muss, warum nicht auch ein Softwarehersteller?

In der Praxis lassen sich folgende Ausprägungen feststellen

je länger die Software am Markt ist, desto problematischer ist häufig die Integration in eine standardisierte Infrastrukturlandschaft
je jünger das Softwareprodukt ist, desto einfacher ist die Integration

Dieser Sachverhalt lässt sich relativ leicht begründen: Je älter der Kern einer Software, umso mehr wurde vom Hersteller vernachlässigt, die Architektur des Softwareprodukts auf die immer weiter steigenden Betriebs- und Sicherheitsstandards über die Jahre hinweg anzupassen. Leider handelt es sich dabei häufig um etablierte Software, insbesondere ist dies in kleineren Branchen bzw. bei Nischensoftware anzutreffen.

Warum also nicht auf ein zeitgemäßes Softwareprodukt setzen, werden Sie vielleicht fragen?

Das Problem ist hier überlicherweise eine über Jahre vorhandene Produkt- bzw. Herstellerbindung.

Anwender möchten sich ungern in eine andere Software einarbeiten, liebgewonnene Anwendungen werden trotz erkennbarer Schwächen als unersetzlich gesehen
Bei einem Produktwechsel steht in der Regel eine Migration der Altdaten in das neue Produkt an, was in der Regel auch problematisch ist und häufig zusätzlich ein Migrationsprojekt erfordert

Irgendwann ist dann aber dennoch die Zeit gekommen, zu der der zentraler IT-Betreiber dann sagt: Das Softwareprodukt xy darf nicht weiter verwendet werden!

Dafür gibt es verschiedene Gründe aus Sicht des IT-Betreiber, wie zum Beispiel:

Die eingesetzte Software / Softwareversion wird vom Hersteller nicht mehr supported oder auch Realität, den Hersteller gibt es mittlerweile gar nicht mehr (=> kein Ansprechpartner im Supportfall vorhanden)
Die eingesetzte Software / Softwareversion ist unter den aktuellen Betriebs- und Sicherheitsstandards technisch nicht mehr lauffähig (=> die Software kann von den Nutzern nicht mehr eingesetzt werden)

Softwareentwicklung für den Einsatz im zentralen IT-Betrieb ist daher ein wichtiges Thema für Hersteller, Nutzer und Betreiber.

Best practice für Hersteller von Softwareprodukten

Bei den folgenden best practice Empfehlungen geht es nicht darum, nach welchen Methoden und mit welchen Architekturen eine Software entwickelt wird. Es wird ausschließlich der Blick auf die Einsatzfähigkeit von Software und Setups im Rahmen einer zentralisierten IT-Umgebung gelegt. Aus diesem Grund ist das Thema DevOps in diesem Kontext auch nicht relevant, da es nicht darum geht, wie etwas, sondern was in die Infrastruktur gebracht wird.

Die Nutzer, bzw. die Fachbereiche oder Organisationen bezahlen monatlich für einen zentralisierten IT-Service. Wenn Software nur mit erheblichen Aufwänden in einer standardisierten Umgebung Lauffähig gemacht werden kann, dann verursacht dies überproportionale Kosten.

Softwareherstellern muss klar werden, dass diese Kosten durchaus auch eine Kauf- bzw. Nicht-Kaufentscheidung für ein Produkt sein können und dass Softwareentwicklung am IT-Betrieb ausgerichtet sein muss!

Wir möchten an dieser Stelle auch auf unsere Blog-Kategorie verweisen, die sich Themen rund um die Entwicklung von Software befasst.

Automatischer Softwareverteilung

In zentralisierten IT-Umgebungen wird Client-Software (lokale Installationen) nicht mehr per Hand installiert, sondern über Mechanismen der automatischen Softwareverteilung. Dafür gibt es mehrere Gründe: Ein IT-Mitarbeiter muss nicht mehr zu einem Arbeitsplatz gehen, um eine Software dort zu installieren und wenn ein Rechner defekt ist, wird der komplette Rechner getauscht und anschließend werden alle vom Nutzer benötigten Softwareprodukte automatisch installiert. Das Ziel ist es, eine möglichst kurze Unterbrechung für den Nutzer zu realisieren.

Die automatische Softwareverteilung funktioniert natürlich nicht, wenn während der Installation zum Beispiel Registrierungs- oder Konfigurationseingaben über Dialoge verlangt werden, die manuell auszufüllen sind. Die Software bzw. das Setup der Software müssen daher eine silent install Option bieten. Es handelt sich dabei um eine Standardfunktion von Installersoftware (die Software, die zum Erstellen eines Setups verwendet wird). Neben dem üblichen Parameter /silent können dem Setup darüber hinaus weitere Konfigurationen oder eine Konfigurationsdatei mit den relevanten Einstellungen mitgegeben werden.

Es ist absolut unverständlich, dass heute immer noch vom Hersteller gepflegte Softwaresetups existieren, die diese Option nicht bieten.

Konfiguration von Basiseinstellungen

In zentralisierten IT-Umgebungen wird ist die Ablage von Daten, Dateien und damit auch von Konfigurationsdateien aus Berechtigungssicht reglementiert. Es gibt Bereiche, in denen haben Nutzer Schreib(- und Leserechte), nur Leserechte oder auch gar keine Rechte. Programme werden in der Regel im Benutzerkontext, also mit den Rechten des ausführenden Benutzers im System, ausgeführt.

Leider gehen Softwarehersteller häufig immer noch davon aus, dass der Anwender die Software im Zweifel „als Administrator ausführen“ startet, um Zugriffprobleme dieser Art zu lösen. NEIN! Speziell in zentralisierten Umgebungen haben Nutzer keine administrativen Rechte, da dies dem Gedanken der Standardisierung widerspricht.

Wenn es also heute immer noch gepflegte Software gibt die meint, vom Nutzer zum Beispiel zu ändernde Konfigurationseinstellungen in eine Datei im Standard-Installationsverzeichnis (C:\Programme oder C:\Programm (x86)) speichern zu müssen, dann hat der Hersteller der Software offenbar grundsätzliche Verständnisprobleme über Programm- bzw. Standardvorgaben von Microsoft und dem Sinn und Zweck von Berechtigungen im Allgemeinen.

Wenn Ihre Software Konfigurationsdateien verwendet, dann bieten Sie eine Möglichkeit, den Ablageort der Konfigurationsdatei frei zu konfigurieren (idealerweise auf einem Fileshare). Damit werden folgende Probleme in der Praxis auf einen Schlag gelöst:

Mehrere Nutzer der Software können auf eine gemeinsame Konfiguration zugreifen
Die Berechtigungen, wer auf diese Datei oder das Verzeichnis, in dem die Datei liegt, können dediziert gemanaged werden. Zum Beispiel kann eine Benutzergruppe angelegt werden, die auf das Ablageverzeichnis berechtigt ist. Neue Nutzer müssen dann nur in diese Gruppe aufgenommen werden.
Grundsätzliche Programm- / Anwendungskonfigurationen lassen sich so auch zentralisieren und über einen nur lesenden Zugriff bereitstellen und müssen nur an einer einzigen Stelle angepasst werden.

Anlegen von Datenbanken

Üblicherweise ist das Anlagen von neuen Datenbanken durch Nutzer und Anwendungen auf zentralen Datenbanksystemen und -clustern unterbunden. Dies hat vor allem ressourcen- und abrechnungstechnische Gründe. Die,von den zentralen Datenbankadministration den „Kunden“ bereitgestellten, Datenbanknutzer haben in der Regel Vollzugriff auf die Datenbank, aber kein DB_CREATE Recht.

Es ist daher fatal, wenn eine Anwendung alternativlos davon ausgeht, dass diese die Datenbank selbständig anlegen kann. In der Praxis bedeutet das dann, das dem Datenbanknutzer temporär das DB_CREATE Recht eingeräumt werden muss. Dies erfordert zusätzlichen Abstimmungsaufwand und bedeutet potenzielle Risiken im IT-Betrieb.

Idealerweise wird daher für das Anlegen der Datenbank vom Hersteller ein Skript bereitgestellt, das dann von den zentralen Datenbankadministration ausgeführt werden kann.

Benutzerspezifische Konfigurationen

Anwendungen bieten häufig die Möglichkeit, dass sich der Nutzer gewisse Anwendungseinstellungen konfigurieren kann. Selbstverständlich sollen diese individuellen Einstellungen dem Nutzer beim nächsten Programmstart wieder zur Verfügung stehen und nicht neu konfiguriert werden müssen. Diese Anwendungseinstellungen müssen daher irgendwo abgespeichert werden.

Sofern diese Einstellungen nicht innerhalb einer Datenbank gespeichert werden, bieten Windows- und unixoide Betriebssysteme dazu verschiedene Ablagebereiche, um diese Einstellungen in Dateiform zu speichern. In diesen Bereichen benötigen die Nutzer keine erweiterten bzw. administrativen Rechte zum Lesen und Schreiben von Konfigurationsdateien. Dies sind insbesondere

%appdata%, Ort der Ablage von benutzerspezifischen Einstellungen des angemeldeten Nutzers unter Windows
%programdata%, gemeinsames Verzeichnis aller Nutzer unter Windows (üblicherweise ein verstecktes Verzeichnis)
Homeverzeichnis (~), benutzerspezifische Einstellungen des angemeldeten Nutzers unter unixoiden Betriebssystemen

Beispiel für die Auflösung der genannten Systemvariablen unter Windows:

C:\Users\kaymo>echo %appdata%
C:\Users\kaymo\AppData\Roaming

C:\Users\kaymo>echo %programdata%
C:\ProgramData

In der Praxis zeigen sich Probleme bei folgenden Eigenschaften von Software:

eine Einzelplatzanwendung, die durch eine zentrale Installation (zum Beispiel unter Citrix) bereitgestellt wird unterscheidet grundsätzlich nicht zwischen verschiedenen Nutzern. Die Einstellungen eines Nutzers werden durch einen anderen überschrieben.
Einstellungen werden in das Installationsverzeichnis der Software geschrieben. Aufgrund mangelnder Berechtigungen des Nutzers dort können die Einstellungen nicht geschrieben werden.
Allgemein, die vorgesehenen Mechanismen des jeweiligen Betriebssystems zur Speicherung von benutzerspezifischen Einstellungen werden nicht genutzt.

Für Windows-Systeme gibt es beispielsweise folgende Übersicht der Eigenschaften und Verzeichnisse, die von Installern genutzt werden können und sollen: Microsoft Installer Referenz

Nutzer- und Gruppennamen

In gut organisierten IT-Organisationen existieren Namenskonventionen. Konventionen erleichtern das Leben allgemein, da diese eine standardisierte Benamung vorgeben und sich häufig aus der Namenskonvention auch Rückschlüsse über den technisch / fachlichen Inhalt schließen lassen.

Speziell in großen Organisationen mit vielen Nutzern sind die Vorgaben zur Pflege eines LDAP oder Active Directory sehr formal und stringent.

Vermeiden Sie daher hart kodierte Vorgaben in diesem Bereich wie „der Nutzer muss nutzer97“ oder „die Berechtigungsgruppe muss NAMEDERSOFTWARE“ heißen.

Passwörter

Auch das Thema der Passwörter fällt unter den Bereich der Konventionen von IT-Organisationen und zusätzlich in den Bereich der Sicherheitsstandards. Üblicherweise werden betriebssystemseitige oder organisationsseitige Vorgaben zur Passwortlänge, Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen verwendet.

Vermeiden Sie innerhalb Ihrer Anwendung daher unbedingt

hart kodierte Passwörter
grds. Einschränkungen zu den Inhalten eines Passworts (z.B. gar keine Sonderzeichen oder nur eingeschränkte Sonderzeichen)

und überlassen Sie entsprechende Vorgaben der Organisation.

Ein weiterer Aspekt ist die Verwendung von Passwörtern, zum Beispiel in Konfigurationsdateien. Vermeiden Sie dort die Verwendung von Klartext-Passwörtern. Nutzen Sie beispielsweise eine anwendungsinterne Verschlüsselungsmethode, um Passwörter als verschlüsselten String in Konfigurationsdateien ablegen zu können. Idealerweise bieten Sie ein kleines Tool zu Ihrer Software mit an, damit der IT-Betreiber selbständig Passwörter vergeben und verschlüsseln kann.

Betriebssysteme

Üblicherweise bieten die zentralen IT-Betreiber verschiedene, standardisierte Betriebssystem-Plattformen an. Wichtig ist zu wissen, dass in der Regel ausschließlich Systeme betrieben werden, für die es einen kommerziellen Support gibt – nämlich für den Fall, in dem der IT-Betreiber selbst in die Situation kommt, Herstellersupport in Anspruch nehmen zu müssen.

Für Windows-Betriebssysteme bedeutet das, dass die üblichen 10-Jahres-Supportzeiträume der von Microsoft unterstützten Versionen zu beachten sind. Bei unixoiden Systemen solche, die einen Long Term Support (LTS) bieten.

Ein anderer Aspekt sind die Kosten, nämlich die Kosten, die für den technischen Betrieb einer Fachanwendung anfallen, also monatlich verrechnet werden. Kosten sind ein maßgeblicher Entscheidungsfaktor für oder gegen den Einsatz eines bestimmten Softwareprodukts. Grundsätzlich kann aus der Praxis heraus festgestellt werden, dass die Bereitstellung von Windows-Servern teurer ist, als die Bereitstellung von unixoiden Servern, analog die Bereitstellung von MS SQL-Server- oder Oracle-Datenbanken im Vergleich zu anderen DBMS. Dies ist allein durch die notwendigen kommerziellen Lizensierungen bedingt (Basislizenz, CALs, etc.).

Sofern es Ihre Anwendungsarchitektur ermöglicht, bieten Sie daher idealerweise alternative Betriebssysteme an.

Lizenzmechanismen

Speziell im Bereich der von Herstellern verwendeten Lizenzmechanismen ergeben sich häufig Probleme und Stolperfallen. Ja, die Entwicklung und Pflege von Software kostet Geld und Hersteller sollen selbstverständlich für ein verwendetes Produkt bezahlt werden (Lizenzgebühren). Das Problem ist aber häufig, dass Softwarehersteller anscheinend denken, ihr Produkt wird von Max Mustermann eingesetzt oder die illegale Nutzung durch Max Mustermann soll durch entsprechende Lizenzmechanismen verhindert werden.

Wir reden hier im Kontext von Organisationen, großen Organisationen, im privaten und im öffentlichen Bereich. Dort dürfen schon grundsätzlich aus Compliance-Gesichtspunkten keine Softwareprodukte oder grundsätzlich Produkte „illegal“ eingesetzt werden. Zumal solche Organisationen in der Regel auch mit dem Kauf gleich einen Support- und Wartungsvertrag abschließen (müssen). Durch Lizenzmechanismen werden ehrliche Kunden also unnötig gegängelt. Wenn dann noch die technische Umsetzung des Lizenzmechanismus in der Betriebsumgebung Probleme bereitet, dann ist das schlecht – vor allem, bei unflexiblen Herstellern, die sich einer Lösungsfindung verwehren.

Die folgenden Arten eines Lizenzmechanismus bereiten in der Praxis bei zentralen IT-Organisationen regelmäßig Probleme:

Hinterlegung von Registrierungsinformationen am Client durch den Endanwender: Insbesondere in virtualisierten Umgebungen und im Mehrbenutzerbetrieb problematisch => welcher Nutzer gibt die Informationen ein, wo werden diese Lizenzinformationen gespeichert, hat der Nutzer überhaupt die notwendigen Rechte, die Information irgendwo zu speichern? Siehe auch das Thema automatische Softwareverteilung und silent Install.
Verwendung von Hardware-IDs: Gerne werden auch Hardware-Informationen wie die MAC-Adresse o. ä. verwendet, um diese mit den Lizenzinformationen zu speichern bzw. zu kombinieren => in virtuellen Umgebungen kann sich die Informationen regelmäßig ändern, werden mehrere Instanzen der Anwendung zum Load-Balancing gefahren existieren unterschiedliche IDs, etc.
Verwendung von Dongles: Bei der Verwendung eines Dongles, als Sicherheitsmechanismus, muss in zentralen Umgebungen dafür ein extra Server bereitgestellt werden, die sogenannten „Dongleserver“. Dies bedeutet wiederum, dass eine Person physisch an den Server muss, um den Dongle dort einzustecken. Verwenden mehrere Fachanwendungen einen Dongle-Mechanismus, dann muss die Donglesoftware des jeweiligen Herstellers auf dem Dongleserver installiert werden, es müssen ausreichend USB-Steckplätze bzw. Erweiterungen eingerichtet werden, etc. Im Endeffekt muss eine eigene kleine Infrastruktur aufgebaut werden, um diesen Lizenzmechanismus bedienen zu können. Und wer zahlt das am Ende? Der Kunde bzw. die Nutzer in der Organisation, die die betreffende Software einsetzen (müssen).
Online-Lizenzprüfung: Dongles werden nur noch von Online-Lizenzprüfungen getoppt. Wenn diese Art der Lizenzenzprüfung ausschließlich von Softwareherstellern angeboten wird zeigt dies völliges Unverständnis über die Anforderungen an Betriebs- und Sicherheitsstandards in IT-Umgebungen => externer Zugriff von außen in geschützte Umgebung notwendig, in der Regel verboten.

Für die im Blickpunkt stehenden zentralen IT-Umgebungen ist es erfahrungsgemäß das Beste, wenn Sie

völlig auf einen technischen Lizenzmechanismus verzichten oder
diesen in Form einer simplen Textdatei abbilden, die beim Start der Anwendung eingelesen und ausgewertet wird (z.B. signierte XML-Datei, damit diese vor Änderungen geschützt ist).

Fazit

Softwareentwicklung für einen zentralen IT-Betrieb ist definitiv ein praxisrelevantes Thema, das von vielen Softwareherstellern leider immer noch verkannt wird.

Softwareprodukte, die sich nur mit Hindernissen in standardisierte IT-Betriebsumgebungen integrieren lassen, verursachen ungeplante und hohe Kosten. Diese Kosten werden wiederum auf die Kunden umgelegt, die diese Software einsetzen wollen. Daher stellen Betriebskosten durchaus ein wichtiges Entscheidungsmerkmal für oder gegen den Einsatz von Softwareprodukten dar.

Wenn Sie vor der Herausforderung stehen, Softwareprodukte und Fachanwendungen in einen zentralen IT-Betrieb überführen bzw. dort betreiben zu müssen, kontaktieren Sie uns gerne bei Fragen. Wir unterstützen Sie dabei gerne.