Die Arbeit der Informatiker

Im Artikel “Reverse Engineering – Re-Engineering” habe ich zwei Arten des Engineerings unterschieden, wovo ich eines als technisch im Sinne der Technik und eines als technisch im Sinne einer Sozialtechnik auffasse. Ich will den Unterschied nochmals auf einer anderen Ebene beobachten. Als “Informatiker” kann ich jemanden sehen, der eine entsprechende Ausbildung hat, egal was er arbeitet, oder jemanden, der Software produziert, egal welche Ausbildung er hat.

Diese Unterscheidung hat in unserer Gesellschaft keine Praxis. Sehr viele Hochschulinformatiker sind sehr rasch im Management von Informatikabteilungen von Banken und dergleichen. Dort kaufen sie die neusten Computer und stellen Prgrammier an und kümmern sich um Bilanzen von einzelnen Projekten. Das heisst sie arbeiten als Manager, aber viele sehen sich dabei als Informatiker. In dieser Praxis sind wohl alle Übergänge fliessend, und von Übergängen kann man ja ohnehin nur sprechen, wenn man zuvor unterschieden hat, was die Praxis ja gerade nicht tut.

Ich tue es trotzdem, weil mich das Business nicht interessiert. Mich interessiert die Technik und mithin Informatiker als technisch arbeitende Ingenieure. Mit technisch arbeiten meine ich in diesem Sinne das umfassende Herstellen von Software im Unterschied zu Management”arbeiten”, wo es um Firmenführung, Personalführung, betriebliche Organisation usw geht.

Diese Unterscheidung macht keinen Sinn, wenn man wie F. Taylor explizit Maschinen und Menschen als Zahnräder einer Organisation auffasst. Dann denkt man in einem Bereich des “Soziotechnischen Systems” von G. Ropohl, das der Soziologe T. Veblen als Technokratie beschrieben hat. In diesem Mainstream erscheint Technik nie als Technik, dafür erscheint buchstäblich alles als technisch – bishin zum Regierungsgeschäft, das schon Plato als Technik des Steuern eines Schiffes (Kybernetes) begriffen hat, wobei auch er den Kapität und den Steuermann nicht auseinander gehalten hatte.

Jede Software ist als technisches Produkt eine Maschine. Wenn Informatiker technisch arbeiten, analysieren sie was die programmierten Maschinen schliesslich machen, wenn sie in der SAPisierung arbeiten, analysieren sie à la Taylorwie die Firmen- oder die Personalstruktur so umgestaltet werden muss, so dass sie zur jeweiligen Software passt.

Das kapitalistisch gedachte Business repräsentiert die Ideologie, die ich hier als SAPisierung bezeichne, wonach das BusinessProcessing Software und Betriebsstruktur auf einander abstimmen müsse. Und Informatiker, die innerhalb dieser Ideologie denken, sehen sich als Vermittler, die mit ihren Computerprogrammen Betriebsabläufe modellieren. Computerprogramme kann man aber aber auch jenseits von sochen Wahnvorstellungen als sich selbstbeschreibende Maschinenteile sehen. Und dann sieht man die Arbeit der Informatiker als Konstruieren von Maschinen.

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Peter Bormann  On June 9, 2012 at 12:44 PM

    1) Ideologie als “Wahnvorstellung”
    Dir ist aber schon klar, daß das ein Beispiel dafür ist, daß Du Dich in einer “jahrhundertealten” Traditionslinie der Ideologie- und Latenzkritik bewegst, die auf die aufklärerische Unterscheidung von “Verkennen – Erkennen” und die Sein-Schein-Semantik der Philosophie zurückgeführt werden kann?
    Soviel nur dazu, daß Du als radikaler Radikalkonstruktivist “nichts” mit begriffs- und theoriegeschichtlichen Traditionen zu schaffen hast…
    Unabhängig davon hat sich diese Ideologieauffassung (Verkennen als Halluzination, Pseudowissen, Wahn, usw. usf.) als theoretisch und wissenschaftlich “unfruchtbar” herausgestellt. Sie taugt nur im Rahmen einer erkenntnisarmen (öffentlichen) “Diskreditierungsrhetorik”.
    Man kommt m.E. weiter, wenn man “Ideologie” re-spezifiziert als eine bestimmte Selbstbeschreibungsweise sozialer Systeme (hier: von Organisationen), die auf diverse Weise Kontingenz invisibilisiert und dadurch u.a. eine Handlungsorientierung ermöglicht. Dann sind Organisationsideologien z.B.:
    * Firmen sind primär dazu da, Profit zu erwirtschaften
    * Organisationen sind rationale Zweck-Mittel-Zusammenhänge
    * In Organisationen kommt es primär auf Leistung bei der Karriere an
    * Organisationen sind Maschinen
    etc.
    Diese handlungsorientierenden Ideologien sind wiederum zu beziehen auf:
    * Entscheidungskommunikation
    * Mikropolitik
    * Kultur
    * Gedächtnis
    in Organisationen.
    2) “Wenn Informatiker technisch arbeiten, analysieren sie was die programmierten Maschinen schliesslich machen, wenn sie in der SAPisierung arbeiten, analysieren sie à la Taylorwie die Firmen- oder die Personalstruktur so umgestaltet werden muss, so dass sie zur jeweiligen Software passt.”
    No, sir. In der von Dir als “SAPisierung” bezeichnete Ideologie besteht immer noch das sog. “business-IT gap”. Und das heißt, es sind Fachbereichsexperten (idR “keine” ITler) die Business Processes fachlich erfassen (analysieren, dokumentieren, optimieren). ITlern fehlt dazu meist das domänenspezifische Wissen (Ausnahme vielleicht manche Wirtschaftsinformatiker) .
    Wenn ITler anfangen, diese Business Processes zu modellieren, dann geht es um “technischer Verfeinerung, Testen und Ausführung solcher Prozesse” (Programmieren inkl.). Und das heißt: Es geht um die Orientierung an Software, die auf entspr. Maschinen (Process Engines) ablaufen soll.
    En bref, die “Trennung” von IT und Fachbereich wird auch in der Business-(Process)-Engineering (Deiner “SAPisierungs-Ideologie”) aufrecht erhalten. Daher auch der stetige Verweis auf das “business – IT gap”!
    Daß es nun Aufgabe von Software-Entwicklern / Programmierern sein soll, die Organisationsstruktur zu verändern, halte ich für Deine weder wissens- noch erfahrungsgesättigte “Projektion”. Denn IT-guys haben dafür weder die Qualifikation / Kompetenz noch die Erfahrung – zumal es einfach “nicht” ihr Job ist.
    Das machen eher Manager, Organisationsberater, Consulter, u. dgl. – zumal das massiv organisatorische Mikropolitik beinhaltet. Und ich kenne kaum ITler, die dieses Thema sonderlich “schätzen”!
    3) Es steht jedoch noch etwas anderes zur Debatte – nämlich, daß Nicht-ITLer (also: bestimmte Fachbereichsexperten) selbst Software entwickeln, so daß man weniger teure Software-Entwickler benötigt. Die Fachbereichsexperten würden also selbst Geschäftsprozesse sowohl fachlich als auch technisch modellieren und diese dann ggf. als Software auf Process Engines ausführen lassen. Das war zumindest eine der Hoffnungen bei der modellgetriebenen Entwicklung im enterprise computing.
    Ich glaube freilich, daß das nur “sehr eingeschränkt” möglich ist. Denn die Nicht-ITler müssen selbst immer mehr in eine IT-Rolle schlüpfen, wenn’s um “technisches” Modellieren, Testen, Codieren, usf. geht.
    Nur: welche Organisation ist lebensmüde genug, Business Processes seitens Informatik-Laien in ihre Produktivsysteme einspielen zu lassen?
    Je komplexer daher die Fachbereiche einerseits und die technische Infrastruktur andererseits sind, desto unwahrscheinlicher ist es, das business-IT-gap zu schließen. Weder können ITler komplett die Fachbereichsexperten ersetzen, noch können letztere komplett Softwareentwicklungs- und Modellierungsaufgaben übernehmen. Dementsprechend bleiben auch zwei prinzipiell unterschiedliche Rollenprofile, nämlich: ” Fachexperten – ITexperten”, erhalten. Es ist dabei sogar “egal”, ob eine Person beide Rollen erfüllen kann. Denn es kommt auf die Rollendifferenzierung an! Aber aufgrund der dabei auftretenden immensen Komplexität geht die Rollen- idR auch mit einer Personen-Differenzierung einher.
    4) Mit Blick auf Voranstehendes bleibt die Aufgabe der IT immer noch das “Konstruieren, Warten, Testen und Benutzen von Soft- und Hardware-Maschinen.” Das gilt sowohl im Rahmen des Business Process Engineering als auch unabhängig von dieser Ideologie.
    5) Und wenn ITler Managementpositionen besetzen, dann ist es letztlich “egal”, ob sie sich als ITler sehen oder nicht. Denn Management-Rollen “verlangen” Managementtätigkeiten (Führen, Planen, Organisieren, Kommunizieren, etc.), aber keine IT-Tätigkeiten (Analysieren und Erfassen von Software-Anforderungen, Prototypen erstellen, Designen, Codieren, Testen, usf.).
    Störend (auch demotivierend) wird es nur dann, wenn IT-Manager (als ehemalige Entwickler) schließlich ihren unterstellten Entwicklern vorschreiben wollen, wie sie ihren Job zu tun haben.
    Ähnliches Beispiel: Ein General wird Politiker – und tritt auch mit seiner Uniform
    öffentlich auf. Er mag sich selbst immer noch als Militär sehen. Aber insofern er sich in politischen Arenen bewegen muß, wird er “politisch” beobachtet und bewertet.
    Er könnte sich auch ein Hasenkostüm anziehen und sich für einen Hasen halten. Trotzdem würden seine Verlautbarungen immer noch “politisch” interpretiert werden – zumindest bis zur evtl. Einlieferung in die Psychiatrie :-)

  • kybernetiks  On June 9, 2012 at 9:52 PM

    Peter, Deine ganze Argumentation beruht darauf, dass in der Industrie ganz und gar unklar ist, inwiefern ein Informatiker als Informatiker oder als Manager arbeitet. Ich habe aber meine Unterscheidung bezeichnet:
    Mir geht es EINERSEITS um DIE Informatiker, die mich hier nicht interessieren, weil sie als Manager fungieren und ANDRERSEITS um DIE Informatiker, die mich interessieren, weil sie Maschinen (Software) herstellen.
    Das de Industrie diese Idealtypen vermischt und vermengt, ist mir klar – und dass Leute, die dann in solchen Vermengungen stecken, entsprechende Ideologien brauchen, habe ich nebenbei geschrieben, um den Verweise auf – wie es wirklich ist – etwas zu entspannen.
    Du kannst also in bezug auf Businesswelten in allem und jedem gerne recht haben. Ich widerspreche nicht, weil es mich nicht interessiert. Mich interessiert der Informatiker als Hersteller von Software – ich schreibe jetzt mal etwas präziser, was ich damit meine im nächsten Beitrag.

    • Peter Bormann  On June 10, 2012 at 9:51 AM

      > Peter, Deine ganze Argumentation beruht darauf, dass in der Industrie ganz und gar unklar ist, inwiefern ein Informatiker als
      Informatiker
      > oder als Manager arbeitet. Ich habe aber meine Unterscheidung bezeichnet:
      > Mir geht es EINERSEITS um DIE Informatiker, die mich hier nicht interessieren, weil sie als Manager fungieren und ANDRERSEITS um DIE
      > Informatiker, die mich interessieren, weil sie Maschinen (Software) herstellen.
      Rolf, ich frage mich, ob das nicht eine “Gespensterdebatte” ist. Denn ich stimme zu: Techies kümmern sich um “technische” Aufgaben (Hard- und Software). Sobald sie sich bspw. mit Planen, Organisieren, Kalkulieren, etc. als IT-(Projekt-)Manager, CIOs u.ä. befassen, sind das keine “technischen” Aufgaben mehr. Es ist dann m.E. eher wurscht, ob man sich in einer Management-Position als ITler sieht oder nicht – denn man hat Managementaufgaben zu erledigen und wird auch dementsprechend beurteilt / beobachtet.
      Mit der These, daß sich ITler – im Rahmen von Biz (Process) Engineering – um Organisationsumgestaltung, Veränderung der Personalstruktur, u.ä. befassen sollen, kann ich dagegen “null” anfangen. Das machen ITler idR einfach nicht (wie gesagt: keine Kompetenz, keine Erfahrung, kein Interesse) – es sei denn: sie bedienen bspw. Managementfunktionen, aber dann spielt hierbei die IT-Qualifikation keine grosse Rolle.
      Nur nebenbei: ITler werden für Managementaufgaben idR auch “nicht” ausgebildet. Das sieht m.E. wohl “kein” Informatik-Studium vor. Man wächst da rein – oder auch nicht.

      “Das de Industrie diese Idealtypen vermischt und vermengt, ist mir klar – und dass Leute, die dann in solchen Vermengungen stecken, entsprechende Ideologien brauchen,”
      Ich frage mich, ob das nicht Deine “phantasievolle” Eigenkreation ist. Wie gesagt: selbst bei Deiner sog. “SAPisierungsideologie” existiert das business-IT-gap. Daß man dann Ideologie “braucht”, um solche Vermengungen zu ertragen, ist gleichfalls nicht nachvollziehbar. Denn erstens bedienen Ideologien in sozialen Systemen ganz andere Funktionen (v.a. Handlungsorientierung) und, zweitens, lassen sich in diesem Bereich business- und IT-orientierte Rollen sehr gut differenzieren. Das ist irgendwie “Dein” Problem, das Du Dir selbst geschaffen hast.

      Aber wenn Du meinst noch einen Artikel dazu schreiben zu müssen, wie Informatiker angeblich im enterprise computing in ideologischer Verwirrung arbeiten. Nur zu: es ist immer schön, einen radikalen “Konstruktivisten” dabei zuzusehen, wie er mich / uns über die wirkliche Wirklichkeit aufklärt. Lustig nur, daß Du nicht erkennst, wie Deine Kreuzung von Ideologieauffassung (Verkennen / Erkennen) und Konstruktivismus radikal ins komplett “Traditionelle” umschlägt :-)

  • kybernetiks  On June 10, 2012 at 11:34 AM

    ok, Peter, ich glaube, wir haben da ein Durcheinander in unseren Bezeichnungen. Ich versuchs Mal etwas “extern”: Mehr als 60% der ETH-Maschinenbauingenieure über 45 Jahre arbeiten so eindeutig spezifiziert in Managementpositionen, dass sie absolut keine konstruktive Tätigkeit mehr ausführen.
    Und was Du als meine Fantasie bezeichnest ist in der Tat meine Verallgemeinerung von Maschineningenieure auf alle Ingenieure.
    Aber anyway: Ich brauche diese Beschreibung ja ausschliesslich zur Unterscheidung von technischer und nicht technischer Arbeit. Ich glaube, dass ich so die Redeweise “technisch” etwas einkreisen kann.
    Mein nächster Beitrag befasst sich nicht mit “enterprise-schnickschnack” sondern mit Technik gerade jenseits davon.

    • Peter Bormann  On June 10, 2012 at 12:03 PM

      > Mehr als 60% der ETH-Maschinenbauingenieure über 45 Jahre arbeiten so eindeutig spezifiziert in Managementpositionen,
      > dass sie absolut keine konstruktive Tätigkeit mehr ausführen.
      Ich habe gerade keine Statistiken parat, aber für Uni-Informatiker – ab einem gewissen Alter –
      mag es so ähnlich aussehen. Freilich haben nicht alle Softwareentwickler ein Hochschulstudium
      absolviert (auch in der Schweiz nicht, nehme ich an).

      Zudem: Selbst wenn Techies in Management-Positionen arbeiten, kann ich keinerlei ideologische
      Verwirrung erkennen. Niemand erwartet von einem IT-Manager, daß er selber noch codet, modelliert
      und testet. Und ich kann nicht sehen, daß Software-Entwicklungstätigkeiten beim Managen von Teams,
      in der organisatorischen Mikropolitik, in Kundenkontakten, u.ä. gefragt sind.

      Und selbst im Rahmen der “SAPisierungsideologie” bzw. im Rahmen von Business (Process) Engineering
      ist m.E. die Differenzierung von nicht-technischen = fachlichen und technischen (software-
      orientierten) Tätigkeiten und Rollen relativ “klar”. Es gibt da keine Verwirrung, Verblendung,
      oder sonst irgend etwas.

      Irgendwie scheint Dich zu beschäftigen, daß Techies als Manager arbeiten. Warum? Uni-BWLer
      haben (idR) auch “keine” Ausbildung als Manager – und arbeiten trotzdem in solchen Positionen.
      Das betriebswirtschaftliches Wissen mitunter dabei hilfreich ist, ist unbestritten. Aber zu
      Managementaufgaben gehören noch ganz andere Qualitäten wie die gerne zitierten “soft skills”
      (Präsentation, Selbstinszenierung, Konfliktmoderation, Führungsfähigkeit, Teamfähigkeit, diplo-
      matisches bzw. mikropolitisches Geschick, Rhetorikerfahrungen, Delegierenkönnen, u.v.a.m.).

      Ich wiederhole mich: Die Diskussion, wer nun wie als Techie und Manager arbeitet oder nicht und
      dabei ideologisch verwirrt, verblendet, deprimiert oder sonst irgend etwas ist,
      leuchtet mir weniger und weniger ein.

      Vielleicht ein Konsensangebot: ITler “arbeiten” letztlich soft- und hardware-orientiert.
      Sie “arbeiten faktisch” so – bilden sich das also nicht irgendwie ein, während sie eine
      Managerrolle spielen.
      Und nachdem das geklärt ist, können wir uns der Technik als Funktionssystem widmen?

  • kybernetiks  On June 10, 2012 at 12:54 PM

    ok, das machen wir ;-)
    und ich schreibe trotzdem noch etwas zu “Technik”, ein bisschen eine gemeinsame Ahnung unserer Verwendung des Wortes müssten wir vielleicht haben, wenn aus dem Funktionssystem was werden soll. Wir könnten ja schlecht ein Funktionssystem “jdhjfdjh” beschreiben. Wir werden sehen.

    • Peter Bormann  On June 10, 2012 at 1:13 PM

      Kurz noch zwei Dinge, bevor ich den Rechner ausschalte:

      1) Vielleicht müssen wir mehr sagen, woher unsere “Erfahrungen” jeweils kommen, wenn wir über Technik / Techniker sprechen. Ich bin stark an enterprise computing orientiert (Java EE, model-driven SOAs, technische Modellierung und Ausführung von Geschäftsprozessen). Aber es ist die Frage, wie weit solche Orientierungen schon innerhalb der Software-Entwicklung “generalisierbar” sind.

      Dein Hinweis auf ETH-“Maschinenbau-Ingenieure” hat mich jedenfalls überrascht. Ich wußte gar nicht, daß Du Dich in dem Bereich auskennst und diese Erfahrungen für Ingenieure generalisiert hast.

      2) > und ich schreibe trotzdem noch etwas zu “Technik”
      Fein.

      > Wir könnten ja schlecht ein Funktionssystem “jdhjfdjh” beschreiben.
      Ich denke, Alltagsannahmen von dem, was wir unter “Technischem” verstehen,
      laufen immer mit. Aber ich würde stur den heuristischen Kriterienkatalog für Funktionssysteme durchspielen wollen – und dann freier “herumspielen” (mit Blick auf basale technicité, kybernetischen Mechanismus, usf.).

      Wie und ob das alles zusammenpassen kann – no idea. Aber das macht ja gerade den Reiz aus: Einfach `mal lostapsen – und sich wundern, wo man landet…

      Übrigens sind wir nicht allein: Leute wie Kevin Kelly (mit seinem “Technium”) interessieren sich auch für solche systemischen Fragestellungen. Vielleicht kann ich demnächst einen Post dazu einstreuen.

      In diesem Sinne
      ~ Peter

Feedback ist erwünscht!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: