Am Mittwoch, den 24.04.2019, 18:02 +0200 schrieb Thomas Güttler:
>
> Wenn ich eine Termineinladung per Mail bekomme, kann ich die im
> Thunderbird akzeptieren.
> Dumm ist bloß, dass diese Info ("Thomas G wird teilnehmen") nicht zum
> Einladenden kommt.
>
Ja, wir sind eine ähnliche Route gegangen. Über die Jahre haben und
hatten wir immer einen starken DIY/Selfhosting-Background, haben viel
unserer notwendigen Infrastruktur inhouse betrieben, den überwiegenden
Teil davon auf Linux/Debian. Das hat auch über Jahre hinweg gut
geklappt. Über lange Zeit waren die Mitarbeiter auch "privat" relativ
untechnisiert, haben bestenfalls SMS auf Mobiltelefonen geschrieben und
hatten Technik im Büro.
Spätestens mit den Smartphones, Google, Apple beobachte ich hier
grundlegende Änderungen, die vor allem auch in die Erwartungshaltung an
die Firmen-IT hinein strahlen. Die Nutzer sehen, was möglich ist.
Mithin:
Plötzlich *wollen* die Leute nicht mehr akzeptieren, daß es (in der
Konstruktion mit lokalem SMTP/IMAP-Server und verschiedenen
CalDAV/Groupware-Systemen, die wir in den Jahren probiert haben) über
einen Desktop-Kalender schwierig bis unmöglich ist, (a) die
Terminkalender aller relevanten internen Beteiligten und des
Besprechungsraumes für eine Terminfindung zu sehen, (b) einen Termin
festzulegen, in der einer der Besprechungsräume und alle Beteiligten
verfügbar sind, (c) der dann auch diese Ressourcen, und sei es
vorläufig, "blockt" und (d) nach Empfang/Bestätigung durch die
Beteiligten "verbindlich wird.
Plötzlich *wollen* die Leute auch nicht mehr akzeptieren, daß Instant
Messaging über das lokale XMPP-System auf den Arbeitsplätzen mit
Clients passiert, die wie 1990er-ICQ aussehen und sich auch genau so
bedienen lassen, bei denen der Verlauf bestenfalls "zufällig" zwischen
den Geräten synchronisiert und man unter Umständen auch mal Nachrichten
übersieht, weil der Client entweder beim Minimieren den Konferenzraum
verloren hat oder es nicht für nötig erachtete, eine Benachrichtigung
zu zeigen.
Plötzlich *wollen* die Leute nicht mehr hinnehmen, daß Argumente wie
"Datenschutz", "wir können es selbst betreiben" und "es ist Open-
Source" ins Feld geführt werden als Begründung dafür, daß nur 75% der
Features abgedeckt werden, die andere "marktgängige" Lösungen können,
und vor allem die tatsächlich relevanten Use Cases schlecht bis nicht
funktionieren. Warum auch? Am Ende des Tages legt Dir Google GDPR-
Compliance vor, gibt Dir einen korrekten AV-Vertrag, der ISMS-Mensch
nickt das ab, damit ist doch alles gut...?
Was ist bei uns dann zunächst passiert? Shadow IT. Der interne Chat
wurde den Erwartungshaltungen nicht mehr gerecht, also haben sich die
Leute eine WhatsApp-Gruppe aufgemacht, die Entwickler einen Slack-
Channel (weil sie das auch von Open-Source-Projekten schon kannten) Der
interne Kalender blieb hinter den funktionalen Wünschen zurück, also
haben die Kollegen begonnen, sich selbst mit Google Calendar auf ihren
Androids und im Browser zu helfen, um dienstliche Termine zu
koordinieren. Daneben (ich habe leider nicht die komfortable Situation,
*nicht* für den Betrieb der Infrastruktur verantwortlich zu sein)
merkst Du, wenn Dir eine beliebige Groupware-Komponente (wir haben mit
ownCloud-Erweiterungen wie auch Open-XChange versucht zu arbeiten) bei
einem weiteren Upgrade auf die Füße fällt, daß das Aufrechterhalten
dieser Infrastruktur immer mehr Zeit und Energie kostet, die Dir an
anderen, wichtigeren Stellen (Entwicklung, Betrieb, Optimierung unserer
eigenen Anwendungen und Dienste) einfach fehlt. Erschwerend kommt
hinzu, daß es derzeit nahezu aussichtslos ist, Personal für den
systematischen Betrieb komplexerer Infrastruktur auf Linux-Basis am
Markt zu finden.
Irgendwann bleibt die Frage, wie "low-level" Du benötigte Dienste
selbst betreiben kannst und willst. Ich bin nicht restlos glücklich
über diese Entwicklung, sehe aber im Umkehrschluß auch, daß wir auch in
anderen Bereichen "Spezialisierung" erleben und das Level, unterhalb
dessen man Dienstleistungen einkauft, stückweise "nach oben" rutscht.
Vor Unix war Computing noch sehr massiv an tatsächliche Hardware
gebunden. Mit Unix und später Windows ist die Abstraktion eine Ebene
weiter hoch gerutscht, hat man angefangen, Anwendungen für ein
Betriebssystem, nicht mehr für eine spezielle Maschine zu schreiben.
Mit Virtualisierung haben wir es intern irgendwann geschafft,
Anwendungen auf VM-Basis zu bündeln und auszurollen und haben keine
Zeit mehr damit verschwendet, mit dem IBM-Support darüber zu
diskutieren, daß wir auf dem supporteten e-Series-Servern Debian und
nicht RedHat oder SuSE fahren wollen.
Mittlerweile haben wir Technologien wie docker und lassen die
Entwickler (mit deutlich geringerem administrativen Aufwand und weniger
Reibereien) Anwendungen in Containern packen, die teilweise bei uns,
teilweise in Container-Infrastruktur im RZ unseres Dresdner Providers
laufen. Mit Amazon Lambda, "Function-as-a-service" und dem ganzen Kram
wird sich das absehbar noch ein Stück weiter verändern. Das ist nicht
nur gut... manchmal vermisse ich massiv die Möglichkeit, den gesamten
Stack "in Tiefe" zu durchdringen, zu verstehen, wie die Rädchen
ineinandergreifen und was man wie zu tun hat, damit das Gesamtsystem
läuft. Und: Die Komplexität, die man als gegeben hinnimmt, wird immer
größer, was enorme Risiken birgt.
Auf der anderen Seite eben hat man (in meiner Branche) dann Services
wie Autodesk BIM360 als Kollaborationslösungen, die selbst ein
Großkonzern wie Autodesk als "powered by Amazon Cloud" anpreis - mit
der klaren Aussage: *Selbstverständlich* werden wir uns hüten, dafür
selbst Infrastruktur hochziehen zu wollen, wenn es das besser und
preiswerter, als wir es jemals könnten, am Markt gibt. Wenn das aus der
Erwägung von Autodesk wirtschaftlich so aussieht, stellt sich die Frage
eigentlich gar nicht, wie das für ein KMU rechnen kann. Und dort sind
Betrachtungen wie organisatorischer Aufwand (etwa durch Themen wie
DSGVO, ISMS, ..., oder das dafür notwendige Personal und die
Qualifikationen im Betrieb - dazu fand ich
https://twitter.com/isotopp/status/1009364595084025856 und den
Folgethread sehr treffend) noch gar nicht explizit betont.
Kurzum: Zumindest in meiner Filterblase, zurückkommend zum
Ausgangspunkt, sehe ich, daß sich die Rolle von "IT-Administration"
zunehmend ändert. Tatsächliche "Detail-Experten", Mail-Admins, ...,
wandern zunehmend zu großen Strukturen (bzw. sind auch jetzt kaum noch
am Markt verfügbar). "IT" in Unternehmen wird zunehmend weggehen von
Eigenbetrieb, hin zu Bewertung, Einkauf, Integration, internem Support
von Lösungen, wie das auch in anderen Bereichen passiert: Wieviel
Unternehmen etwa haben jetzt noch eigenen Fuhrpark mit eigenen Kfz und
eigener Werkstatt, die die Fahrzeuge selbst pflegen?
Das wirkliche Problem, das ich bei dieser ganzen Entwicklung sehe, ist,
daß Infrastruktur zunehmend weiter und umfangreicher als bisher von
einzelnen Konzernen abhängig wird, deren Lösungen in dem Treiben
unersetzbar werden. Dagegen hilft FLOSS nicht mehr. Dagegen braucht es
andere Konzepte, wie wir Nutzern, Privatpersonen, Firmen Dienste auf
Augenhöhe mit Google und Amazon, aber ohne Google und Amazon anbieten.
Das wäre auch politische Aufgabe, aber dort (vorsichtig formuliert) tun
sich derzeit alle extrem schwer... :(
Viele Grüße,
Kristian
