[2104] in SAPr3-news
Re: Kleinstes R/3-System?
daemon@ATHENA.MIT.EDU (Robert Schuhl)
Thu Jan 16 16:57:27 1997
To: sapr3-news@MIT.EDU
Date: 16 Jan 1997 19:11:00 +0200
From: rschuhl@rsl000.rhein-main.de (Robert Schuhl)
roger@larry.westfalen.de meinte am 15.01.97
zum Thema "Re: Kleinstes R/3-System?":
> wir haben schon genug schwierigkeiten, 250 user mit einer ultra sparc
> enterprise 3000 mit 6 prozessoren und 1,5 gb ram auskommen zu lassen.
> was f=FCr einen rechner willst du denn dann f=FCr 2000 nutzer aufstelle=
n?
> selbst eine cray ymp w=FCrde daf=FCr nicht reichen.
Bischen =FCber den SUN-Teller hinaussehen. 250 User auf einer DEC 2100 3 =
=20
Prozessoren, 512 MB RAM sind v=F6llig zufrieden. Ausserdem: MAn kann ja m=
it =20
Applikationsservern erweitern. Und leistungsf=E4hige DB-Maschinen sind sc=
hon =20
vorhanden. Nat=FCrlich ist eine zentrale DB-Maschine immer ein =20
Zuverl=E4ssigkeitsproblem, ist aber heute mit Backup-Systemen in den Grif=
f =20
zu bekommen.
> au=DFerdem kann es ja auch durchaus gute organisatorische und gesetzlic=
he
> gr=FCnde geben, die es einer beh=F6rde gebieten, daten dezentral zu hal=
ten.
> IMHO sollte sich die edv nach der organisation richten und nicht um-
> gekehrt, aber das sehen sap und die von dieser firma verprovisionierten
> berater sowieso anders.
Das mit den gesetzlichen Vorschiften kann sein. Aber ein zentraler =20
Datenbestand hat auch seine Vorteile, wie eine erheblich bessere =20
Infrastuktur des Rechenzentrums, wie entfernte Tape-Roboter, =20
Backupl=F6sungen. Aber das ist sicherlich ein Organisationsproblem, wobei=
=20
ich der Meinung bin, da=DF die EDV zwar Dienstleister ist, aber nicht all=
en =20
org-Quatsch mitmachen sollte. Hier sollte sie evtl. auch mal gefragt =20
werden. Und: Berater sind sicher auch nicht allwissend, und ich hoffe, da=
=DF =20
sie das auch wissen.
> zum beispiel datenschutz: datenhaltende stelle ist die beh=F6rde, in de=
r
> die daten eingegeben werden. wenn jetzt ein rechner f=FCr ein dutzend
> beh=F6rden zentral aufgestellt w=FCrde, wie soll der leiter der beh=F6r=
de
> ruhigen gewissens f=FCr die sicherheit der daten garantieren k=F6nnen?
> und wie sollen hochgradig sch=FCtzenswerte daten mit absoluter sicherhe=
it
> w=E4hrend der =FCbertragung zwischen pc und server vor unbefugtem zugri=
ff
> bewahrt werden? keine firma und auch nicht das bsi konnten da eine
> auch nur ann=E4hernd befriedigende antwort geben.
Das ist aber auch bei einem Abgleich der Daten nicht anders. Irgendwie =20
m=FCssen auch hier Teile =FCber die Leitung. Da=DF es nie eine 100% Siche=
rheit =20
geben wird ist klar. Betrifft aber beide Varianten. Fr=FCher konnte auch =
im =20
=F6ffentlichen Bereich nur zentral gearbeitet werden. Siehe: Kommunale =20
Gebietsrechenzentren. Er kann auch nicht daf=FCr garantieren, wenn sie im=
=20
Keller liegen.
> und wer behauptet denn, da=DF es keine dezentrale administration geben =
k=F6nne?
> 250 nutzer an ebensovielen windoof-pc m=FCssen ohnehin vor ort betreut
> werden und zusammen mit einer zentralen kopfstelle kann das ein gut
> vorbereiteter systemverwalter das durchaus =FCbernehmen.
Sicher kann es das geben, mit den damit verbunden Kosten und Risiken, =20
jeder Systemverwalter mu=DF eine v=F6llig vertrauensw=FCrdige Person sein=
. Das =20
sind erheblich mehr, die lokalen Schaden anrichten k=F6nnen, als bei =20
zentraler Verwaltung, die nat=FCrlich erheblich mehr Verantortung haben. =
Das =20
mu=DF sicher vorher abgew=E4gt werden.
> also: ich bitte um vorsicht mit solchen pauschalen aussagen. das ktw is=
t
> eine definierte leistung des sap-systems und die mit abstand fehlerhaft=
este.
> ich habe noch keinen nicht-trivialen transport mitgemacht, der nicht
> irgendwo daneben gelaufen w=E4re.
Hier kann ich nur zustimmen. Ich hoffe da=DF SAP hier noch einigen =20
Gehirnschmalz reinsteckt. Es funktioniert zwar, aber manchmal dauert der =
=20
Transport l=E4nger als die Entwicklung selbst. Und pauschalieren sollte m=
an =20
sicher nicht. Nur kenne ich auch die Probleme, insbesondere in der =20
Industrie, dann die Daten bei dezentralen Systemen wieder zusammenzuf=FCh=
ren =20
um z.B. eine Bilanz zu erstellen. Wir haben uns dagegen entschieden
Nichts f=FCr Ungut
Robert Schuhl
--
-------------------------------------------------------------------------=
-
Robert Schuhl
E-Mail: R.Schuhl@TheOffice.net
rschuhl@rsl000.rhein-main.de
office Robert.Schuhl@ald-vt.de
Web: Homepage http://www.geocities.com/Heartland/9303/index.html
Hanauinfos http://www.geocities.com/Heartland/9303/indexhu.html
PGP key avaiable on request.
