Atenci�!! AQUESTA �S LA VERSI� CORRECTA DEL CORREU, AVANS HA
SORTIT SENSE QUE L'ACAB�S (coses de l'evolution).
> Objeccions? De detall, algunes. Per exemple, que GIMP no �s comparable a
> Photoshop a poc que t'hi fiquis en un ambient professional; altra cosa
[...]
> complexitat d'una base de dades per no saber sortir-s'hi amb un full de
> c�lcul ben utilitzat. �s clar que molta gent tampoc sap utilitzar b� un
> full de c�lcul...
Una q�esti�, que potser al document no queda ben clara �s que
en molts dels casos que s'analitza un dels productes, l'an�lisi
est� orientat a la UdL, �s a dir, quan es parla de CAD es parla
del CAD que utilitzem aqu�, no del CAD que pugui emprar un
arquitecte "de veritat", per� la part de CAD, imatge,
s�, m�sica, etc. no son per la part "Administraci�" de la UdL
sin� que son m�s per la part "Docent/Recerca".
Respecte a les BBDD. La veritat �s que les solucions son les que
hi ha. La idea que tenim �s, aprofitant l'avinentesa de la
migraci�, ELIMINAR aquelles BBDD que puguem.
M'explico:
Hi ha tot un seguit de BBDD petites (MS-Access majoritariament)
que viuen a la UdL. Aquestes BBDD s'han creat en moltes unitats
administratives nostres per sortir del pas en alguna necessitat
que pogu�ssin tenir puntualment. Despr�s de solucionar la
necessitat puntual, la BBDD en q�esti� s'ha "institucionalitzat"
i ha esdevingut una BBDD de treball diari. Doncs b�, aquestes
BBDD tenen alguns problemes, siguin o no basades en PL, siguin
o no MS-Access, operin sobre Linux o sobre Windowz o sobre el
que sigui:
1- Seguretat: NO hi ha control sobre l'operaci� de la BBDD. Ni
qui hi accedeix, etc.
2- Seguretat: Algunes d'aquestes BBDD no entren a c�pia de
seguretat, resideixen nom�s a un PC, etc.
3- LOPD: Algunes d'aquestes BBDD contenen dades de car�cter
personal i no estan registrades a l'APD (Ag. Protecci� de
Dades), b�sicament, pq el servei d'inform�tica (ASIC a la
UdL, pels que vulgueu llegir la guia de migraci�) no sap
ni que existeixen.
4- Altres: Manteniment, desenvolupaments que s'hi puguin fer,
integraci� amb altres BBDD, integraci� al campus virtual i
a la intranet, etc.
Doncs b�, donat que no hi ha una alternativa a Access v�lida
a Linux, i donats els problemes esmentats, l'opci� m�s v�lida
i coherent �s, posats a fer canvis, canviem la BBDD Access per
alguna BBDD Integrada (integrada al Backoffice, etc.), controlada
per ASIC, registrada a l'APD, etc.
Evidentment, migrar un Access d'alguna unitat estructural nostra
a una BBDD Integrada, no �s trivial, fer-ho amb 20 BBDD o m�s
�s un veritable merder. Per� fer-ho �s important, per diversos
motius i fer-ho b� encara ho �s molt m�s. El m�s interessant
�s que en fer-ho, establirem i farem una "guia"/kit/etc. de com
fer-ho.
Per cert, aix� de tenir Access "sueltos" per la xarxa no �s
exclusiu de la UdL, totes les administracions, si tenen una
mica de "m� lliure", n'acaben tenint...... per desgr�cia
dels inform�tics :-(
> Objeccions importants? Una: no veig un estudi acurat de les implicacions
> de la migraci� en els fluxos de treball i de rendiment i aix� �s molt
> important. Per� aix�, que �s important a la UdL, �s capital a
> l'Administraci� p�blica (para la orella, Oriol, si est�s llegint aix�)
> perqu�, en termes administratius, "rendiment" volt dir "servei al
> ciutad�". I aqu� est� una de les meves impugnacions al fet de qu�
> s'utilitzi una universitat com a camp de proves de l'Administraci�
> p�blica; i m'estranya que s'hagi fet aix�, perqu� aquesta mateixa
> observaci� li vaig fer a l'Oriol Ferran en un dinar que vam fer fa tres
> mesos amb un company d'Hispalinux i un d'altre de Softcatal�, i va estar
> d'acord amb ella. Aquell dia jo vaig suggerir que millor -molt millor-
> que una universitat seria una unitat administrativa que, per les seves
> caracter�stiques, tingu�s una mica de totes: atenci� i serveis directes
> al ciutad�, assessorament o estudis per a altres �rgans i/o suport
> administratiu a tasques t�cniques; d'aquesta manera es podrien veure els
> possibles 'forats' �mbit per �mbit i, aix�, establir POL�TIQUES.
> Exemple de pol�tica: si el forat sorgeix en els serveis de caire intern,
> la migraci� tira endavant perqu� els 'clients' interns tenen m�s
> capacitat de patiment i de compensaci� de danys que els ciutadans, que
> s�n m�s perentoris en l'exig�ncia de les prestacions que acrediten. Si
> �s a l'inrev�s, la migraci� s'atura fins que no es tapi el forat de
> d�ficit de servei a l'exterior. O b� la pol�tica contr�ria (ehem!) all�
> cadasc�.
Uf! Llarg i complexe el par�graf.... anem per parts (atenci�
aqu� hi ha opinions personals meves...).
La UdL �s una universitat, cert (nom�s faltaria), i l'Oriol
va estar d'acord amb t�, cert.
La UdL tamb� �s una administraci� p�blica, tenim una part de
la nostra estructura que �s una administraci�, normal i
corrent. Per� l'acord que estem adoptant amb DURSI (el
Departament d'Universitats, Recerca i Societat de la
Informaci�), no �s NOM�S per que la UdL faci la migraci�,
l'acord contempla (contemplar�):
1- La migraci� dels escriptoris de la pr�pia UdL. D'aquesta
migraci� n'han de resultar diversos productes addicionals:
a. Una guia de migraci� d'escriptoris, amb tots els
problemes detectats durant la migraci�, amb totes
les solucions trobades. Amb consells, receptes, etc.
de com fer determinades coses.
b. Tots els "by-products" resultants, ja siguin
pegats a programes, traduccions, etc.
c. Documentaci� i material de formaci�, encara que
el Jes�s Corrius amb el material de la UOC ja ha
fet una magn�fica feina.
2- El suport des de la UdL de la migraci� d'un parell d'unitats
de la Generalitat (la STSI i un altra) i d'un parell d'entitats
locals (ajunt., etc.).
3- Alguns altres projectes (ajudar a crear una forja, etc.)
"menors" de creaci� d'infraestructura per migraci�, etc.
(suposo que em deixo altres coses...)
Resumint, la migraci� de la UdL va comen�ar ja fa temps, molt
de temps. Tenim coses molt avan�ades (infraestructura, etc.)
i coses no tant (escriptoris). La idea de la col.laboraci�
amb STSI/DURSI �s, pura i simplement, aprofitar tot el que
nosaltres fem (o tant com puguem aprofitar) i emprar
aquesta experi�ncia i els resultats que en treuguem per que
ajudin a les migracions de la resta d'administraci�.
Evidentment que la migraci� de les unitats de l'administraci�
(especialment aquelles que tinguin atenci� al ciutad�) seran
dures. Evidentment que la migraci� de les unitats de l'administraci�
de caire t�cnic (amb menor relaci� amb el ciutad� per�
amb necessitats de programari molt m�s complexes) seran
dures......
Malgrat tot, la UdL no �s l'�nica iniciativa que est�
tirant endavant l'Oriol (fins on jo s�),
> Tant de bo l'experi�ncia sigui ben profitosa per a la Universitat de
> Lleida i val esperar en el seu moment una bona mem�ria sobre aquesta
> migraci�. Per� jo continu� dient que una universitat (la clientela de la
> qual, per m�s que diversa, �s sempre en sentit end�gen, ben al contrari
> que a moltes unitats administratives) no �s el banc de proves adient per
> a l'Administraci�.
? La veritat, no veig pq no pot ser un bon banc de proves
de moltes, moltes coses, especialment tenint en compte que
la migraci� la fem dels escriptoris (dels Windows) i que
els escriptoris i el que hi ha darrera (LDAP, SMB, etc.)
son igualets a la Generalitat, que a la Uni, que a
Tallers Manelet.... :-)
Tota la part relativa a fluxos de treball, etc. no �s
migraci� d'escriptori, sin� migraci� de backoffice, que
ja son figues d'un altre paner... les migracions de
cadascuna de les peces d'un backoffice (sigui el de
la UdL, sigui el del DURSI, sigui el que sigui), s�n
altament delicades i complexes. Evidenment que a la
UdL la farem, evidenment que la nostra experi�ncia
estar� a disposici� de tothom, per� desenganyem-nos,
CADA backoffice �s diferent, i cada aplicatiu de
backoffice s'haur� d'estudiar detalladament, de
forma individual i fer-ne, si procedeix, la migraci�
amb molta, molta cura.
I res de disculpar-se per donar la brasa... per aix�
existeixen les llistes de discussi�, per discutir! :-)
--
__________________________________________________________
Universitat de Lleida
Area de Sistemes d'Informacio i Comunicacions
Carles Mateu i Pi�ol Tel: +34 973 702049
Director FAX: +34 973 702130
www: http://www.udl.es/usuaris/carlesm/
GnuPG key: CD989EA1 ( http://www.keyserver.net/ )
Fingerprint = B1B7 65F7 38E4 C34E 5865 135F DEA6 CF2A CD98 9EA1
_________________________________________________________
signature.asc
Description: This is a digitally signed message part
