Liebe AS/400, iSeries, i5, system i und IBM i Gemeinde

[Fuerchau]

Wir, also die FTSolutions, arbeiten schon lange (nun seit 20 Jahren) in der BI-/DataAnalytics-Branche.
Die Idee des Selfservice-BI, also der User baut sich seine Dashboards selber, hat sich inzwischen in Luft aufgelöst. Dies betrifft sogut wie alle BI-Tools (auch und gerade Power-BI).
Warum?
Der End-User hat keine Ahnung von der inneren Datenbankstruktur um die richtigen Daten überhaupt zu finden.
Wenn der End-User dann andlich irgendwelche Daten geladen hat, scheitert er an komplexen Fragestellungen, wie die Daten analysiert, Warnungen, farbliche Markierungen und auch nur komplexere Ausdrücke (also Formeln) geschrieben werden.
Wenn es dann noch um Drilldown, dynamische Filterung, u.v.m. geht, ist er letztendlich heillos überfordert.
Wenn denn dann verschiedene User sich treffen um über die ermittelten Daten zu sprechen, wird dann häufig festgestellt, dass dann jeder eine andere Sicht der Daten hat und es meist zu keiner Übereinstimmung kommt. Das Meeting wird dann meist abgebrochen um erst mal die Daten untereinander zu konsolidieren. Das war i.W. das Excel-Chaos.

Daher bieten wir eben unsere Dienstleistungen zum Aufbauen von Dashboards an und unsere Kunden sind froh darüber.

Genau aus diesen Gründen glaube ich nicht, dass euer E30 vom normalen End-User geeignet ist, komplexe Abläufe in E30-Code zu überführen.
Meine persönliche Erfahrung bei der Softwareentwicklung ist pauschal so:
20% eines Programmes sind Funktionscode, also Beschreibung dessen, was zu tun ist.
78% des Programmes sind dann Userfehler-Verhinderungscode. Also die berühmten Plausibilitätsprüfungen, die den gewünschten Ablauf dann sicherstellen.
Die restlichen 2% sind i.d.R. Nice-To-Have-Funktionen, die nach Kostenabschätzung meist die ersten 98% um ein mehrfaches übersteigen können.

Jeder Kunde, den ich bisher unterstützt habe, war diesbezüglich mit meinen Leistungen sehr bis äußerst zufrieden. So wie ich einen Sachbearbeiter in seiner Tätigkeit eher selten ablösen kann, sowenig ist es umgekehrt möglich, dass dieser Sachbearbeiter vernünftige Programme erstellen wird.
Wenn er privat Programme generiert, wie und womit auch immer, und damit Erfolg hätte, wäre er kein Sachbearbeiter geworden.

Ich habe schon viel gesehen, was da so mit Excel an Formeln, Verweisen, z.T. VBA-code zusammengezimmert wurde und dann irgendwann durch ein richtiges Programm abgelöst werden sollte, weil der Zimmerer dieser Dokumente abgängig geworden ist.
Dasselbe gilt auch für MS-Access, wenn es als Nicht-Entwickler verwendet wurde.

Deine Karrikaturen sind ganz nett, aber leider sehr E30-lastig;-).

Ich will damit nicht sagen, dass E30 schlecht ist, sondern dass ich auch für E30 ein gewisses Maß an IT-Erfahrungen mitbringen muss.

Historisch gesehen (1991/1992) habe ich mich mal mit Synon auf der AS/400 beschäftigen müssen.
Die war/ist auch ein sog. 4GL-Tool.
Nachdem die ersten 5-10 Progrämmchen fertig waren, war ich erstaunt, dass diese als Programmobjekt jeweils 500KB überstiegen, für ein einfaches Bildschirmpflegeprogramm. Nach der ersten Hochrechnung über die Anzahl der geplanten Programme und die Größe der generierten Datenbank musste ich leider feststellen, dass die geplante Hardware hier nicht ausreichen wird. Wir hätten ca. 5 Mio.DM zusätzlich für die Plattenaufrüstung investieren müssen.
Synon habe ich dann rausgeschmissen und wir haben dann native COBOL auf der AS/400 entwickelt.
Die Programme/Module waren dann zwischen 50-200 KB groß und die geplante Hardware (damals 72 Systeme AS/400 F2 mit 988MB Festplatte, den Hauptspeicher weiß ich nicht mehr, sowie Rel V2R1).

[E305GL]

Wir, also die FTSolutions, arbeiten schon lange (nun seit 20 Jahren) in der BI-/DataAnalytics-Branche.
Die Idee des Selfservice-BI, also der User baut sich seine Dashboards selber, hat sich inzwischen in Luft aufgelöst. Dies betrifft sogut wie alle BI-Tools (auch und gerade Power-BI).
Warum?
Der End-User hat keine Ahnung von der inneren Datenbankstruktur um die richtigen Daten überhaupt zu finden.
Wenn der End-User dann andlich irgendwelche Daten geladen hat, scheitert er an komplexen Fragestellungen, wie die Daten analysiert, Warnungen, farbliche Markierungen und auch nur komplexere Ausdrücke (also Formeln) geschrieben werden.
Wenn es dann noch um Drilldown, dynamische Filterung, u.v.m. geht, ist er letztendlich heillos überfordert.
Wenn denn dann verschiedene User sich treffen um über die ermittelten Daten zu sprechen, wird dann häufig festgestellt, dass dann jeder eine andere Sicht der Daten hat und es meist zu keiner Übereinstimmung kommt. Das Meeting wird dann meist abgebrochen um erst mal die Daten untereinander zu konsolidieren. Das war i.W. das Excel-Chaos.

Daher bieten wir eben unsere Dienstleistungen zum Aufbauen von Dashboards an und unsere Kunden sind froh darüber.

Genau aus diesen Gründen glaube ich nicht, dass euer E30 vom normalen End-User geeignet ist, komplexe Abläufe in E30-Code zu überführen.
Meine persönliche Erfahrung bei der Softwareentwicklung ist pauschal so:
20% eines Programmes sind Funktionscode, also Beschreibung dessen, was zu tun ist.
78% des Programmes sind dann Userfehler-Verhinderungscode. Also die berühmten Plausibilitätsprüfungen, die den gewünschten Ablauf dann sicherstellen.
Die restlichen 2% sind i.d.R. Nice-To-Have-Funktionen, die nach Kostenabschätzung meist die ersten 98% um ein mehrfaches übersteigen können.

Jeder Kunde, den ich bisher unterstützt habe, war diesbezüglich mit meinen Leistungen sehr bis äußerst zufrieden. So wie ich einen Sachbearbeiter in seiner Tätigkeit eher selten ablösen kann, sowenig ist es umgekehrt möglich, dass dieser Sachbearbeiter vernünftige Programme erstellen wird.
Wenn er privat Programme generiert, wie und womit auch immer, und damit Erfolg hätte, wäre er kein Sachbearbeiter geworden.

Ich habe schon viel gesehen, was da so mit Excel an Formeln, Verweisen, z.T. VBA-code zusammengezimmert wurde und dann irgendwann durch ein richtiges Programm abgelöst werden sollte, weil der Zimmerer dieser Dokumente abgängig geworden ist.
Dasselbe gilt auch für MS-Access, wenn es als Nicht-Entwickler verwendet wurde.

Deine Karrikaturen sind ganz nett, aber leider sehr E30-lastig;-).

Ich will damit nicht sagen, dass E30 schlecht ist, sondern dass ich auch für E30 ein gewisses Maß an IT-Erfahrungen mitbringen muss.

Historisch gesehen (1991/1992) habe ich mich mal mit Synon auf der AS/400 beschäftigen müssen.
Die war/ist auch ein sog. 4GL-Tool.
Nachdem die ersten 5-10 Progrämmchen fertig waren, war ich erstaunt, dass diese als Programmobjekt jeweils 500KB überstiegen, für ein einfaches Bildschirmpflegeprogramm. Nach der ersten Hochrechnung über die Anzahl der geplanten Programme und die Größe der generierten Datenbank musste ich leider feststellen, dass die geplante Hardware hier nicht ausreichen wird. Wir hätten ca. 5 Mio.DM zusätzlich für die Plattenaufrüstung investieren müssen.
Synon habe ich dann rausgeschmissen und wir haben dann native COBOL auf der AS/400 entwickelt.
Die Programme/Module waren dann zwischen 50-200 KB groß und die geplante Hardware (damals 72 Systeme AS/400 F2 mit 988MB Festplatte, den Hauptspeicher weiß ich nicht mehr, sowie Rel V2R1).

Lieber Baldur, Du hast ja so recht mit Deinen 3-4GL Argumenten die sich im Wesentlichen mit meinen Erfahrungen decken. In unserer 5GL-Umgebung gibt es all diese Nachteile großteils nicht. Wir bieten IT Gesamtprojekte die natürlich entsprechende Dienstleistungen und Support beinhalten. Die E30-lastigen Karikaturen waren Teil unseres kostenlosen Werbekalenders. Ich schätze nach wie vor Dein Urteilsvermögen deswegen wäre es nicht ungeschickt sich E30 einmal anzusehen....!!!