„Eine Prämisse ist eine grundlegende Bedingung, die als Ausgangspunkt für Argumente, Schlussfolgerungen oder Entscheidungen dient. Sie bildet das Fundament für rationale Überlegungen und beeinflusst maßgeblich die Stichhaltigkeit eines Arguments. Prämissen sind in verschiedenen Bereichen wie Philosophie, Wissenschaft und Alltagsentscheidungen von großer Bedeutung.“ (Zitat aus www.BachelorPrint.de)

Wenn ich das in meine Sprache übersetzte, dann sind die nachfolgenden Prämissen das Grundgesetz einer IT-Organisation.

Vorweg: Was bedeutet……

Infrastruktur: beschreibt alle aktiven Komponenten einer Umgebung (on-Premises und Cloud) in Ihrer Gesamtheit. Dazu zählen Netzwerk-Komponenten, Server/Services, Nutzer, Gateways und Firewall-Komponenten. Weiterhin zählen auch alle Benutzergruppen dazu.

Entwickler: In der Infrastruktur sind keine typischen Software Entwickler. Sie setzen aus vorhandenen Methoden und zugekauften Softwareprodukten und Dienstleistungen neue Lösungen anhand der Anforderungen zusammen.

ITSM: IT-Service-Management (ITSM) bezeichnet die Gesamtheit von Maßnahmen und Methoden, die nötig sind, um die bestmögliche Unterstützung von Geschäftsprozessen durch die IT zu gewährleisten ITSM beschreibt Informationstechnik mit dem Focus auf Kunden- und Serviceorientierung. Dazu ist eigentlich genug geschrieben. Ich verweise gerne auf die einschlägige Literatur.

Requirements- Engineering: beschreibt den iterativen Vorgang aus unspezifischen und ungerichteten Erwartungshaltungen spezifische, gerichtete und Abgestimmte Geschäftsanforderungen zu erzeugen.

Genug der Vorrede, jetzt gehts los……

§1 Bewerte die Unternehmensdaten

Die Kernkompetenzen des Unternehmens schlagen sich in den Daten, die tagtäglich produziert werden, nieder. Diese Daten (Kundendaten, Produktionsdaten, Ergebnisse aus Forschung und Entwicklung etc.) dienen nicht nur dem operativen Geschäft, sondern sind Grundlage für alle Aktionen, die das Unternehmen prosperieren lassen und die erzielten Erfolge absichern. Sie sind damit auch Grundlage strategischer Entscheidungen. Außerdem werden mit Ihnen regulatorische Anforderungen erfüllt.

Diese Daten haben einen bestimmten Wert, der zu ermitteln ist. Darüber hinaus muss auch Bewertet werden, welche Schäden entstehen, wenn diese Daten nicht zur Verfügung stehen (Impact)
Beispiele: Für die Herstellung von Daten wurde Arbeitszeit, für die Software, die diese Daten hält wurde Hard- und Software angeschafft und konfektioniert, sowie betrieben. Es lassen sich also Rückschlüsse auf den Wert der Widerherstellung der Daten ziehen.
Fällt eine Datenpool für den operativen Einsatz aus, kann anhand der nicht leistbaren Arbeit festgestellt werden, welcher Schaden dabei entsteht. Eine Grundlage für die Schadensbemessung sind Ausfallzeiten (1h, 4 h, 1Tag 5Tage etc.) oder der Totalausfall mit Neuaufbau der Daten.

§2 Arbeite anhand von (geschäftlichen) Anforderungen

Die Geschäftsführung wie viele Menschen aus den Fachbereichen der Unternehmen machen sich Gedanken zur Weiterentwicklung des Unternehmens. Dabei werden im Idealfall Erwartungshaltungen an die die IT formuliert, die sie in Bits und Bytes umsetzen soll. Diese Erwartungshaltungen sind in der Regel ungerichtet und unspezifiziert. Die Aufgabe ist es nun, diese Erwartungshaltung aufzunehmen und in gerichtete und spezifische Anforderungen (Requirements) umzusetzen. Das ist sicherlich ein harter Weg, der aber bei konsequenter Verfolgung immer zum Ziel und damit zum Erfolg führt.

§3 Kenne alle Stakeholder

Stakeholder sind Personen, die unmittelbar oder mittelbar von einer Aufgabe betroffen und / oder an der Anforderungs- Ermittlung (Requirements- Engineering) beteiligt sind.

Es ist für die Qualität der Anforderungen und den Erfolg einer Aufgabe wichtig, direkte Beziehungen zu den Stakeholdern aufzubauen. Die Übermittlung von Informationen über mehrere Personen, Personenkreise und Institutionen sollte unbedingt vermieden werden.

§4 Definiere eindeutige Ziele

Die Zieldefinition bildet eine künftige zu erreichende Situation des Kunden ab. Somit gehören die Ziele dem Kunden. Ziele sollten im Idealfall vom Kunden formuliert werden. Falls das nicht der Fall ist, müssen die Ziele gemeinsam mit dem Kunden erarbeitet werden. Sie sind unbedingter Teil der Requirements- Engineerings.

Ziele sind:

• spezifisch
• messbar
• akzeptiert
• realistisch
• terminiert
  
  Darüber hinaus sind Ziele immer lösungsneutral formuliert.

§5 Beachte alle Rahmenbedingungen

Wie die Ziele sind die Rahmenbedingungen elementarer Bestandteil des Requirements- Engineerings. Sie bestimmen gemeinsam mit den Zielen und den Requirements den Lösungsraum für den Auftrag.
Rahmenbedingungen können nur unter erheblichen Aufwand oder gar nicht geändert werden. Die Einordnung von Rahmenbedingungen ergibt sich aus ihrem Ursprung. Rahmenbedingungen sind u.a.

• Gesetzte und Verordnungen (NIS2, KRITIS, DS-GVO etc.)
• Compliance-Vorgaben
• Standorte
• bereits eingesetzte Technologien und Methoden
• organisatorische Methoden (z.B. ITSM)
• etc.

§6 Etabliere Kunden-Sensibilität in der IT

Jeder Mitarbeiter außerhalb der IT ist ein Kunde! Wenn das IT-Mitarbeiter verinnerlichen, entsteht (mit der Zeit) ein deutlich verbessertes Verhältnis zwischen den Mitarbeitern der IT und allen anderen Mitarbeitern. Das bessere Verhältnis wird bestimmt von der Kundensicht der IT – Mitarbeiter (Was kann ich tun, damit Du Deinen Job gut machen kannst) und der Mitwirkungspflicht des Kunden ((Was muss Du tun, damit ich meinen Job gut machen kann).

Das ist kein Punkt, der unmittelbar mit der IT-Sicherheit zusammenhängt. Wenn aber dieser Punkt erfüllt wird, werden die Mitarbeiter den Vorgaben der IT eher und nachhaltiger folgen.

§7 Tu was Du sagt und sag was Du tust

Transparenz in den Handlungen der IT für alle Stakeholder ist existentiell für die Akzeptanz Eueres Handelns . Das Bringt die notwendige Transparenz. Verlässlichkeit ist ein weiteres wichtiges Attribut der IT. Das heißt nicht, das nicht auch was schief gehen kann. Nur muss man dann schnell aufklären und einen ehrlichen Lösungsweg skizieren. Auch dieser Punkt zahlt mittelbar auf die Sicherheit ein.

§8 Halte Dich an Standards

Technologische und organisatorische Standards vereinfachen die Entwicklung und den Betrieb einer Infrastruktur enorm. Weitere Vorteile:

• Einfacher Betrieb von Hard- und Softwarekomponenten
• Der notwendige Skill ist am Markt in der Regel verfügbar
• Standards müssen nicht mehr dokumentiert werden, es reichen Referenzen
• Interaktion mit anderen Softwarekomponenten ist einfacher oder wird erst ermöglicht.
• Standardisiere Prozesse stützen sich auf eine breite Wissensbasis. So werden sie einfacher eingeführt und weiterentwickelt.
• Standards ermöglichen erst die sinnvolle Automatisierung von Abläufen
  

§9 Halte die Menge der eingesetzten Tools klein

Es ist nicht sinnvoll, für jede Aufgabe ein vordergründig exakt passendes Tool einzusetzen, da man damit die Wissensbreite unverhältnismäßig aufbläht. Das Team kann dann nur oberflächlich mit den Tools arbeiten. Es ist viel besser, die Toolbasis strategisch zu planen und die Fach-Applikation darauf abzustimmen. Vorteile:

• eingeschränkte Angriffsmöglichkeiten

• Breite Wissensbasis in der Organisation

• stabilerer Betrieb

• Einfachere Automatisierung

§10 Konzentriere Dich auf die wirklich notwendigen Methoden

Die Aufgaben der Entwickler, Administratoren uns Support Mitarbeiter sollen nicht von administrativen und organisatorischen Aufgaben von Ihren Kernaufgaben behindert werden. Außerdem sollen Sie bereits erarbeitete Technologien und Methoden einfach wiederverwenden können.
Deshalb ist es wichtig, die in der IT Organisation eingesetzten Methoden zu konzentrieren und vorhandene technische Methoden so aufzubereiten, das sie einfach einzusetzen sind.

Wichtige technologische Methoden (Auszug)

• Zero Trust Architektur (Security Levels & Security Zonen)
• Beschränkung auf notwendige Kommunikationsverbindungen (Kommunikationsmatrix)
• Authentifizierung und Autorisierung
• Identity Access Management
• Enterprise Access Management
• Certification Management
• Focus auf Multi Tier Applikationen (mindestens bei den strategischen Anwendungen)
• Staging
• ……

Wichtige organisatorische Methoden (Auszug)

• Incident-Management
• Problem-Management
• Change-Management
• Reqirements-Management

§11 Kenne Deine eingesetzten Tools in- und auswendig

Es ist sinnvoll, für jedes eingesetzte Tool einen Product- Owner zu benennen. Er ist der Mastermind für das Tool und die und kann Hilfestellung bei den eingesetzten Methoden geben. Er bildet sich weiter und gibt das erworbene Wissen an seine Kollegen.
Auch bestimmt er in Absprache mit den Stakeholdern , wie das Tool in welchen Szenarien eingesetzt wird. Product- Owner steuert verantwortlich die Pflege gemeinsam mit dem Release-Management und dem Vulnerability-Management.
Übrigens: Ein Product- Owner für jedes Produkt hält die Menge der Tools klein -:).

§12 Schütze alle Identitäten und Traue niemanden

Named-User-Identity
Neben den Daten des Unternehmens sind die Identitäten der zweite große schützenswerte Information im Unternehmen. Sie bilden die Legitimation zur Infrastrukturnutzung für die Mitarbeiter(Named-User-Accounts) und zur Beschränkung der Zugriffsrechte in der täglichen Arbeit auf das wirklich notwendige Maß.

Service-Identity
Es gibt aber in jedem Unternehmen Identitäten, die nicht durch Mitarbeiter aktiv genutzt werden, Sie werden in der Regel zur Authentifizierung automatisierter Aufgaben zwischen zwei Software- Komponenten eingesetzt (Service-Accounts).

Privileged Access Identity
Für Administrationszwecke sind sog. „Privileged Access Accounts“, also Konten mit erhöhten Rechten etabliert. Sie dienen Administratoren zur Wartung und Pflege der eingesetzten Systeme und Tools. Es ist unabdingbar, entsprechende Konzepte (Enterprise Access Management) zu entwickeln und strikt umzusetzen

Computer Identity
Ein weitere Gruppe – und nicht die letzte – sind die Maschinen-Accounts, die zur Authentifizierung von zugelassenen Computern notwendig sind.

Alle Identitäten sind auf unterschiedliche Weise sehr hohen Bedrohungen von außen und innen ausgesetzt. Somit ist die Absicherung durch sicheren architektonischen Aufbau der Infrastruktur, Einhaltung von Sicherheitsvorgaben, und konsequente Überwachung existentiell für den sicheren Betrieb.

Zero Trust
„Zero Trust“ gehört aus meiner Sicht als zentrales Element hier erwähnt. Es soll auf alle Bereiche der IT-Infrastruktur und nicht nur auf Identitäten angewandt werden.

§13 Automatisiere so weit als möglich

Alle Aufgaben die sich als Standard- Aufgaben identifiziert sind, sollten automatisiert werden. Darüber hinaus sind Aufgaben zur Überwachung der Infrastruktur zu automatisieren. Der dritte große Block sind periodisch anfallende Aufgaben, die in den Fachbereichen automatisiert werden können.

Vorteile:
Automation entbindet das Team von Routineaufgaben und stellt Kapazitäten zur Weiterentwicklung der Infrastruktur und des Teams frei.

Alle automatisierten Jobs werden immer in der gleichen Qualität durchgeführt. Sie sind damit – auf positive Weise – berechenbar und verlässlich.

§14 Dokumentiere und überprüfe (regelmäßig) die Dokumentation

Dokumentation ist kein Selbstzweck, sondern dient verschiedenen Ansprüchen. Sie hilft dem Entwickler, die Überblick über die (Teil-) Infrastruktur zu behalten und Details im der Tiefe zu beschreiben. Sie ermöglicht den Wissenstransfer zwischen Kollegen uns unterstützt den reibungslosen Betrieb.

Sie zeigt auch den Reifegrad einer Entwicklung an, so das Stakeholder umfassend, aktuell und eindeutig informiert werden. Sie gibt den Stakeholdern damit die Möglichkeit, die erarbeitete Leistung vor der Inbetriebnahme zu bewerten und ggfls. Änderungen zu erwirken.

§15 Vereinheitlichte die Sprache in der IT und den Fachbereichen

Infrastruktur- Administratoren, Software- Entwickler und Anforderer aus den Fachbereichen benutzten in der Regel zwar die gleiche Sprache, Sie verstehen sich aber nur unzureichend. Der Grund liegt in den verschiedenen kulturellen Ausprägungen, die jeder dieser Bereiche mit sich bringt. Am Ende werden zwar die gleichen Worte benutzt, Ihnen aber unterschiedliche Bedeutungen zugewiesen. Das ist der Anfang von Misserfolg.

§16 Habe den Überblick über die gesamte IT-Infrastruktur – zu jeder Zeit

Es ist unbedingt notwendig, das alle Personen, die Entscheidungen treffen, ein einheitliches und aktuelles Bild der gesamten Infrastruktur haben. Ich habe die Erfahrung gemacht, das Diskussionen über beispielsweise neu einzusetzende Komponenten wesentlich einfacher werden, wenn ein gemeinsames, an eine Wand gepinntes Bild des Status Quo vorliegt. In der Regel müssen solche, recht großen Bilder gedruckt werden, um lesbar alle aktiven Komponenten mit Namen und Beziehungen abbilden zu können.

§17 Weiche nur dann von den Prämissen ab, wenn eine realistische Substituierung angeboten wird.

Diese Prämissen sind die Grundpfeiler aller technologischen und organisatorischen Tätigkeiten in der IT. Sie dürfen nicht verletzt werden, da sonst die Handlungsweise der IT-Organisation unberechenbar und beliebig wird.

Ein Einzelfällen kann es aber vorkommen, das man in Teilen abweichen muss. Um diese Abweichung zu ermöglichen (durch die Abweichung entstehen Mehraufwände) , muss der auslösende Fachbereich entsprechende Substituierungen anbieten.
Das können sein:

• Akzeptanz von Einschränkungen in der Funktionalität
• höher finanzieller Aufwand in Entwicklung und Betrieb
• längere Bearbeitungszeiten
• höheres Risiko

Abweichungen von den Prämissen stellen immer ein Risiko dar. Deshalb müssen sie periodisch überprüft und – wenn möglich – eliminiert werden.

Fazit
Egal welcher Organisationsform man anhängt: Diese Prämissen sind immer hilfreich, um die IT-Organisation in eine definierte Richtung zu bringen. Wichtig ist hierbei die Entwicklung von einfachen Leitsätzen, die sich leicht merken lassen.

——————————————————————————————————————————
Das nächste Kapitel befasst sich mit den technischen und organisatorischen Methoden in einer Management-Landkarte

Ich freue mich auf Eure Kommentare, entweder auf meiner Website oder bei linkedin oder Xing.