Wer nächste Woche die Vorlesung von Ihnen die Vorlesung hören möchte,
der muss dann in den F1-3-2 kommen.
Das hatte ich auch schon mal irgendwo in das Komsi reingeschrieben,
aber nicht als E-Mail, sondern als Ankündigung oder als Material.
Keine Ahnung. Also nächste Woche,
ich werde im F1-3-2 sein,
von 14.15 Uhr bis 15.45 Uhr.
Und das ist ja dann vielleicht auch,
haben Sie
das schon mitbekommen
Nein. Okay, ich gehe nicht davon aus,
dass ich das noch mal anhören. Nächste Woche findet die
Vorlesung im F 1, 3, oh super,
dann 1, 2, 3 mit einem kleinen Zahlendreher.
Auf Platz 2. Ja, der hat es gemerkt, ja.
Ja, so. Zum Thema, wo sind wir denn? Logisch,
letzte Woche haben wir uns über Kooperation,
Koordination unterhalten und damit ist das jetzt so von der Seite der,
Wie wollen wir die Welt according to the tools and materials approach?
Wie wollen wir die betrachten? Damit ist das Kapitel abgeschlossen.
Wir können jetzt Einzelplatzsysteme, können wir mit den Entwurfsmetaphern gestalten.
Wir können Kooperationszusammenhänge entsprechend unterstützen. Wir haben nicht nur ein
fachlich motiviertes Benutzungsmodell kennengelernt, sondern auch ein Kooperation,
nicht nur ein Kooperationsmodell, sondern eine ganze Reihe von Kooperationsmodellen,
die wir grob in implizit und explizit
unterteilt haben
Ja, wir haben schon ansatzweise,
also vom Fachlichen her haben wir noch reingeschaut in unterschiedliche Arbeitsplatztypen und wir haben uns auch angeschaut,
wie man das jetzt so von der Unternehmensseite her,
von den Arbeitsprozessen her, wie man das so modellieren kann.
So, und jetzt biegen wir so in,
jetzt müssen wir noch zwei Aspekte im Rahmen, die im Laufe des Semesters beleuchten.
Der eine Aspekt ist, wie können wir dieses,
so dieses konzeptionelle Gerüst, wie können wir das technisch umsetzen,
weil der Anspruch ist schon, dass wir,
also nicht nur über Softwareentwicklung dann sprechen können und dann eine Menge von meinetwegen Folien hinterlassen,
wie so ein System aussehen könnte, dass wir nach Werkzeugmaterial modelliert haben,
sondern wir wollen auch eine Idee davon vermitteln,
wie das konstruiert werden kann.
Dazu ist jetzt zwei, drei Vorlesungen geben,
die heutige Vorlesung beschäftigt sich mit einer dreibuchstabigen Abkürzung,
die ihnen so, da möchte ich fast für wetten,
selbst wenn ihr Berufsleben noch einige Jahrzehnte andauert,
serviceorientierte Architekturen sind jetzt so seit zehn Jahren, so ungefähr,
sind die im Gespräch und die sind da,
um da zu bleiben.
Also wie Kann man so mit dem Gedankengut des Warmansatzes,
wie kann man mit sogenannten Services, fachlichen Dienstleistern,
wie lassen sich Softwaresysteme technisch so konstruieren,
dass sie auf einer serviceorientierten Architektur basieren.
Dazu werden wir heute was machen. Dann werden wir uns
in den nächsten Wochen mit der Konstruktion von,
noch mit weiteren technisch konstruktiven Aspekten beschäftigen.
Und das zweite, ich hätte von zwei Dingen gesprochen,
denen wir uns noch zwei Themen, denen wir uns noch widmen wollen, vorgehensweise.
Da werde ich Ihnen ein bisschen was erzählen über Wie lassen sich die Systeme,
die wir technisch bauen wollen, wie lassen,
welche Vorgehensweisen sind geeignet, um diese Systeme zu konstruieren?
So, das dazu. Heute, wie gesagt,
serviceorientierte Architekturen. Es gibt unterschiedliche Motivationen für serviceorientierte Architekturen.
Ich greife jetzt hier mal eine Motivation raus,
die uns so in den letzten Jahren so ein kleines bisschen
uns Softwareentwickler in den letzten Jahren so ein kleines bisschen
begleitet hat
Was wir wirklich, wenn ich jetzt sage,
was wir wirklich gut können, habe ich schon das Ende
des Satzes, das habe ich schon im Kopf.
Jetzt, aber bevor ich das ausspreche, habe ich schon
im Kopf, dass wir das gar nicht gut können.
Also, was wir wirklich gut können, jetzt kommt das,
was ich eigentlich sagen wollte, sind Rich Client-Software-Systeme.
Also Rich Client bedeutet sowas wie Word. Das war mein
dicker Hintern. Ja. Redge-Client bedeutet sowas wie, Word,
PowerPoint, so Softwaresysteme, bei denen Rechenleistung für die Darstellung
der Oberfläche und für die Funktionalität auf einem Rechner liegt.
Das können wir, das beherrschen wir. Im Prinzip,
die Softwaretechnik dafür ist ausgereift,
sodass das im Einzelfall so ihnen mir uns,
sodass das nicht gelingt, etwas qualitativ Hochwertiges zu bauen,
ist passiert halt.
Aber im Prinzip können wir das
ganz gut
Das war so die Zeit, sagen wir mal so,
so 80er Jahre mit dem Aufkommen von so Desktop-Computern,
wo eine Desktop-Systeme, die Softwaretechnik für Desktop-Systeme entwickelt.
Davor, so die Mainframe-Systeme, das ist etwas,
das wir wirklich gut können. Das können Sie bloß nicht.
Das können Sie aber lernen. Das werden Sie möglicherweise auch noch lernen,
wenn Sie in Organisationen arbeiten, in denen noch Mainframe-Frame-Systeme eingesetzt werden,
also Bankenversicherungen, so typischerweise Organisationen,
in denen schon sehr lange Software entwickelt wird.
Weil die Dinger sind immer noch im Einsatz
und die laufen und alles ist gut
Alles. Sie laufen auf jeden Fall noch. Und sie
wollen gepflegt und gewartet werden. Was wir schon nicht mehr
so gut können, ist das, was einherging mit dieser Desktop-Revolution.
Also Rich Client-Software, gut, die ist insofern einfach,
als dass es keinerlei Verteilungsproblematik gibt.
Das läuft halt auf so ein Word, um dabei zu bleiben.
Das läuft halt hier auf meinem Desktop.
Und irgendwann ist das Dokument fertig und dann nehme ich das
und tue das als Anhang in eine E-Mail und gut ist.
Das ist so die Art von Verteilung, die von Das wäre...
Ich möchte den Tag erleben, wo einmal mit Lecture to Go alles klappt.
Er wird kommen. Ich bin mir ganz, ich gebe
die Hoffnung nicht auf. So, wo war ich
stehen geblieben? Verteilungsproblem. Bridge-Client-Software kennt keine Verteilungsproblematik,
weil das sind halt, sind Systeme,
die laufen in einem Prozessraum und der Softwareentwickler braucht sich darüber
keine Gedanken machen
Und dann sind die Menschen auf die Idee gekommen,
hm, hm, Client, kleinen Server-Software zu bauen.
Also es ist jetzt ein bisschen Holzschnittartig, aber so,
wenn man dann so Anwendungssoftware baut,
dann will man diese Anwendungssoftware möglicherweise,
also die Funktionalität dieser Software nicht immer auf allen Klienten ausrollen,
sondern man möchte so einen bestimmten Teil der Funktionalität und sei es nur eine Datenbank,
möchte man zentral nutzen.
Weil ich möchte auch von verschiedenen Arbeitsplätzen nicht nur auf die gleiche,
sondern ich möchte sogar auf dieselbe Datenbank zugreifen können.
Und ab jetzt wird es schwierig
Weil wir haben es dann mit einem Problem zu tun,
für das es keine prinzipielle Lösung gibt.
Nämlich in welcher Art und Weise verteilen wir die Funktionalität
eines Stücks Software zwischen einem Klienten und einem Server?
Das kann man so oder so machen. Man kann sowas
bauen, so Desktop-Systeme. Und selbst da hat man schon
jeden beliebigen Entscheidungsspielraum. Also ich werde nur von dem Technik,
von dem Technischen Entscheidungsspielraum, bei euch ganz viel, so ultra-Ritch-Client,
der eigentlich nur noch eine Datenbank hinten verwendet oder baue ich etwas,
das ziemlich dünn ist und also auf dem Server viel Funktionalität implementiert.
Das ist also technisch ist das, so ist das
in keiner Weise vorherbestimmt, wie man das macht.
Dann kommt noch was anderes hinzu. Also das ist so eine softwaretechnisch gesehen echte Herausforderung,
um nicht zu sagen ein Problem,
dass auf einmal Leute angefangen haben,
also das Internet zu entdecken,
so zu entdecken und dann wollten die dann eben auch über
den Browser auf einmal nicht nur Internetseiten gucken,
sondern die wollten darin auch
irgendwas programmieren
Du hast ja technisch gesehen erstmal nicht so besonders aufregend ist.
Nur fingen die dann an,
so als echte Konkurrenz zu den Desktop-Systemen so aufzutreten,
weil mit den Webtops sind ja, also ganz entscheidende Vorteile verbunden.
Fällt Ihnen, also jetzt von der technischen administrativen Seite,
fällt Ihnen da vielleicht was ein,
was also so ein Webtop gegenüber einer Desktop-Lösung vorteilhaft macht.
Ja, bitte. Sieben Portale. Portabel.
Da ist man
kein Kleinziehen
Im Grunde etwas anderes ist als Portabilität. Du musst da
ein großer Browser geben. Ja, also es gibt kein Verteilungsproblem.
Das ist das, was Sie mir sagen wollten.
Ja, ja. Danke. Ja, das ist Ihr Anwalt
. Er sagt, ja, das wollte er sagen.
Ja, es ist sehr richtig. Ja, ja,
genau. Das leuchtet ja ein, dass jeder Administrator sagt,
also wenn ich vor die Wahl gestellt werde,
Desktop oder Webtop, sage ich doch immer webtop,
weil so Verteilungsprobleme habe ich dann nicht mehr.
Browser einmal installiert, dann läuft das Ding.
Und ich muss auch nicht über so Sachen wie,
Also es sind alle Versionen, die ich verteilt habe,
sind die aktuell und so, brauchen überhaupt keine Gedanken mehr machen.
Das ist wunderbar. Fällt Ihnen von der Benutzbarkeit irgendwas ein,
was also für oder gegen die eine Lösung war.
Die eine oder die andere Lösung spricht.
Ja. So, wie sieht es mit offline Benutzbarkeit aus?
Ja, Browser ohne online, kein Spaß.
Wenig Spaß jedenfalls. Ja, das ist ein starkes technisches Argument.
Kann das garantiert werden? Kann ein Online-Zugang garantiert werden?
Ist also für Inhouse-Applikation Ist es möglicherweise ein nachrangiges Argument?
Aber schicken Sie mal einen Vertrieb, also in Deutschland,
so rum. Und dann ist,
und dann spätestens dann fangen Sie an,
so als Softwareentwickler etwas genauer hinzuschauen, wenn also die Werbung verspricht,
98 Prozent Abdeckung in der Bevölkerung bezüglich der Erreichbarkeit.
Oder 95 Prozent. So ist es. Es will heißen,
also so hier kurz hinter der Stadtgrenze ist,
also Feierabend
Und wenn sie dann so auf ihrem mobilen Endgerät,
also wollen sie mit dem Kunden etwas besprechen und es ist eine Browser-Applikation,
dann ist, haben sie,
wenn der Kunde nicht selber über irgendwas anderes verfügt,
dann haben sie ein Problem.
So, ja, also das sind so die technischen Randbedingungen.
Ansonsten, wie sieht es denn aus mit Benutzbarkeit von Web-Applikationen?
So die klassische Web 1.0-Applikation.
Ja? Von Reihenmännchen ist der geplatzt
Ja, das ist, also das gesamte Interaktionsverhalten ist also,
sagen wir mal, im Vergleich zu den Desktop-Applikationen eher ärmlich.
Die heißen zwar jetzt, also der eine heißt Rich Client
und der andere heißt nicht pur, pur klein,
so die hier werden ja dann auch gerne als FinClient werden die,
werden die bezeichnet.
So, also das gesamte Benutzungsverhalten ist ja eher dann so Seiten,
also das Web 1.0-Applikationen ist eher so seitenorientiert,
will heißen
Jede Menge Sachen werden eingegeben und schickt man das Formular.
In der Regel schickt man ab und dann wird einem gesagt,
das ist also, irgendwelche Sachen sind falsch eingegeben worden.
Möglicherweise wird auch nur der erste Fehler bemerkt. Also das
ist alles eher, ist alles eher lästig. So,
das hat sich heute mit so,
mit Ajax basierten Frameworks hat sich das alles,
also extrem stark verbessert,
aber so mindestens auf der technischen Seite ist das immer noch etwas anspruchsvoller,
mindestens, was die Infrastruktur anbetrifft, als eine klassische Desktop-Applikation.
So diese hier, diese, das ist Wireless-Application-Protokoll,
da haben sie möglicherweise noch nie was davon gehört.
Also das war so Anfang der 2000er
Jahre dachte man jetzt, also jeder muss jetzt von seinem
damals noch, also so grün auf Schwarz-Handy,
müsste jetzt also seinen Kontostand abfragen.
Und das gab es also dann auch neue Protokolltypen dafür.
Das hat sich heutzutage, hat sich eigentlich ziemlich erledigt.
Aber das, was das hier so zeigen soll,
sind so die unterschiedlichen Benutzungsschnittstellen. Die Idee, ich möchte
dieselbe Funktionalität von unterschiedlichen Frontends aus bedienen können.
Diese Idee ist ziemlich tragfähig. Die ist insofern tragfähig
als das
Das ist so sicher wie das Armen in der Kirche,
das demnächst, also die nächste Art von Frontend dazukommt.
Und das können dann so exotische, da freue ich mich schon drauf.
Also so exotische Sachen sein, wie, also dass irgendwas
in meine Brille projiziert wird, so Augmented, Reality.
Ich gucke durch meine Brille und sehe dann ihre Matrikelnummer,
in welchem Semester sie sind.
Lohnt sich das, mit ihnen zu sprechen?
Oder irgendwas, ich spinne jetzt gerade rum
Ja. So, wer sind sie eigentlich? Gott, will ich das alles wissen?
Ja, das ist dann eine andere Frage. Das ist dann,
das werden sie dann nächste Woche auf der ITMC-Konferenz,
werden sie sich das anhören können,
wenn sie sich den Vortrag mobiles Internet, Fluch oder Segen,
diese Frage kann man für fast alles, also,
was die IT entwickelt, kann man Fluch oder Segen,
das ist immer ein gutes Thema.
Okay, also, die Idee, eine Funktionalität,
so will ich Stine in meiner Brille haben.
Ja, eine amüsante Vorstellung, das Stine,
ein Brillenfrontend hat
Das Grauen vielleicht auch in der Brille. So,
also ein verschiedene Frontends, aber einmal die Funktionalität.
Wir hatten uns das schon mal, ich jetzt endlich mal weiterkommen.
Also es gibt so die, so für unterschiedliche Typen von Arbeitsplätzen,
also kann man auch sagen, naja,
was ist denn da jetzt so eigentlich geeignet, so als oberflächentechnologie.
Also hier unsere Königsdisziplin, der Arbeitsplatz für eigenverantwortliche Expertentätigkeit.
Also der wird mit ziemlicher Sicherheit auch noch so weiterhin,
der so Desktop-artig implementiert werden, also so eine Rich Client Architektur aufweisen,
so beim Geldautomaten, naja gut, das ist also,
ob der jetzt einen Browserfront nennt oder,
also so mit proprietären Technologien implementiertes Rich Client Front ent hat, Time Will Tell.
Also da sind, sie sehen hier diesen Merksatz,
also je nachdem, welche Art von Frontend, also je nachdem,
welche Art von Arbeitsplatz, also ich unterstützen will,
also gibt es immer noch, ich will nicht sagen,
dass das komplett davon abhängig ist oder funktional abhängig ist,
aber es gibt immer noch, also so bestimmte,
denke ich, bestimmte Technologien eignen sich einfach besser,
um einen bestimmten Typ von Arbeitsplatz zu implementieren,
als das bei anderen der Fall ist.
Also das hier würde ich eher ungern,
also browserbasiert implementieren auch, also Stand heute jedenfalls,
aber so, dass der Browser als Betriebssystem der Zukunft
so diskutiert wird und dann alles eben im Browser läuft,
inklusive der Anbindung an,
also lokale Dateisysteme und so weiter
Ich meine, dass technisch, so spricht da erstmal jetzt
nichts dagegen, so in diese Richtung nachzudenken,
so Stand heute, sind es aber eher so Desktop-Applikationen.
So, ich bewege mich mal so in Richtung,
also wir kommen so historisch betrachtet,
kommen wir so von der Ultra-Ritch-Client-Ultra-Ritch-Client-Konstruktion und da hatten wir dann
auch schon so nicht in dieser Veranstaltung,
aber schon in anderen Veranstaltungen,
so haben sie schon so ein bisschen was darüber gelernt
Wie wird so Werkzeugmaterial? Wie wird so ein Werkzeug konstruiert? Naja,
also das hat so in der vollen Breite, das besteht so ein Werkzeug aus,
also drei Komponenten, also logisch eigentlich zwei Komponenten.
Eine ist also die Funktionskomponente, Fachlichkeit, wird dort implementiert.
Also es gibt diese Trennung zwischen Fachlichkeit und Präsentation.
Also ist schon so, ist auch schon so im Kleinen,
ist es schon ein guter Gedanke. Und dann kann man sich,
also so die Art der Darstellung kann man,
also hier ist das jetzt in der vollen Blüte,
aufgeteilt, also eine Interaktionskomponente,
da wird also die Art der Interaktion festgelegt und in der Präsentationskomponente,
also wird dann so die tatsächliche Oberflächenkomponente ausgewählt.
Also um mal zu sagen,
es muss irgendwo eine Eins aus N-Auswahl jetzt vorgenommen werden,
also das ist die Art der Interaktion und ob das Eins aus N jetzt,
also ein Pull-Down-Menü ist oder eine Radio-Botten-Box oder so ist ja für,
also die Art der Interaktion völlig unerheblich, also kann man dieses,
kann man das nochmal abstrahieren und die eigentliche Darstellung
Auswahl findet in der Präsentationskomponente statt. So kann man das,
so kann man das machen, typischerweise fallen also die beiden Komponenten
hier zusammen und ein Werkzeug besteht also dann aus Funktions- und Interaktionskomponente.
So, so wird also ein Werkzeug implementiert und das kann auf dem Material realisiert,
von mir aus als Business-Object, kann das implementiert werden.
Ja und das ist also so alles in einem Prozessraum
und es ist gut, weil das Ding läuft.
Man weiß, wie das zu konstruieren ist. Jetzt kommen wir mit unseren,
kommen wir Jetzt sind diese kleinen Server-Problematik hinein und das soll jetzt mal gleich so am Beispiel,
also wann braucht man sich, also spätestens Gedanken über kleinen Server machen, ist,
wenn man dann so irgendwas hier so mit Browser-Frontend machen will.
Jetzt will ich das machen und also sagen wir mal,
das hier ist so die Welt, aus der ich komme,
so da ist also, das habe ich alles mal so Rich Client-mäßig,
habe ich das hier implementiert und es läuft und jetzt sagt jemand,
wir müssen unbedingt ins Internet und Also das,
was ich weiß, ist also so das Online-Banking,
also da habe ich jetzt abgesehen davon,
dass ich mir eine unfassbare Menge von neuen Problemen einfange,
die damit verbunden sind.
Also ich weiß, ich musste also so hier für die Kunden da draußen,
also muss ich also sowas zur Verfügung stellen, damit die,
also auch mal so was wie eine Anfrage stellen können.
Es läuft dann möglicherweise, je nachdem,
also so in welchen Sprachen das jetzt hier implementiert ist,
nehmen wir mal was Gutartiges an, so was wie Java,
worauf das aber hinausläuft, möglicherweise ist,
also wenn ich nicht, wenn ich nicht,
also die Trennung von Nutzungsschnittstelle und fachlichen Wissen,
also gut gewählt habe.
Das läuft darauf hinaus, dass ich also bestimmte fachliche Funktionalitäten mehrfach implementiere.
Und das ist natürlich eine Katastrophe. Das ist so mehrfach Implementation ist etwas,
das ist, das ist, wie ist denn das?
Das ist wie Drogenkonsum. Drogenkonsum,
ich rede jetzt wie die Jungfrau von Kinder,
ich habe da ja keine Ahnung von,
aber ich stelle mir das so vor,
dass das also am Anfang total klasse ist und dann hat man irgendwann ein Problem,
weil man ist eben auf diese Droge angewiesen.
Und sowas wie Code kopieren ist eben wie Drogenkonsum.
Man kopiert den Code und das läuft dann schon ganz schnell
und alle sagen, super. Und dann stellt jemand fest,
also dass in dem kopierten Code ein Fehler drin ist und dann ist es nicht mehr super.
Dann ist nämlich die Frage, also wo habe ich jetzt überall diese Duplikate?
Das ist dann die Phase des Entzugs, die dann,
also die dann einsetzt. Vielmehr der Entzug setzt ja ein,
wenn man diese Code-Duplikate also versucht zu entdecken,
weil ich rede ja jetzt erst, Duplikat hört sich immer so an,
als würde man das einmal kopieren,
aber so richtig erfolgreicher Code,
der zieht sich ja dann also durch so eine IT-Landschaft,
also wie ein Krebsgeschwür mit Metastasen
So, also lassen Sie das. Wir wollen das nicht
. Sie tun sich da auch so langfristig keinen Gedanken,
denen keinen Gefallen, den Gedanken, den sie fordern,
den sie folgen sollten, ist der hier.
Das ist das Once and Only Once,
also das Vora-Prinzip, Wright Once Reed, Reed Always.
Wir wollen so fachliche Funktionalität, ein einziges Mal wollen wir
die schreiben
Ziemlich, also ich sage das jetzt hier so und ich kann das,
weil ich stehe hier und also ich werde eine Prüfungsfrage dann stellen,
ist Code duplizieren gut oder schlecht und dann müssen sie gut ankreuzen und dann kriegen sie den Punkt.
Möglicherweise stelle ich die Frage etwas subtiler. Es ist in der Praxis
extrem schwer durchzuhalten, dieses Prinzip. Und wenn ich jetzt so sage,
man muss hier einen guten Schnitt wählen,
dann ist das natürlich schön gesagt,
so einen guten Schnitt wählen,
bloß also wo dieser Schnitt zu legen ist,
das wird sich in der Regel erst rausstellen,
also wenn man mal so ein zweites Frontend versucht,
also zu integrieren
Weil erst dann weiß man, an welchen Stellen man Abhängigkeiten zur Benutzungsschnittstelle in seiner ersten Implementation hat.
Also es ist immer mit einem gewissen Re-Engineering-Aufwand verbunden,
so eine zweite Oberflächen-Technologie zu unterstützen. Das wäre jetzt,
also worauf ich mich jetzt in die Richtung, in die ich mich bewege. Hoppla,
die Richtung, in die ich mich bewege, ist,
also nachdem also schon viele Menschen diese schmerzhafte Erfahrung gemacht haben,
das ist halt so eine Service-Architektur und so wie man da hinkommt, das scheint ein Gedanke zu sein, wie der tragfähig ist. So,
es ist ja jetzt nicht nur so, dass so,
dann kommen So Tic-Tac-Toe-Programmierer wie sie kommen also in die Organisation hinein und denken,
sie könnten jetzt irgendwas mit Java reißen und dann ist aber,
worauf sie sich einstellen können, ist,
also ich habe schon von den existierenden Host-Mainframe-Systemen gesprochen, also hinter der Brandmauer,
da stehen noch so richtige Maschinen und die sind dann typischerweise,
ist die Programme, die auf denen laufen,
das sind, die sind in richtigen Programmiersprachen geschrieben,
also sowas wie Cobol PL1, teilweise C, teilweise Assembler,
kommen sie, also da müssen sie irgendwie rankommen.
Die kann man nicht einfach abschalten, diese Dinge,
weil die eben viel Fachwissen und damit auch Investitionen von Unternehmen enthalten,
die Herausforderungen, um nicht zu sagen,
das Problem ist, dass das mit dem,
was die Kundschaft heute erwartet oder was auch Benutzer in Organisationen heute erwarten,
dass die verbunden werden, also mit dem,
was man so aus dem Alltag,
wenn man sich so ein iPad oder irgendwas ähnliches kauft,
was man da kennt.
Also muss diese Mauer, diese Brandmauer hier zwischen den Altsystemen,
die also vom Look and Feel sowas anderes sind,
also zu unseren Systemen, das,
was wir heute bauen wollen, dass diese Brandmauer durchlöchert wird,
beziehungsweise dass die, also da umgangen wird,
sodass das miteinander verbunden wird.
Und um es noch schlimmer zu machen, es gibt keine Organisationen,
in denen es eine einheitliche Software-IT-Landschaft gibt.
Das gibt es einfach nicht. Die Organisation,
die so organisiert ist, die kann höchstens drei Mitarbeiter haben
Wenn das aber Unternehmen sind, die eine gewisse Größe haben, dann haben die typischerweise eine Geschichte.
Eine Geschichte bedeutet, die haben Software vor 10,
20, 30 Jahren angefangen einzuführen und das Zeug läuft.
Es gibt niemanden, der sagt,
also ich muss das jetzt ablösen, einfach nur,
weil es abgelöst werden soll, weil es nicht mehr aktuell ist,
wenn das Zeug seine Aufgabe tut, dann tut es das.
Das kann ich Ihnen aus meiner eigenen Erfahrung,
kann ich Ihnen das nur, also kann ich das nur,
also dass ich mich bestätige, wird sie nicht wundern,
aber ich habe jetzt gerade, als ich das sagte,
habe ich jetzt erstmal von anderen Organisationen gesprochen,
als die Organisation, für die ich außerhalb der Uni selbst arbeite.
Wir haben so ein Zeiterfassungssystem. Das war jetzt nicht vor tausend Jahren,
aber es ist im letzten Jahr tausend, ist es also implementiert worden.
Es war so eine der ersten browserbasierten Lösungen,
die wir so in der Firma eingesetzt haben.
Das Ding läuft immer noch und es ist okay. Und ich weiß genau,
wenn ich das Ding jetzt also so umstrukturieren sollte,
dass es also cloudfähig ist, dann muss ich da Geld reinstecken.
Und jetzt stehe ich da. Was habe ich denn eigentlich
davon, wenn das in so einer blöden Cloud läuft?
Ja, habe ich was davon,
weil ich brauche mich nicht mehr selbst
drum kümmern
24-7 und also Datensicherheit, es wird mir alles garantiert und so.
So, aber worauf ich hinaus will, ist,
also es gibt diese Alt-Software und es gibt das hier, Komponenten von Drittherstellern.
So, und die haben also, da habe ich jetzt,
ist sowas wie SAP, brauche ich halt.
Ich will mich um Lohnen, Finanzbuchhaltung,
ob das jetzt SAP oder Navision oder irgendein anderes,
Fibu-Lobu-System ist. Ich will mich um sowas nicht kümmern,
also wird es so etwas mit sowas existieren und abgesehen davon
würde ich sowieso eigentlich keine Software selbst entwickeln
Weil die Fertigungstiefe, die Säule verringert werden,
Fertigungstiefe verringern bedeutet, so weit wie möglich Standardsoftware einsetzen.
Also damit ich mich auf meinen Kerngeschäft, das ich als Organisation verfolge,
konzentrieren kann. Also ich will Vora, ich will,
das war jetzt, also wenn ich selber Software schreibe,
nicht Code duuplizieren, ich will meine Altsysteme,
will ich integrieren und ich will Komponenten von Drittherstellern,
sprich Fremdsysteme.
Also will ich auch, also zu einem einheitlichen Ganzen,
will ich
das benutzen können
Dass man alles so will. So, jetzt guckt man sich an.
Was steht mir denn da so an Technologien eigentlich zur Verfügung?
Und das ist im Großen und Ganzen, das ist jetzt eine sehr persönliche Einschätzung.
Das ist im Großen und Ganzen das Grauen. Dass wir
sowieso keine, also auf der Ebene will ich,
also nicht, die will ich keine Drittsysteme ansprechen, oder?
Also es sei denn, man hat wirklich,
also man hatte irgendeine Art von Fable für, würde ich niemandem zu raten.
Das hier kann ich einsetzen, wenn ich also in einer
reinen Java-Welt bin, bin ich eher selten.
Das hier Object Request, Broker, Architecture, was ein ziemlich schwergewichtig.
EJBs, Enterprise Java Beans, also bringt, ja,
das ist eine Verteilungstechnologie, gut, aber es ist ziemlich schwergewichtig, macht ziemliche Annahmen über meine Software-Architektur. Eigentlich will ich mich darauf nicht einlassen,
Webservices, aha, das könnte was sein,
das könnte was werden, vielleicht sogar restful, Webservices,
das könnten wir uns mal näher angucken und das werden wir auch,
weil das so verspricht, also so, das hat nichts mit Web,
Webtop oder so zu tun und das hat einfach was über die Art und Weise,
wie kann ich auch diese Services zugreifen,
auf die Funktion die mir als Service zur Verfügung gestellt werden,
das ist zielführend oder was heißt zielführend,
da ist also Potenzial, das ist eine Chance.
Und ich kann für all diese Verteilungstechnologien,
kann ich hier so diese Fragen stellen,
weil also das da, wenn man da nicht aufpasst,
ist es typischerweise etwas unperformant, dass das natürlich extrem performant,
aber standardisiert, das ist wohl kaum.
Es ist einfach, ich predige ja hier,
wenn ich vor ihnen stehe,
mindestens einmal pro Vorlesung,
Design,
Spielraum klein machen
Nicht jedes, es ist keine Spielwiese,
in der wir uns da im Unternehmensalltag bewegen,
sondern der muss halt on time on budget
on scope müssen. Also Funktionalitäten implementiert werden. Und wir können,
also wir gucken uns mal an, also wie kriegen wir das hin,
dass wir uns also hier in so eine Richtung bewegen können.
Und die Idee, die jetzt mit dem Wamm am Ansatz
unmittelbarsten verbunden ist, sind die sogenannten fachlichen Services.
So, könnten Sie bitte mal das Ding da
einen kleinen Moment ausschalten?
Danke. Ich