... ist ja eine Palette von Themen, ich versuche mal ein paar Dinge anzureißen:

@Sourcen im IFS: attraktiv ist die einfache GIT (subversion) Anbindung, die einem eine saubere Versionierung liefert. Das geht aber auch mit verfügbaren Erweiterungen für RDI.

Ein komplettes Paket, wie Andreas das hier skizziert, macht Sinn, wenn die verfügbare Truppe auf mehreren Hochzeiten tanzt. Dann ist Vereinheitlichung von Werkzeugen sicherlich sinnvoll. Was es dann wird, hängt von den skills der Truppe ab und ist auch Geshcmacksache (sagte der Affe und biss in die Seife).
Ein Umstieg für eine reine RPG Truppe macht m.E. keinne Sinn, solange es keine richtige Entwicklungsumgebung gibt (RDI ist das auch nicht, da fehlen die wichtigsten Features : all das, was bei Eclipse für Java unter Source und Refactor kommt). Solange da nichts ist, nehme ich (Geschmacksache!) immer noch SEU, wenn ich mir das aussuchen darf.

@SRVPGMs: Serviceprogramme auf eine exportierte Procedure zu beschränken, ist ein ernsthafter Kunstfehler, dann sollte man stattdessen PGMs nehmen, das spart einem (fast) alle diskutierten Probleme.
Der wesentlliche Unterschied zwischen PGM und SRVPGM ist, dass SRVPGMs mehrere Entrypoints haben, die auf denselben Daten operieren. Das vereinfacht die Schnittstellen (jeder kriegt nur die, die er braucht) und es werden keine Steuerungsparameter übergeben.
Die Größe von SRVPGMs (sprich: wieviel Module binde ich zu einem SRVPGM ist in erster Linie eine Frage des Deployments. Für eine Software mit einer einzigen produktiven Installation favorisiere ich: ein Modul ein SRVPGM, für eine Vielzahl von Installationen sind größere Einheiten oft einfacher.

@Parameter Schnittstellen: Selbige ändert man nicht, sobald man eine Funktionalität in Production hat. Dann gibt es eine neue Funktion (die ja die alte durchaus benutzen kann), mit der geänderten Schnittstelle. Die kann man dann da einbauen, wo die Erweiterung benötigt wird.

@Dateien: hier ist es besonders einfach bei SQL: Alle Programme greifen immen auf Views zu (niemals auf die Table). Standard ist hier select * from XyzView und XyzView as select (Feldliste von Datei). Kommt ein Feld in der Date hinzu, gibt es dann eine weitere View. Jetzt kann man auch die EDS (die immer auf Views verweisen) überall verwenden - ohne dass sich da irgendwas ändert. Mit dieser elementaren Vorgehensweise kann man sogar Felder in eine andere Datei verschieben, ohne dass vorhandene Programme das merken. (Komplizierter wird es bei Erweiterungen von Keys, aber das hat man nicht so oft).

D*B