Was ist der fundamentale Unterschied zwischen dem Maschienenbau und der Informationstechnologie, die Frage treibt mich nun schon seit Jahren um.

Zunächst ist ersteinmal die Informationstechnologie ohne Hardware nicht wirklich gegenständlich, was der Maschienenbau durchaus ist. In heutiger Zeit ist dann meist auch die Konstruktionszeichnung für die Maschine bzw. deren Unterlagen nicht mehr gegenständlich sondern ein Teil der der IT Mittel.

Welche Vision ist mir einmal vermittelt worden, welche ich heute schmerzlich vermisse, weswegen ich immer Mal wieder gedanklich das Thema in den Fokus bekomme.

Einer meiner Ausbilder in der klassischen Konstruktionslehre als Maschienebau-Prof brachte es auf den Punkt: Während wir in anderen Seminaren erfolgreich und begeistert mit der aufkommenden Rechentechnik Federn und deren Kinamatik mathematisch simulierten, hatte er schon die reale Zukunft im Blick. In der Retrospektive muss ich sagen es war der maschienenbauende Mathemathiker der da fabulierte. Er wusste, das alles nur funktionierte, da bis in die kleinsten Beschreibungen alles normiert war, und auch Neues immer wieder normiert wird.
Er verstieg sich nun zu der Aussage, dass wenn wir Studenten einmal mittem im Leben stehen, die IT genauso funktionieren würde wie seine Erfahrung: eine normgerechte M4 Schraube lässt sich immer mit einer normgerechte M4 Mutter verbinden. Das ganze natürlich auch analog im zöllischen Bereich.

Wie ist es nun aber heute in der IT? wir haben da auf der Ebene der Softwarekomponente die API, welche gewährleistet, dass egal welcher Hersteller diese Komponente gebaut hat, sie wird von einer anderen Kompomente 'normgerecht' benutzt werden können. Insofern ist die Aussage des Prof's auf den ersten Blick richtig.

Nur in der IT sind leider relativ wenig kleinste Beschreibungen normiert, oder anders ausgedrückt die wenigsten in der IT wissen was ein RFC ist, geschweige denn schauen nach ob eine API einem RFC entspricht. 
Da dies so ist, und die mathematische Abhängikeiten den meisten Personen der IT nicht geläufig sind, kommt es hier zu einer wesentlich höheren Projektausfallwahrscheinlichkeit.

Im Maschienenbau kommt es im Prototypen- oder im Testaufbau zu einem Passproblem der Verbindungen, welches zum ersten mit einem beliebeigen anderen den Normen entsprechenden Teil behoben werden kann. Danach wird sich  auch damit beschäftigt werden, für die Serie Ersatz bei einem beliebigen Hersteller zu beschaffen.

In der IT kommen verschiedene Layer an Zuständigkeiten zum Tragen, auch solche, welche das Projekt nur unwesentlich tangieren, Unstimmigkeiten hier lassen die Kosten schnell ins Uferlose anwachsen, da das Teil eben eine Sonderanfertigung ist und keiner Norm unterworfen. Der Projekterfolg ist dann damit nicht mehr gegeben. Es können auch Schäden auftreten, welche im eigentlichen Sinne nicht reparabel sind, wenn sie dann erst in der Produktion zum Vorschein treten.

zb.: Im Microsoft SharePoint Bereich kann man funktional grundsätzlich alles richtig aufbauen, die Ausfallsicherheit ist gegeben auf der Seite des den Benutzer tangierenden Frontends aber auch auf der DatenSenkenSeite dem SQL Server ist alles den Regeln entsprechend. Schon diese ganze Architektur mit ihren unnzähligen API's hält einige Pitfalls bereit. Mit Wissen und Erfahrung ist dem zu begegnen und der mathematische Worst Case ist vermeidbar.
Nun kommt eine Firmenpolicy daher, die vorschreibt, dass jeder Rechner mit einer Antivirensoftware auszustatten sei, also wird vom technischen Personal dem nachgekommen. Dieses Personal ist aber aufgrund mangelnder Fähigkeiten nicht in der Lage, über ihr eigentliches Tun hinaus irgendetwas eigenes zu entwickeln.. Es kommt wie es kommen muss das System läuft zwei Jahre mit einer völlig falschen Version der Antivirensoftware für ein Server-OS, und hinterlässt im SQL Windows Log eineindeutige Spuren. Diese nimmt das Personal zwar war, sie sind aber nicht in der Lage dieses irgendwie zuzuordnen. Irgendwann nach den Jahren erfolgt eine Revision der Software vom Hersteller derselben, der die Hände über dem Kopf zusammenschlägt, weil die aufgetretenen transaktionalen Fehlfunktionen sind natürlich in der DB nicht mehr entfernbar. Die Frage sei hier hypothetisch erlaubt, bekommt ein anderer grosser Fertiger seinen 4nm Prozess möglicherweise nicht ans Fliegen, weil hier Daten unbekannt und unbemerkt sich anders darstellen?

Man könnte nun einwenden, dass bei einer Maschine auch mit dem falschen Oel viel Unheil angerichtet werden kann. Ja, aber je wichtiger diese Oele für die Maschine sind, je mehr Vorkehrung werden bestimmt getroffen, so dass kein falsches Oel an die Lagerstellen gelagen kann.

Nur wie in der Software Industrie dagegen schützen? Eine Entwicklung ist die sogenannte Cloud. Aus meiner Beobachtung ist aber zu sehen, dass es hier auch bei sehr gewichtigen Unternehmungen aufgrund eines zu schlanken Personals zu Auswüchsen kommt, die im Maschinenbau nicht vorkommen könnten. ERGO ist das System IT heute noch lange nicht an dem Punkt wo die gegenständliche Hardware vor 45 Jahen wie selbstverständlich seit vielen vielen Jahern war.
Mein Fazit eine reale Cloud von wissenwollenden technisch interessierten Menschen bereitgestellt ist allemal besser als jedes andere Konstrukt, es mag zwar an manchen Stellen Einschränkungen geben bei der Konfiguration der Systeme, es ist aber Verlass auf diese Systeme.

Überbestimmte Automaten in den Händen von Personen die noch nicht mal wissen, was ein Automat ist, wird es wohl im Maschinenbau nicht geben. Ergo ist es eventuell nicht nur ein Problem der API, sondern eins des sehr häufig anzutreffenden Menschen, der glaubt etwas zu wissen, aber nicht wissen will wie es funktioniert, und trotzdem die Hebel bedient. Das Schlimme daran ist, er merkt es nicht und ist glücklich.

[Update] Die Letztens durch ein Gewitter im Süden der USA aufgetreten weltweiten Störungen im Azure AD Anmeldedienst bringen wiederum andere Überlegungen in den Fokus: MS wird bzw. hat aus diesem Ereigniss gelernt, oder aber, ein möglicher Angriff würde hinter einem Naturereigniss verborgen..

https://www.theregister.co.uk/2018/09/17/azure_outage_report/

Comments


Comments are closed