Dienstag, 30. August 2016

Software Engineering in Deutschland ̶ eine kritische Bestandsaufnahme (Version 2)

Anlässlich eines Dagstuhl-Workshops im Oktober 2005 entstand ein Manifest [1], das außer von den vier Autoren Manfred Broy, Matthias Jarke, Manfred Nagl und Dieter Rombach noch von weiteren 30 Kollegen unterschrieben wurde. Das sind fast alle Inhaber von deutschen Universitätslehrstühlen in Softwaretechnik bzw. Software Engineering. Als ich für meinen letzten Blog-Beitrag das Manifest wieder einmal las, stimmten mich einige Aussagen doch etwas nachdenklich. Ich nahm mir vor, sie mit einigen Kollegen zu diskutieren. Ich will dies in der Form eines Gruppen-Interviews tun, und zwar in diesem Blog.

Alle mir etwas auffällig erscheinenden Aussagen in dem Manifest hatte ich zunächst in Kurzform übernommen. Ich habe sie in kursiver Schrift vorneweg gestellt. Ich habe eine stichwortartige Überschrift hinzugefügt. Anschließend habe ich in jedem Fall einige Fragen formuliert, die mich bewegen. Zur Beantwortung habe ich mir bekannte Kolleginnen und Kollegen eingeladen. Die Antworten sind hier alle aufgeführt, und zwar mit oder ohne Namen des Beitragenden, ganz nach Wunsch. 

Die ersten drei Antworten kamen vom Kollegen Christof Ebert in Stuttgart (am 30.8.). Der Beitrag von Peter Mertens aus Nürnberg folgte als nächster (am 3.9.). Eine sehr ausführliche Antwort kam von Manfred Broy (am 12.9.). Er schlug unter anderem vor den Originaltext des Manifests zu zitieren und nicht meine (nicht immer gelungene) Paraphrase. Das habe ich jetzt geändert. Platz ist ja kein Argument, eher die Übersichtlichkeit. Barbara Paech aus Heidelberg hat sich (am 22.9.) noch der beiden Zusatzfragen am Schluss angenommen.

Aktuelle Erfolgsmaßstäbe

Software Engineering (abgekürzt SE, deutsch Softwaretechnik) auf Weltniveau ist die Voraussetzung dafür, dass Deutschland seine führende Stellung im Ingenieurbereich (z.B. Export-Weltmeister im Maschinenbau) halten und ausbauen bzw. eine entsprechende Position in neuen Sparten (z.B. e-Health) aufbauen kann. 

Bertal Dresen (BD): Welche Qualitätsziele halten Sie heute für relevant und angemessen (wie z. B. Fehlerfreiheit, Zuverlässigkeit, Änderungsfreundlichkeit)? Welche Maße sollen zur Anwendung kommen und welche Schwellwerte sind derzeit erreichbar bzw. akzeptabel? Wie sieht es heute bezüglich Produktivitätszielen aus? Welche Maße bevorzugen Sie (z. B. LOC, Function Points)? Müssen Metriken stärker in der Ausbildung verankert werden? Teilen Sie meine Meinung, dass die Produktivität an Bedeutung verliert, sobald auch der Wert eines Produkts in Betracht gezogen wird?

Christof Ebert (CE): Das sind viele Fragen, und viele sind heute beantwortet. Qualitätsziele werden für das Projekt oder Produkt festgelegt und durch Standards unterstützt,  beispielsweise funktionale Sicherheit oder Benutzbarkeit. Auch das Software-Volumen hat inzwischen seine durch ISO abgedeckten Standards, auf Basis der Function Points. Produktivität wird heute grundsätzlich wertorientiert gemessen, denn Softwarezeilen pro Stunde und andere solcher Maße sind ziemlicher Quatsch. Die Standardisierung mit ISO hat die Informatik professioneller gemacht. Standards zählen heute zum Kanon des „State oft the Art“ und sind damit vor Gericht, beispielsweise bei der Produkthaftung, relevant. Kritisch bleibt, dass in der Ausbildung und Industrie zu wenig empirisch gearbeitet wird. Kennzahlen sind ad-hoc, und die wenigsten Unternehmen haben belastbare Erfahrungsdatenbanken.

Peter Mertens:  Im Hinblick auf die  weitere Integration  von IT-Systemen in Unternehmen, in Institutionen der öffentlichen Verwaltung und selbst in Haushalten, auf eingebettete Systeme, auf Verbindung von Informationstechnik und Mechanik sowie  mit Blick darauf, dass sich immer mehr zum Teil wenig geschulte  Menschen (z. B. Sparkassenkunden) zwangsläufig mit IT-Systemen befassen müssen, scheint mir vordringlich: Viel gründlicher und geduldiger  als bisher üblich müssen die Apps, Programme und Systeme, die "auf die Menschheit losgelassen" werden, ausgetestet sein. Das hätte zur Folge, dass die Zeitspannen zwischen "Updates" sehr viel länger werden als momentan üblich. Angestrebt werden sollte z. B., dass die Software im PKW mindestens so lange fehlerfrei arbeitet, wie das durchschnittliche Wartungsintervall des Fahrzeugs ist. Dann könnte die Werkstatt die nächste Version fachmännisch aufspielen und die Fahrzeugeigentümer müssten sich nicht alle paar Monate mit den Problemen und den Tücken der Softwareimplementation auseinandersetzen und hierfür viel Freizeit opfern.

Dass  sich umgekehrt  Hersteller von Gebrauchsgütern aller Art  ̶  ich denke z. B. an eine Aussage des Vorstandsvorsitzenden eines bedeutenden deutschen Fahrzeugproduzenten  ̶  dafür aussprechen, im Interesse der Geschwindigkeit ("Time to Market") den  Entwurf und  Bau ihrer Erzeugnisse  dem momentan unbefriedigenden Perfektionsgrad der Softwareproduktion anzunähern, halte ich für den falschen Weg und nachgerade für eine Reduktion der Wohlfahrt im Staat. Kurzum: Auch bei der verkauften Software jene Reife, die man physischen Produkten "Made in Germany" (oder Austria oder "Swiss made") weltweit oft attestiert.

BD: Peter Denning (Jahrgang 1942) rüttelte in einem Beitrag in den CACM (Heft 59,9, 9/2016) an den von ISO standardisierten (und von Christof Ebert zitierten) Qualitätskriterien. Anstatt ihrer schlägt er sechs Stufen vor, die stärker die Nutzersicht als die Entwicklersicht berücksichtigen. Sie sind in der folgenden Tabelle zusammengefasst.



Die unteren zwei Stufen sind negative Maße, die oberen vier sind aufsteigend positiv. Man sollte über sie diskutieren.

Manfred Broy (MB): In den letzten Jahren sind sehr differenzierte Qualitätsmodelle, auch nicht zuletzt durch meine eigenen Forschungsarbeiten, entwickelt worden. Ein besonderes Augenmerk haben wir auf das Thema der Wartbarkeit gelegt. Ein Start-Up aus meiner Forschungsgruppe, die CQSE, ist hier aus meiner Sicht am absoluten 'leading-edge' in Praxis und Theorie. Was Produktivitätsziele betrifft, so halte ich alle Metriken für Krücken. Allerdings meine ich, dass Metriken stärker in der Ausbildung verankert sind. Das lässt sich auch, soweit es meine Lehre betrifft, gerne nachweisen. Sie brauchen nur mein vor wenigen Jahren erschienenes Buch zum Thema Projektorganisation und Management [2] lesen. Dann sehen Sie, welche Bedeutung dort den Metriken eingeräumt wird. Der letzte Satz, dass Produktivität an Bedeutung verliert sobald der Wert eines Produktes in Betracht gezogen wird, ist eine Binsenweisheit.

Vergleich Maschinenbau

Damit erfolgversprechende Forschungsprojekte realisiert werden können, muss eine Zusammenarbeit mit Ingenieuren, insbesondere Maschinenbauern, erfolgen. Disziplinen wie der Maschinenbau unterscheiden sich allerdings in Bezug auf ihr Wissenschaftsverständnis merklich von der Informatik. Während in der Informatik allgemein das Bestreben nach verallgemeinerbaren Methoden vorherrscht, besteht im Maschinenbau ein vorrangiges Ziel darin, funktionierende (große) Systeme zu bauen. Disziplinübergreifende Forschungsprojekte müssen sowohl den methodischen Erkenntnisfortschritt als auch eine empirische Bestätigung beinhalten und werden daher in der Zukunft deutlich höhere Forschungsvolumina benötigen.

BD: Halten Sie die hier ausgedrückte Meinung für richtig, dass in der Software lediglich die Methoden zählen, nicht jedoch Produkte und funktionierende Systeme? Sollte die hier zitierte Meinung an Hochschulen oder in der Praxis vorherrschen, was muss geschehen, um sie zu verändern? Ist es nicht gerade für ein Hochlohnland wie Deutschland wichtig, auf den Multiplikatoreffekt von Produkten zu setzen, anstatt sich auf Projekte zu spezialisieren?

MB: Es ist Unsinn zu behaupten, dass in der Software nur die Methoden zählen und nicht die Produkte. Das ist in dem Manifest auch nie so gesagt worden. Eine solche Meinung herrscht auch an Hochschulen nicht vor und in der Praxis schon gleich gar nicht.

Grundlagen versus Theorie

Angesichts der hohen gegenwärtigen Bedeutung und der sich noch verstärkenden Bedeutung in Zukunft ist von Seiten des BMBF eine wesentlich höhere Förderung für Software Engineering vorzusehen. Auch die Deutsche Forschungsgemeinschaft muss diese Thematik in besonderer Weise fördern, indem spezielle Programme aufgelegt werden und sich sowohl DFG als auch Gutachter klar werden, dass Grundlagenorientierung – wie in allen Ingenieurwissenschaften – nicht nur Theorie bedeutet.

BD: Als Grundlagen der Informatik gelten diejenigen Wissenschaften, auf denen sie beruht (z.B. Physik, Mathematik, Elektrotechnik, Psychologie)? Eine Theorie in den Naturwissenschaften erklärt, warum etwas geschieht. Ist der Eindruck richtig, dass der Begriff Theorie von Informatikern oft auch für die Formalisierung gewisser Methoden benutzt wird? Woran liegt das? Was kommt dadurch zu kurz?
MB: Als Grundlagen der Informatik sehe ich nicht die Physik, Mathematik, Elektrotechnik und Psychologie. Theorie in der Informatik wird zumindest nach meiner Definition mit den fundamentalen Zusammenhängen begründet wie Berechenbarkeit, formale Sprachen, algorithmische Komplexität. Grundlagen im Software-Engineering bedeutet für mich, zusätzlich zu den Kenntnissen wesentlicher Teile der Theorie der Informatik, dass der Student ein klares Verständnis von wichtigen Begriffen hat, mit denen der Software-Ingenieur hantiert. Beispiele sind Schnittstelle, Architektur, Modularität, Kompatibilität. ... . Ich könnte hier das Begriffsgerüst beliebig fortsetzen.

Ziele der Ausbildung

Die universitäre Lehre muss international wettbewerbsfähig sein. Sie sollte international zusammenarbeiten. Trotz Grundlagenorientierung muss auch auf die gegenwärtige Praxis vorbereitet werden. 
...  Neben der Vermittlung praxisrelevanter Inhalte muss die Lehre auch gezielter auf Forschungsinhalte vorbereiten.
BD: Der letzte Satz könnte dahingehend interpretiert werden, dass Hochschulen primär an dem eigenen Nachwuchs interessiert seien. Ist dieser Vorwurf begründet? Ist es nicht viel wichtiger auch das Entwickeln und Bewerten von Produkten und Dienstleistungen zu lehren? Wie kann die Praxis-Relevanz des Studiums generell gesteigert werden? Lassen sich ‚soft skills‘ (z.B. Rhetorik, Team-Fähigkeit) theoretisch lehren?

CE: Die Ausbildung muss immer an der späteren Umsetzung interessiert sein. In der Informatik-Ausbildung werden der untere Teil des V-Modells und die Werkzeuge überbetont, während Requirements Engineering, Projektmanagement, Soft Skills etc. zu kurz kommen. Natürlich geht das nicht nur theoretisch, und genau deshalb ist es wichtig, dass das Studium Grundlagen und Methodik auch im praktischen Kontext vermitteln. Das kommt dort zu kurz, wo Professoren nur an Zitationsindexen interessiert sind und nie in der Industrie gearbeitet haben.

MB: Das Manifest beschreibt explizit, dass Lehre auch auf Praxis vorbereiten muss und natürlich auch auf die Fähigkeit zu forschen. Das ist der Anspruch jeder wissenschaftlichen Disziplin. Zumindest, was mich betrifft und die Kollegen, deren Lehre ich kenne, muss ich sagen, dass es ein völlig unzutreffender Vorwurf ist, dass wir nur am eigenen Nachwuchs interessiert sind. Ich finde die Unterstellung fast bösartig.

Verhältnis Primär- zu Sekundärbereich
  
Software ist wettbewerbsentscheidender Faktor geworden, nicht nur in der Primärbranche, die durch die Entwicklung eigenständiger Softwareprodukte gekennzeichnet ist. Dies gilt weitaus stärker in allen so genannten Sekundärbranchen (eingebettete Software in Produkten und Dienstleistungen, z.B. Maschinen- und Fahrzeugbau, Elektrotechnik, Telekommunikation, aber auch Unterhaltungsbranche, Medizin u.a.), in denen 80 % der Softwareingenieure arbeiten [3]. Für die Wertschöpfung im Produktionsgüter- und Dienstleistungsbereich ist Software Engineering entscheidend als „Produktionstechnik des 21. Jahrhunderts“.
BD: Das klingt für mich, als ob man aus der Not eine Tugend macht. Führt diese Einstellung nicht dazu, dass Informatiker auf Dauer in eine Ecke gedrängt werden, während Ingenieure, Kaufleute, Ärzte und andere das Denken für sie übernehmen und auch den ganzen Ruhm einheimsen? Sollten Informatiker nicht  lieber andern Berufen und Personengruppen Informatik-Produkte anbieten, mit denen sie ihre Anwendungen leicht und sicher erstellen können? SAP ging  ̶  zumindest ansatzweise  ̶  in diese Richtung. Wäre das nicht nur ein Weg zu mehr Professionalität der Informatiker, würde es nicht auch das Problem des Fachkräftemangels an der Wurzel angreifen?

MB: Ich bin genug in Projekten unterwegs, insbesondere auch als Gutachter für gescheiterte Projekte, um eine Vielzahl von Beispielen aufzählen zu können, die zeigen, dass dieses Bild eben gerade heute noch mehr zutrifft denn je. Ich schreibe das unter dem Eindruck eines Projektes, das ich gerade begutachtet habe, das für das Anwendungsunternehmen von strategischer, fast existentieller Bedeutung ist und durch Missmanagement in ein Desaster geführt worden ist.

Nirgends steht im Manifest, dass es sich nicht lohnt, sich um den Primärbereich zu kümmern. Allerdings gilt mehr denn je, dass heute die Informatik in allen möglichen Disziplinen entscheidend in den Anwendungen unterwegs ist. Und man wird in diesen Anwendungen keinen Fortschritt machen, wenn hier nicht Software-Engineering und Anwendungs-Know-How eine enge Verbindung eingehen. Im Manifest wird in keinster Weise geschrieben, dass hochqualifizierte Arbeitsplätze nur mit Ausländern besetzt werden. Im Text wird zunächst über Wissenschaft gesprochen und über die Art und Weise, wie sich der Ruf von Wissenschaftlern begründet. Was das für die Praxis bedeutet, ist etwas ganz anderes. Abgesehen davon kenne ich eine Vielzahl von Firmen, die über die Landesgrenzen hinaus wirken, insbesondere Anwendungsfirmen. Beispiele sind Siemens, KUKA, die deutschen Automobil-Firmen und eine Vielzahl von anderen mittelständischen Firmen.

Weiterbildung von Praktikern

Die Hochschulen sollten für die Weiterqualifizierung von Industrie-Mitarbeitern sorgen. Hier bestimmen Quereinsteiger noch immer das Bild des Berufes.

BD: Natürlich würde die Industrie begrüßen, wenn sich Hochschulen hier stärker engagieren würden. Was kann getan werden, um die Situation zu verbessern? Bei fast einer Million Arbeitskräften im IT-Bereich werden Quereinsteiger noch lange benötigt. Was ist falsch daran?

MB: Quereinsteiger stoßen schnell an ihre Grenzen!

Schätzung des Bedarfs

Es gibt einen geschätzten Bedarf von 385.000 Softwareentwicklern in Deutschland. Auch bei vorsichtiger Bewertung dieser Zahl ergibt sich daraus, dass ein weiterer Ausbau der Softwaretechnik an deutschen Universitäten dringend erforderlich ist, denn nach dem aktuellen Stand der Forschung und Lehre wären das derzeit 7300 benötigte Softwareentwickler pro Forschungsgruppe. Vereinzelt begründen einschlägige Firmen bereits die Verlagerung ins Ausland mit dem Mangel an Softwareingenieuren.

BD: Wie verlässlich sind solche Bedarfsschätzungen? Wie weit kann bzw. muss dieser Bedarf aus Nachwuchs im Inland abgedeckt werden? Besteht wirklich ein Mangel an deutschen Führungskräften? Wenn ja, was kann getan werden?

MB: Nur zu dem Punkt des Mangels an deutschen Führungskräften. Nennen Sie mir fünf Vorstandsmitglieder in deutschen DAX-Unternehmen, die in der Lage sind, ihr Unternehmen zu Fragen der Digitalisierung strategisch kompetent zu führen.

Internationale Ausstrahlung

Deutsche Wissenschaftlerinnen und Wissenschaftler im Bereich Software Engineering zeigen international eine hohe Präsenz. Insbesondere im Vergleich mit den europäischen Nachbarn lässt sich feststellen, dass in dem traditionell von den USA dominierten Feld neben den Briten gerade Deutsche in den Organisationskomitees und Herausgeberräten aller einschlägigen Konferenzen und Zeitschriften beteiligt sind. Dieses positive Bild zeigt sich auch in vielen Beiträgen zu Konferenzen und Zeitschriften, deren Anzahl allerdings noch steigerungsfähig ist.
BD: Ist diese Ansicht wirklich ernsthaft vertretbar? Die Informatik ist – und das weiß doch jeder – sowohl was die Wirtschaft als auch die Wissenschaft betrifft, international ausgerichtet. Ohne sichtbare technische und wissenschaftliche Leistungen, die auch im Ausland beachtet werden, insbesondere in den USA, verkommt Wirtschaft und Wissenschaft zur Provinzialität. Das großzügige finanzielle Engagement des Staates in Begegnungsstätten (wie Schloss Dagstuhl), im Ausland geförderte Forschungsgruppen (etwa der Fraunhofer-Gesellschaft) oder den Wissenschaftleraustausch (wie Fulbright und ICSI Berkeley) ist zweifellos hilfreich, allein reicht es sicherlich nicht aus. Was kann getan werden, um einzelne Wissenschaftler oder Unternehmer dazu zu motivieren, ihrem fachlichen Wirken über die Landesgrenzen hinaus mehr Nachdruck zu verschaffen? Welche neuen Initiativen könnten helfen?

MB: Nur ganz kurz: Wir versuchen gerade eine konkrete inhaltliche Zusammenarbeit mit den USA!

Technologietransfer

Die Industrie ist eingeladen, diese Zusammenarbeit verstärkt zu suchen bzw. anzunehmen. Innerhalb dieser Zusammenarbeit kann vorhandenes Wissen transferiert werden bzw. gemeinsam erarbeitetes für die Nutzung aufbereitet werden. Diese Zusammenarbeit besteht nicht aus kurzzeitiger und kurzfristiger Entwicklungsarbeit. Eine längerfristige Zusammenarbeit im beschriebenen engen Kooperationsmodus bezüglich des Horizonts der Aufgabenstellung und der Kooperationszeit ist eine ideale Basis für das Rekrutieren von Mitarbeitern, deren Qualifikation und Eignung der Industriepartner dann genau kennt.
BD: Wird nicht über dieses Problem schon seit Jahrzehnten gejammert? Was kann getan werden, um die Situation zu verändern?

CE: Technologietransfer findet überall dort statt, wo parallel zur Forschung auch der Markt und der Bedarf hinterfragt werden. Gute Forschung ist auf Tuchfühlung mit der Industrie. Algorithmen für Suchmaschinen oder für selbstfahrende Autos entstehen genau an dieser Schnittstelle, und nicht im stillen Kämmerlein eines Lehrstuhls. Dass es klappt, zeigen Fraunhofer Institute und die vielen Unternehmen, die ganz konkret mit Hochschulen arbeiten und damit den Transfer operationalisieren. Bei Vector [dem Unternehmen, bei dem Ebert Geschäftsführer ist] unterstützen wir verschiedene deutsche Hochschulen in der Forschung und im Transfer – ohne die Freiheit der Forschung einzuschränken.

MB: Von jammern kann keine Rede sein – wir machen das – gern bei Bedarf näheres!

Stand der Praxis

Im Widerspruch dazu wird in vielen Unternehmen der Sekundärbranche die Entwicklung und Pflege von Software noch als reiner Kostenfaktor betrachtet. Nur wenige Unternehmen haben bereits die strategische Bedeutung von Software als Umsatzgenerator und „Business-Enabler“ erkannt und betrachten Softwareprojekte unter dem Aspekt ihrer Unternehmensstrategie.
BD: Kommt hier nicht eine Meinung zum Ausdruck über eine Situation, die mindestens seit 20 Jahren nicht mehr zutrifft. Was kann getan werden, um das nachhängende Bild zu korrigieren?

MB: Betrachtet man wie der Einkauf in der Automobilindustrie Aufträge vergibt – im Fall von Softwareentwicklern rein nach Tagessätzen – so sieht man, dass die Aussage aus dem Manifest nach wie vor gilt!
  
Stuttgarter Modell

Die Erfahrungen mit einem speziellen Studiengang mit dem Schwerpunkt Softwaretechnik sind sehr gut. Versuche, wie etwa in Stuttgart, wurden nach erfolgreicher Evaluation inzwischen fest etabliert.

BD: Warum blieb Stuttgart bisher ein Einzelfall? Gäbe es nicht Alternativen zum Stuttgarter Modell, die insgesamt besser wären, nämlich generell die konstruktiven Aspekte der Informatik stärker zu betonen, und zwar für Systemprodukte, in denen Hardware und Software zusammen geplant werden?

MB: Volle Zustimmung!

Zusatzfrage 1

BD: Welche Möglichkeiten gibt es, um sowohl den intellektuellen wie den wirtschaftlichen Wert eines Software-Produkts kenntlich zu machen und ins allgemeine Bewusstsein zu rufen? Gibt es Möglichkeiten, dieses Anliegen während des Studiums stärker zur Geltung zu bringen?

Barbara Paech (BP): Ja, natürlich. Bei uns gibt es durch einen Lehrbeauftragten von SAP eine Vorlesung Software-Ökonomie. In Projekten mit industriellen Auftraggebern (im großen Stil bei Herrn Brügge an der TUM), im kleinen Stil an vielen anderen Unis erhalten die Studis ganz konkrete Anforderungen bzw. Feedback, das den  wirtschaftlichen Wert betont. Allerdings eher für kleine Anwendungen wie Apps.

Zusatzfrage 2

BD: Was sehen Sie als die größten Erfolge des Software Engineering an? Wo besteht noch Nachholbedarf? Wie sehen Sie Deutschland im Vergleich zu anderen Ländern? Tut die Gesellschaft für Informatik (GI) auf diesem Gebiet genug und – vor allem – tut sie das Richtige?

BP: Ich persönlich finde es nicht so hilfreich, größte Erfolge zu sammeln. Wichtig ist mir eine kontinuierliche positive  Weiterentwicklung. Im Bereich Requirements Engineering, den ich am besten beurteilen kann, gibt es z.B. eine Entwicklung von ausschließlich systemnahen Anforderugen zum Einbezug von NutzerInnen durch 'Use cases' und 'user stories'  zu 'continuous software engineering' mit kontinuierlichem NutzerInnen-Feedback zu kleinen Inkrementen. Da ist vieles noch nicht ganz ausgereift, aber das geht ein ganz essentielles Problem des SE an, nämlich dass die Produkte oft Funktionalität haben, die die NutzerInnen so nicht brauchen können oder wollen.

Diese Entwicklungen werden typischerweise nicht durch Unis angestoßen, sondern kommen aus der Praxis, aber die empirische Forschung hilft, Mechanismen deutlich zu machen und von Werbesprüchen wegzukommen. Die methodische Forschung hilft, diese oft als Hype entstehenden Entwicklungen (ein)zuordnen und eben auch für die Lehre aufzubereiten.

BD: Vielen Dank allen Beitragenden!

Referenzen:
  1. Broy, M., Jarke, M:, Nagl, M., Rombach, D.: Manifest: Strategische Bedeutung des Software Engineering für Deutschland. Informatik Spektrum 29.3 (2006), 210-221
  2. Broy, M., Kuhrmann, M.: Projektorganisation und Management im Software Engineering. Heidelberg 2013
  3. Evasoft2000: Analyse und Evaluation der Softwareentwicklung in Deutschland. Studie für das Bundesministerium für Bildung und Forschung, 2000

Montag, 22. August 2016

Über Geschäftsmodelle der Software-Industrie oder über den Wert von Software

Es sind inzwischen 10 Jahre her, seit ich mich zuletzt mit dem Thema Software als Industrie [1] befasste. Zehn Jahre sind in unserer Branche eine lange Zeit, in der sich nicht nur technisch Einiges geändert hat. Vor allem haben wir die 2008 durch die Banken ausgelöste große Wirtschaftskrise hinter uns. Das Jahr 2006 wurde von der Bundesregierung als Informatik-Jahr besonders hervorgehoben. Das motivierte die Kollegen Manfred Broy, Matthias Jarke, Manfred Nagl und Dieter Rombach dazu, in der Form eines Manifestes auf die Bedeutung von Software [2] hinzuweisen. Beide Veröffentlichungen sollen quasi als Bezugsbasis gelten.

Software überall

Man kann kaum noch sagen, wo uns Software nicht begegnet [3]. Die Schätzung in meinem Artikel von 2006 [1] über die Anzahl von Software-Firmen dürfte um eine Größenordnung zu niedrig sein. Allein in Deutschland gibt es vermutlich rund 50.000 Software-Unternehmen. Etwa 85% von ihnen bestehen aus einem Mitarbeiter, weitere 10% haben weniger als 10 Mitarbeiter. Sowohl die Zusammensetzung der Branche als auch die jeweilige Spitzenformation ist sehr unstabil. Pro Jahr melden etwa 500 Software-Firmen Konkurs an. Die Zahl der Neugründungen liegt in derselben Größenordnung, vielleicht sogar höher. Der Vergleich, der in der nachfolgenden Tabelle versucht wurde, leidet darunter, dass unterschiedliche Kriterien für die Auswahl zur Anwendung kamen.


Führende deutsche Software-Häuser (nach Lünendonk)

Offensichtlich dominieren in der Liste von 2003 die Firmen, die sich auf Software-Projekte konzentrieren. Im Jahre 2013 überwiegen die Firmen, die Software-Produkte anbieten. Firmen, die vorwiegend Online-Dienste anbieten (wie Google und Facebook) fehlen in beiden Jahren. Auch die Firma Apple ist ausgeschlossen, da sie ihre Software vorwiegend mit Hardware gebündelt vertreibt. Es macht daher keinen Sinn, aus den Zahlen einen Trend ablesen zu wollen. Auch die aktuellen Zahlen stellen nur einen kleinen Bruchteil der Software dar, die heute im Markt angeboten wird.

Software-Cluster am Beispiel Jena

Dass Deutschland im Software-Geschäft alles andere als eine zweite Geige spielt, ist weltbekannt. Niemand anderes als Jim Cook, der CEO von Apple, sagte dieser Tage in einem Interview in der Washingten Post, dass er sich gerade bemüht, besseren Kontakt zu SAP zu etablieren. Wörtlich sagte er: ‘They own three-quarters of the world’s transactions, in terms of it running on their products’. Nur so viel zur Erklärung: Transaktionen sind ein Pseudonym für ernsthafte Datenverarbeitung, bei der es um wertvolle Daten geht.

Durch meinen Kollegen Klaus Küspert wurde ich vor einiger Zeit auf eine Veröffentlichung (von Guido Buenstorf·und Dirk Fornahl) hingewiesen, in der die Geschichte von Intershop aufgearbeitet wurde. Wer es bereits vergessenen hat: Stephan Schambach und Intershop waren nur eine von Deutschlands Raketen im Internet-Boom. Intershop erreichte den Gipfel seines Aktienkurses und seiner Mitarbeiterzahl im März/April 2000. Ihr Börsenkurs stürzte von über 1400 auf unter 200 Euro. Die Firma existiert weiter in Jena. Schambach ist weiter daran beteiligt, hat aber auch schon zwei Nachfolgefirmen gegründet. In der Untersuchung werden 40 Firmen gelistet, die von ehemaligen Mitarbeitern von Intershop gegründet wurden. Die Tabelle drückt den Stand von 2008 aus.



Spin-offs der Firma Intershop aus Jena

Eine solche Cluster-Bildung ist nicht untypisch für die Software-Industrie. Sie gibt es in Ballungsräumen wie München, Stuttgart, Karlsruhe, Darmstadt, Frankfurt, Aachen, Dortmund, Hamburg und Berlin. Sie löst im Falle Deutschlands nicht das Problem, dass es deutschen Software-Firmen - mit der Ausnahme von SAP - sowohl an Finanzkraft wie an internationalem Ansehen fehlt.

Erfolgten im Falle von Jena einige der Spin-offs unfreiwillig, ist die Trennung einzelner Gruppen von großen Firmen oder die Kooperation zwischen mehreren kleinen Firmen meist freiwillig. Es drückt sich oft eine Form von Spezialisierung aus, indem wertvolle Spezial-Skills mehreren Unternehmen im Umkreis angeboten werden.

Viele Diskussionen befassen sich mit der Frage, welche Rolle Start-ups spielen, also Neugründungen von Firmen. Hier machte die Stadt Berlin in letzter Zeit viel von sich reden. Viele Branchenkenner aus Süddeutschland können darüber nur schmunzeln. Angeblich sucht Wagniskapital in den letzten Jahren vor allem nach Anbietern von neuer Finanz-Software (auch Fintech genannt). Was dabei für Berlin sprechen sollte, ist mir ein Rätsel. Eine Sonderkonjunktur scheint es aber bei Computerspielen aus Berlin zu geben. Laut Angaben des Wall Street Journals gingen allerdings in Berlin von 2014 auf 2015 das eingesammelte Wagniskapital von 1,5 Milliarden Euro auf 520 Millionen zurück.

Software als Gut mit Wert

Wird in der Wirtschaft von Werten gesprochen, landet man alsbald bei Geschäftsmodellen. Als Basis für die folgenden Erläuterungen soll eine Definition aus dem Gabler Wirtschaftslexikon dienen:

Das Geschäftsmodell bestimmt, (1) was eine Organisation anbietet, das von Wert für Kunden ist, (2) wie Werte in einem Organisationssystem geschaffen werden, (3) wie die geschaffenen Werte dem Kunden kommuniziert und übertragen werden, (4) wie die geschaffenen Werte in Form von Erträgen durch das Unternehmen „eingefangen“ werden, (5) wie die Werte in der Organisation und an Anspruchsgruppen verteilt werden und (6) wie die Grundlogik der Schaffung von Wert weiterentwickelt wird, um die Nachhaltigkeit des Geschäftsmodells in der Zukunft sicherzustellen.

Hier ist meine Liste mir bekannter Geschäftsmodelle für die Software-Branche. Mit der Nummer 9 höre ich auf.
  1. Überlassung von Produkt-Lizenzen (mit/ohne Service) für Installation beim Nutzer. Microsoft und SAP haben dieses Modell perfektioniert und wurden groß damit.
  2. Ditto für Online-Nutzung (engl. Access only). SalesForce ist ein bekanntes Beispiel.
  3. Planungs-, Entwicklungs-, Installations- und Wartungs-Projekte nach Vorgabe durch andere Unternehmen. Nach diesem Modell operieren die meisten der 50.000 Firmen im deutschen Markt.
  4. Ausbildung und Beratung von Nutzern. Das schaffen nur Firmen mit anerkannter Kompetenz.
  5. Verbesserung der Absatzchancen für andere Produkte (z.B. Rechner-Hardware). So begann es bei Firmen wie IBM, Bull und Siemens. Nur Apple blieb diesem Prinzip treu und bündelt Hardware mit Software. Es wurde auf diese Weise die erfolgreichste Firma der Branche. Es wurden Spitzenumsätze und –gewinne erreicht. Man lieferte soeben das milliardste Gerät eines Typs (des iPhone) aus. Viele andere Branchen verbessern die Attraktivität ihrer Produkte durch ‚eingebettete‘ Software. Positive Beispiele sind die Werkzeugmaschinen- und die Flugzeugindustrie. Zum Mißkredit von Software sorgte in letzter Zeit die Automobilindustrie, insbesondere VW und Bosch.
  6. Erschließung neuer Vertriebs-, Verteilungs- und Wartungsmöglichkeiten. Die Firma Amazon begann mit dem Buchversand und ließ danach eine Einzelhandelsbranche nach der anderen alt aussehen.
  7. Verbesserung des Informationsflusses zwischen Kaufinteressenten und Warenanbietern, also zielsichere Werbung. Google hat erkannt, dass dank der Internet-Technik hier ein riesiges Potential erschließbar ist und hat sich darauf spezialisiert und weltweit konsequent durchgesetzt. Google verdiente dabei derart viel Geld, dass es jeden andern Software-Hersteller durch kostenlose Angebote aus dem Markt vertreiben kann, sofern es nur wollte.
  8. Ermöglichung von Folgegeschäften. Da Google Microsoft aus seinem ursprünglichen Geschäft (Nummer 1 dieser Liste) zu vertreiben scheint, sucht Microsoft Zugang zu neuem Umsätzen durch Verschenken von Betriebssystem-Software. Das Betriebssystem seinerseits informiert Microsoft, was auf dem Rechner läuft und bei welchen Anwendungen noch Geld zu verdienen ist.
  9. Verkauf von Firmenanteilen. Das ist der Weg, wie viele Wagniskapitalgeber Gewinn machen. Es hat auch die Firmengründer von Microsoft und SAP zu Milliardären gemacht. Meist wird der Schritt schon nach wenigen Jahren unternommen. Dann kommt es darauf an, ob die Personengruppe der Gründer Talent bewiesen hat, ob ihre technischen Ideen wirtschaftliches Potenzial haben und ob geschützte intellektuelle Rechte existieren. Das Beispiel der Göppinger Firma TeamViewer beweist, dass in Deutschland auch dieses Modell zum Tragen kommen kann (Die Firma wurde 2014 von dem Investor Permira für 870 Mio. Euro aufgekauft).
Ich möchte zunächst unterscheiden zwischen dem intellektuellen und dem wirtschaftlichen Wert, den ein (lauffähiges) Software-Produkt darstellt. Beide sind wichtig und sollten jeden Informatiker interessieren. Der intellektuelle Wert eines Software-Produkts wird bestimmt durch den Grad seiner Originalität. Die Frage, die man stellen muss, lautet: Enthält das Produkt Ideen, die den Stand der Technik weiterbringen? Der wirtschaftliche Wert ergibt sich aus der Beantwortung der Frage: Was sind potentielle Nutzer willens dafür auszugeben, dass es ihnen ermöglicht wird, die durch das Produkt geschaffenen Vorteile auszunutzen. Beide Werte liegen auf unterschiedlichen Ebenen. Sie stellen verschiedenen Dimensionen dar. Es gibt noch weitere Wertdimensionen, die in Frage kämen, die hier aber nicht in Betracht gezogen werden sollen. Als Beispiele seien der gesundheitliche, der erzieherische oder der unterhaltende Wert genannt.

Werden nur Qualität (im Sinne von Fehlerfreiheit oder Zuverlässigkeit) oder Produktivität (bei der Erstellung) diskutiert, kann man leicht perverse Ergebnisse erzielen. Qualität ist am einfachsten zu erreichen, wenn es keine fremden Nutzer gibt. Die Produktivität ist leicht zu steigern, indem man dasselbe macht, was man schon 100 Mal gemacht hat. Kunden sind leichter zufrieden zu stellen, wenn sie ein Produkt geschenkt bekommen als wenn sie dafür bezahlen müssen.

Im Gegensatz zu Lyrik und schriftstellerischer Prosa kann Software seinen Wert innerhalb von Monaten oder Jahren total einbüßen. Ein Software-Produkt muss zwei Formen von Lebendigkeit besitzen. Es muss sich an die anvisierte oder vorgefundene Nutzerumgebung anpassen. Vor allem muss es angemessen reagieren in Bezug auf Ausdrucksform, Antwortzeit, Sprache und intellektuelles Niveau. Nutzer passen sich, im Falle eines für sie wertvollen Produkts in gewissem Rahmen freiwillig an. Das Produkt muss sich auch verändern können, sobald sich die Umgebung ändert, etwa durch neue Gesetze.

Selbstverständnis der Softwaretechnik

Einige Ideen bezüglich Software-Entwicklung, die sich bei mir herauskristallisierten, habe ich in einen Blog-Eintrag im Februar diesen Jahres zusammengefasst. Ich nannte es meine 10 Grundthesen. Eine davon geht auf die NATO-Tagung von 1969 in Rom zurück, über andere habe ich in den 1990er Jahren veröffentlicht und vorgetragen. Auch bei meinem eingeladenen Vortrag in Leipzig anlässlich der ICSE 2008 stand eine solche Idee im Mittelpunkt. Dort sagte ich unter anderem:

Cost and productivity are key issues only where the value of a product is ignored.

Das im Oktober 2005 anlässlich eines Dagstuhl Workshops entstandene Manifest [2] ist außer von den vier Autoren noch von weiteren 30 Kollegen unterschrieben. Das sind fast alle anwesenden Inhaber von deutschen Universitätslehrstühlen in Softwaretechnik bzw. Software Engineering. Wenn man berücksichtigt, dass Software Engineering erst seit der 1968er Konferenz in Garmisch die Würde eines eigenen Studienfachs besitzt, ist diese Zahl beachtlich. Die Klage der Unterzeichner, dass eine Stärkung der akademischen Präsenz dringend erforderlich sei, ist durchaus verständlich. Wichtiger ist es für mich, über eine Neuausrichtung nachzudenken.  [Im nächsten Beitrag gehe ich auf dieses Manifest im Detail ein.]

Der Hauptgrund aber, warum ich dieses Manifest überhaupt erwähne, ist die Tatsache, dass darin der Begriff Wert überhaupt keine Rolle spielt. Das dort Gesagte gilt für Hobby- und Spiel-Software wie für ernsthafte Software gleichermaßen. Das Spektrum dessen, was Software umfasst, ist weiter enorm gewachsen. Den mathematischen Algorithmen oder Beispiel-Programmen, die bestenfalls 50 Zeilen oder eine Schreibmaschinenseite umfassten, stehen Programmsysteme im Bereich von Mega- oder Gigabytes gegenüber. Die Software, wie sie etwa von Google täglich genutzt und verwaltet wird, umfasst etwa zwei Milliarden Programmzeilen oder 50-100 Gigabytes. Ich überlasse es dem Leser abzuschätzen, wie vielen Buch- oder Bildschirmseiten dies entspricht. Dasselbe gilt für den Wert. Der Marktwert der Firma Alphabet (früher Google) liegt glatt eine Größenordnung über General Motors, der größten Autofirma Amerikas. Er wird im Kern durch dieses eine Programm bestimmt.

Eine Reflexion persönlicher Art

Ein Kollege, der mich gut kannte, meinte einmal: ‚Sie haben oft gute Ideen, nur dauert es meist etwas lange, bis Sie draufkommen‘. Ich empfand dies im Prinzip als Kompliment. Ich bin mir der im Nachsatz formulierten Einschränkung durchaus bewusst. Selbst 20 Jahre nach Ende meiner Berufskarriere kommen mir manchmal Ideen, von denen ich sage, ach, wären die mir doch früher gekommen. Um dieser Situation Rechnung zu tragen, begann ich damit diesen Blog zu führen.

Weitere Referenzen
  1. Endres, A.: Geschäftsmodelle und Beschäftigungspotenziale der Software-Industrie. Informatik Forsch. Entw. 21,1/2 (2006), 99-103
  2. Broy, M., Jarke, M:, Nagl, M., Rombach, D.: Manifest: Strategische Bedeutung des Software Engineering für Deutschland. Informatik Spektrum 29.3 (2006), 210-221
  3. Broy,M., Endres,A.: Informatik überall, jederzeit und für alle. Informatik-Spektrum 32,2 (2009), 153-162

Dienstag, 16. August 2016

Mathematik-Schmankerl für die Enkel

Mein Freund Peter Hiemann in Grasse, den Sie als Beitragenden dieses Blogs bestimmt kennen, ist ein gelernter Mathematiker. Dieser Tage sah er sich veranlasst, bei seinem 14-jährigen Enkel etwas für Mathematik zu werben. Er möchte  ̶  wie er sagt  ̶  dem Enkel Lust an Mathematik verschaffen. Offensichtlich ist bei dem Enkel der Mathematikunterricht in der Schule nicht motivierend genug.

Es gibt sicher eine Vielzahl von Wegen, wie man dies tun kann. Peter Hiemann versucht es mit Fakten, also mit mathematischen Konstanten. Gleich danach kommt er auf Konstanten der Natur, also von der reinen Mathematik zur Physik und zur Biologie. Das ist für jemanden, der Hiemann kennt, keine Überraschung. Ob es bei dem Enkel als Appetitanreger ausreichte, weiß ich nicht. Hiemann schrieb: 

‚Mich würde interessieren, ob andere Opas ähnliche Situationen mit ihren Enkeln erleben und wie sie reagieren. Es mag sich nicht [nur] um Mathe handeln.‘ 

Dem schließe ich mich an. Da auch der Administrator dieses Blogs bei seinen Beiträgen sehr oft an seine Enkel denkt, bin ich Peter Hiemann dankbar, dass er sein Material zur Verfügung stellt. Gerne führe ich eine Diskussion in diesem Blog darüber, wie man Mathematik lehren sollte, dass sie bei Jugendlichen auch ankommt.

Sie können Hiemanns Text lesen, indem Sie hier klicken.

Samstag, 6. August 2016

Abstraktion, (k)ein Unwort für praktische Informatiker?

Manchmal darf man Dinge öfters sagen, manchmal muss man sogar. ‚Ceterum censeo…‘ sagte einstmals Cato, jedesmal wenn er im Senat redete. Seine Taktik war schließlich erfolgreich. Mit dem Thema Abstraktion, kurz Thema A genannt, befasse ich mich seit rund vierzig Jahren. Schon mehr als einem Kollegen ging ich damit auf die Nerven. Auch in diesem Blog kam es bereits drei Mal vor. Beim ersten Mal nahm ich die Doppeldeutigkeit des Begriffs Abstraktion ins Visier. Ich unterschied zwischen (Mengen-) Vereinigung und Transzendentierung. Danach versuchte ich für alternative Konzepte zu werben, etwa für die Aggregation.

Jetzt werde ich nur eine Diskussion der letzten Tage wiedergeben. Wie immer in diesem Blog, heiße ich auch hier Bertal Dresen (BD). Mein Sparringspartner war wieder mein Kollege Hartmut Wedekind (HW) aus Darmstadt. Er hat einen großen Vorteil für mich: Mit ihm kann man eine ganze Weile streiten. Er gibt nicht so leicht nach. Wer mit mir länger auskommen will, benötigt drei Eigenschaften, Resilienz, Geduld und Vergesslichkeit.

Wedekind hatte Anfang August in seinem Blog einen Beitrag veröffentlicht mit der Überschrift  „Das Invariante bleibt: Eine Studie zum Begriff der Nachhaltigkeit“. Darin versuchte er unter anderem Juristen klarzumachen, dass sie unterscheiden sollten zwischen konkreten Verträgen und der Idee eines Vertrages. Die Idee sei eine Abstraktion so wie es Zahlen gegenüber Ziffern seien. Ich konnte mich nicht zurückhalten und schrieb einen Kommentar mit folgendem Wortlaut.

BD: Es ist jammerschade, dass der Informatiker Wedekind uns immer klarmachen will, dass er mit Zahlen rechnen kann. Erst seit es (elektronische) Ziffernrechner gibt, gibt es die Informatik. Schon vor 50 Jahren konnte ich keine Differentialgleichungen lösen, ohne mir genau zu überlegen, was meine Gleitkommadarstellung mit ihnen machte.

HW: Aber das will ich doch gar nicht. Ich will doch bloß das Invarianzprinzip (auch als Nachhaltigkeit mit dem Thema "was bleibt") an ganzen Zahlen als Beispiel klar machen, weil ganze Zahlen alle kennen. Die ganze Abstraktionshierarchie bis hin zu den komplexen Zahlen erspare ich mir. Die intensionale Abstraktion zu den Begriffen hin bringe ich, weil sie auch den Juristen unbekannt ist. Sie [ob die Juristen oder ich gemeint waren, kommt auf dasselbe heraus] verstehen das nicht oder wollen es nicht verstehen. Das weiß ich doch.

Schauen Sie sich aber das fast unerträgliche "Abstraktionselend" (siehe z.B. bei Wikipedia) in der Welt doch mal genau an (nicht nur bei Juristen), und auch das Blabla drum herum inkl. "Information hiding" bei den Informatikern. Das ist unverstandener Quatsch zum Quadrat und bloße Metaphorik. Schauen Sie sich [auch] den Quatsch vom berühmten Kronecker an. "Die ganzen Zahlen hat der liebe Gott gemacht, alles andere ist Menschenwerk." Das Schlimme, die glaubten das früher wirklich. Der Blödsinn ist kein Spaß, obwohl es so aussieht. Das ist Schwachsinn und eines Wissenschaftlers unwürdig.

BD: Sie tun ja auch Dinge, die Sie nicht tun wollen. Sie wollen Informatiker sein und werben für Mathematik. 'Math considered harmful' kann ich nur sagen. Besonders wenn Informatiker sie betreiben, die eigentlich eine ganz andere Aufgabe haben.

HW: Ich mache die Mathematik in ihrer "ontologischen" Infantilität zur Sau. Ich werbe doch nicht für sie. Kronecker ist kein Winzling, sondern steht in deren "hall of fame", ganz oben. Den Mathematikern heute ist der Auspruch Kroneckers ja auch peinlich, so wie gute Juristen auch das Abtrenntheater eines Savingy nicht mehr ertragen können, weil es auch so geht, wie das anderen Nationen machen. In Europa kann man das nicht einbringen. Nicht exportierbar! Nur die Japaner, die haben es übernommen. Überall haben sie die Lacher, bloß die Belachten merken das nicht, weil sie dogmatisch und unkritisch sind. Das sind wissenschaftliche (auch politische) Todsünden. Und was ist mit ISO/OSI mit seinen 7 Schichten der Abstraktion?

BD: Das sind Hilfen fürs Denken. Es gibt auch schöne Bilder in Büchern. Es gibt aber keine OSI-Maschine, die sie direkt bearbeitet. OSI kommt auf Maschinen nur indirekt vor, von Menschen mühsam von Hand übersetzt und angepasst. Dabei entstehen dann viele Fehler. Aber dafür tragen dann andere Leute die Verantwortung. Nicht die, die abstrakte Bildchen malten. Was wäre an einer Machine, die direkt die ISO-Protokollschichten interpretiert, abstrakt?

HW: Man kann bei ISO/OSI die Invarianzen vom Schicht zu Schicht einzeln vorführen, wenn man will. Merkmal für Abstraktion: Was bleibt, wenn der Strom ausfällt und kein Notstrom-Batterie-System vorliegt? Bei Datenbanken sagt man, nur das, was auf Platte konkret protokolliert wurde. Das sind die After-Images einer Seite nach jeder Veränderungstransaktion. Mit den konkreten Bits der Images wird dann ein Recovery der Abstraktionsschichten darüber veranstaltet. Auch bei HANA muss recovered werden können.

BD: Ob TCP/IP eine Abstraktion im Sinne Ihrer ganzen Zahlen ist, wage ich zu bezweifeln. Haben Sie kein besseres Wort für 'konkret vorhandene Interpretationsebenen'?

HW: Sicherlich. Man brauchte das DoD mit seinem TCP/IP auf der wichtigen Schicht  4. Ohne DoD kein Internet. Der Aristoteles in seiner Ontologie hat ähnlich in Schichten gedacht. Das ist aber keine Abstraktionshierarchie, für uns nur eine Analogie (Ähnlichkeit). Es ist eine Ontologie-Hierarchie.

BD: Noch einmal: Sobald Sie von Abstraktion reden, besteigen Sie eine Art Rakete, die Sie von der Erdoberfläche entführt. Sie begeben sich in Sphären, wo der (arme, aber praktische) Informatiker nichts tun kann. Sie treffen dort vielleicht auf Mathematiker und Philosophen. Aber das interessiert mich wieder nicht. Es gäbe unten eigentlich genug zu tun. Auch für Leute wie Sie.

HW: Vielleicht hilft Ihnen der E.W. Dijkstra mit seinem Betriebssystem THE weiter. Es war damals das erste Mal (1965), dass systematisch eine Abstraktionshierarchie als Konzept benutzt wurde. [Stimmt nicht ganz. Ich benutzte 1956 den Bell-Interpreter, der als Schicht zwischen Hardware und Anwendung lag.] Dijkstra war ein exzellenter Mann. Ganz neidisch war Dave Parnas mit seiner Metaphorik "information hiding" (statt Abstraktion). Das Data Independent Accessing Model (DIAM) für Datenbanken kam erst später, 1972, IBM San Jose.

BD: Im zitierten Text kommt zwar einmal das Wort Abstraktion vor. Mich würde es sehr wundern, wenn Dijkstra Schichten einer Implementierung als Abstraktionen bezeichnet hätte. Oder die Schichten einer Sahnetorte.

Abstraktion ist für mich als Ingenieur und Informatiker  ̶  unabhängig davon, was Philosophen und Linguisten meinen  ̶  eine auf realen Rechnern undefinierte Operation. Sie ist vergleichbar mit der Division durch Null.

Dass man für die gedankliche Kopfarbeit, d.h. ohne an Rechner zu denken, mehr Freiheitsgrade hat, das bestreitet niemand. Nicht formales Denken ist sogar meist einfacher und schneller, nur ist es nicht maschinell verwertbar, bzw. nachvollziehbar. Ich selbst habe oft Pseudocodes verwendet, d.h. Notationen, die aussahen wie Programmiersprachen, die aber nie ausführbar waren. Das Abstrahieren führt jedenfalls nicht näher zu einer maschinellen Lösung eines Problems, sondern weg von ihr. Es führt in die falsche Richtung.

Ich kann mir übrigens auch abstrakte Zahlen gedanklich vorstellen. Für sie würden etwa die folgenden Operationen gelten:

0/0 = 1; 0/∞ = 0; ∞/∞ = 1; ∞/0 = ?; ∞/n = ∞; n/0 = ∞ für n ≠ 0

Ob Mathematiker sich bereits mit solchen Zahlen angefreundet haben, weiß ich nicht. Einem Informatiker würde ich davon abraten.

HW: Auf die Worte kommt es mir nicht an. Meinetwegen nennen wir Thema A jetzt wieder Information Hiding. David Parnas freut es. Wie nennt man dann die Abstrakten Datentypen (ADT)? „Hidden Data Type“ oder „Gekapselte Daten“? Alles archaische, metaphorische  Bildersprache. Das ist wie bei „Eiweiß“. Das erweckt falsche Vorstellungen. Wissenschaft macht „Protein“ daraus. Eiweiß kommt  nicht nur im Weißen des Eis vor. Protein, das versteht so ohne Weiteres wenigstens niemand, (also auch nichts Falsches), es sei denn, er schreibt eine Formel an die Tafel. Eiweiße haben alle die gleiche Struktur und werden vom Fachmann als solche sofort erkannt.

BD: Ich weiß, dass Worte oft der Anlass für Schwierigkeiten in der Kommunikation sind. Sie sind immer so vorbelastet. Mit dem Adjektiv 'abstrakt' habe ich weniger Probleme als mit dem Substantiv 'Abstraktion'. Eine Darstellung kann leicht 'abstrakter' sein als eine andere. Ist sie damit auch 'abstrakt'? Manchmal ist es leichter besser zu sein als gut.

Schlussgedanken

Für Platon (428-348 v. Chr.) ist bekannt, dass er die Idee eines Dings für wichtiger hielt als das Ding selber. Die Idee eines Dings ist für Philosophen eine Abstraktion, eine Translation aus der realen Welt in die Welt des Geistigen. Sobald von der Idee eines Computers, eines Programms, einer Datei, usw. geredet wird, sollte sich ein Informatiker als nicht zuständig erklären. Anders ist es, wenn über konkrete Computer, Programme und Daten gesprochen wird oder wenn die Menge (genauer gesagt, die Klasse) aller Rechner, Programme oder Dateien gemeint ist, die etwa im Internet zugreifbar sind oder die Untermenge, die gültig oder lauffähig ist. Da liegen die echten Aufgaben für Informatikerinnen und Informatiker.  Niemand sagt, dass dies leichte und unwichtige Aufgaben seien.

Es gibt eine Menge von Begriffen, die sich als Alternativen zu dem Wort Abstraktion anbieten würden: Dekonkretisierung, Despezifierung, Entformalisierung, Entpräzisierung, Transzendenz, Vergeistigung, Verunschärfung, usw. Gegen die Benutzung außerhalb der (praktischen) Informatik (Bsp. für abstrakte Malerei oder abstrakte Kunst) habe ich nichts einzuwenden. Bei abstrakter Interpretation und abstrakter Syntax fühle ich mich eher unwohl.


Fortsetzung und vorläufiger Abschluss am 11.8.2016

Nach der Veröffentlichung dieses Blog-Beitrags entwickelte sich der Dialog zwischen Hartmut Wedekind und mir noch erheblich weiter. Diesen Teil der Diskussion gebe ich hier als normalen Blogtext wieder, anstatt in den Kommentarmodus zu wechseln. Der Text ist so leichter lesbar.

HW: Nicht auf Platon und Aristoteles, sondern auf Gottlob Frege (1848-1925), den Begründer der modernen Logik, beziehe ich mich. Auf einer Tafel an seinem Geburtshaus in Wismar steht der Satz „Er ermöglichte durch seine Vorarbeit die Elektronische Datenverarbeitung.“ Na bitte, wenn das nichts ist! Frege hat auch die moderne Abstraktionslehre entwickelt. Er müsste der eigentliche Angriffspunkt der Kritik sein. Bei mir kommt in Sachen Abstraktion nichts Neues hinzu. Die Lehre Freges ist rund 130 Jahre alt und jedermann zugänglich.

BD: Wer Frege als Vordenker der Informatik ansieht, sollte dies auch bei Gerbert d'Aurillac tun, alias Papst Silvester II (946-1003). Wie kaum ein anderer engagierte er sich für die Einführung arabischer bzw. indischer Ziffern im Abendland. Ohne sie hätten es menschliche und mechanische Rechner verdammt schwer, besonders mit der Division. Ein Problem hätten sie allerdings weniger. Eine Division durch Null käme nicht vor.

HW: Logik hat viele Höhen und Tiefen erlebt: Hoch bei den Griechen, Tief bei den Römern, Hoch im Mittelalter (diverse Päpste waren bedeutende Logiker, die aus den Klöstern kamen), Tief in der Renaissance auch noch bis in die Aufklärung hinein. Leibniz gehört nicht zu den großen Logikern. Man kann auch sagen, warum. Das neue Hoch begann mit Frege. Dann folgten Tarski, und Gödel. Leider haben die Mathematiker die Logik unter ihre Fittiche genommen und z.B. auch die Juristen, die im Mittelalter noch sehr nah dran waren, total verdrängt. Mathematiker sind Usurpatoren, die scheinbar alles besser wissen. Lesen Sie mal eine ordentliche Geschichte der Logik, da sieht das (aristotelische) Mittelalter glänzend aus.

BD: Gerbert hatte in Córdoba, Sevilla, Fes oder Kairouan Arabisch und Mathematik studiert. Ob er als Logiker von anderen Logikern anerkannt wird, weiß ich nicht. Jedenfalls kommt er in einem früheren Blog-Eintrag von mir vor. A propos Frege. Bei ihm finde ich den Satz: 'Das Abstraktum von x sind alle y, die in einer Äquivalenzrelation zu x stehen.' Was hat das mit Datenverarbeitung zu tun? Kann man das mit Lochkarten verarbeiten?

HW: Der Wertebereich von y sei: (III, ***, ???, 000, &&&, $$$, .... ). Bei Lochkarten braucht man für Sonderzeichen Mehrlochungen pro Spalte.  Man erkennt das Muster (Bem.: Tiere können das nicht): Alle Symbolfolgen im Wertbereich y sind gleichlang. Man sagt auch anzahlgleich (Frege).  Das ist die Abstraktionsleistung! Es entsteht ein Abstraktum, das wir Muster nennen wollen. Das ist insofern neu, als wir neu über Altes reden. Abstraktion ist eine neue Art zu reden, nur eine "facon de parler". Gleichlang oder anzahlgleich ist eine Äquivalenzrelation. Ich kann jetzt über das Muster III reden, invariant in Bezug auf alle Darstellungen im Werteberich von y, wenn nur die Bedingung gleichlang eingehalten wird.  Die Lochkarten für den Wertebereich kann ich wegwerfen. Mich interessieren ja nur alle Gleichlangen zu III, auch neuproduzierte. Früher in der Scholastik sagte man "Man hat das Wesentliche erkannt." Ich darf jetzt mit "Muster III" Sätze bilden z:B. :  "Muster III ist ungerade."

Die Definition von Äquivalenz (Leibniz, 1664-1716) lautet: x ist äquivalent zu y, wenn alle Aussagen P über x auch, also P(x), auch für y gelten, also P (y), und umgekehrt. Man sagt auch: P( ) ist invariant (d.h. der Wahrheitswert von P( ) bleibt unverändert) in Bezug auf das Austauschen von x durch y und umgekehrt. Psychologen und Juristen begreifen das nie. Abstraktion ist seit Frege ("Die Grundlagen der Arithmetik", 1884, bei Reclam billigst zu erwerben) sprachlogisch zu verstehen. "Aussage" (proposition) ist ein sprachlogischer Terminus. Haben die Mathematiker die Fregesche Abstraktionlehre anerkannt?  Ja, sie haben es mit ihren Äquivalenzklassen, aber nur extensional, das Intensionale interessiert sie auch nicht.

BD: Habe ich Sie richtig verstanden? Ich wähle mal ein sehr praktisches Beispiel: Ein Passwort muss 8-20 Zeichen lang sein und muss mindestens einen Großbuchstaben A-Z und ein Sonderzeichen §$%&/()=?*+~# enthalten. Sagen Sie, diese syntaktische Regel spezifizert (implizit) ein Abstraktum, eine nicht explizit aufgelistete Menge (oder Klasse) mit den zugelassenen Elementen?

HW: Ja! Sie definieren eine Menge von Passwörtern als Abstraktum. Alle Mengen sind Abstrakta, aber das tun sie doch explizit durch Angabe von Regeln, die die Eigenschaften der Elemente der Menge bestimmen. Die Regeln sind aber keine Axiome (allgemein wahre Aussagen), so z.B. wie Peano seine Axiome zur impliziten Definition der natürlichen Zahlen einführte. Man kann die Peano- Axiome konstruktiv beweisen. Ihre Regeln kann man nicht beweisen. Die sind einfach schlicht so, um es Eindringlingen schwer zu machen. Peano, der war gegenüber dem zahlen-gottgläubigen Kronecker schon ein Fortschritt.

Wir Wedekinder sind immer ganz traurig. Es müsste eigentlich Peano-Dedekind-Axiome heißen. Unser berühmter Fast-Namensvetter Richard Dedekind (übrigens Nachfolger von Gauß in Braunschweig) wird leider immer verschwiegen. Dedekind war ein berühmter Zahlentheoretiker. Wenn ich mich Mathematikern vorstelle, fragen die in der Regel nach  "wie heißen Sie? Meine prompte Antwort: "Nein, nein, nicht so wie Sie meinen."

BD: Wenn Sie jede implizit definierte Menge (oder Klasse) als Abstraktum bezeichnen, so wundert mich das zwar. Falls es wirklich keine guten anderen Begriffe für diese Form der Bildung von Gruppierungen gibt, werde ich es wohl akzeptieren müssen. Also wimmelt es auch auf der Erdoberfläche nur so von Abstrakta, nicht nur im Himmel der Philosophen. Nur das einzelne Element einer Menge ist noch konkret, die Menge selbst jedoch nicht mehr, sofern die Elemente nicht explizit gelistet sind. Man lernt nie aus!