En las entradas previas estuve contando un poco como suelen ser las cosas a la hora de montar un sistema informático. Está redactado en clave de humor pero si alguien ha estado metido en dicha vorágine, sabe que las cosas se parecen más a la realidad de lo que le podría parecer a un profano.
Los sistemas son en realidad más complejos de lo que piensa la gente o más simples de lo que piensan algunos. Para un buen ingeniero informático el sistema tendrá su trabajo y su complejidad pero está controlado. Para un profano lo que empieza como algo simple como un vídeo para cambiar un grifo de Bricomanía se puede acabar complicando más que la Sagrada Familia. Al final, zapatero a tus zapatos y deja al profesional hacer su trabajo que es lo mejor y en la informática no hay excepciones a esta regla.
Otro ejemplo es cierta comunidad que sacó hace años un sistema por unos 7 millones de € ¿es caro? Pues habida cuenta que primero había que descontar el IVA y que luego incluía el precio de las licencias de cierta sistema cuyo importe ascendía 3,6 millones resultó que no era precisamente un chollo. Y la empresa que se lo llevó no acabó en plazo ni de coña, pero eso es otra historia.
Al final, depende de lo que haga, el tiempo, lo que incluya, .... Un sistema de 10 millones de € puede ser barato y otro de 50.000 € puede ser caro. A priori y sin conecer el asunto, no se puede decir. Además, no hay que olvidar que lo que sale en prensa no tiene por qué corresponderse con la realidad. No cuesta lo mismo por ejemplo, montar y explotar una aplicación relativamente simple con una BD en una sitio que no haya nada (lo pagas todo) que aprovechar una infraestructura existente.
2.- ¿Es un sistema una Web y poco más?
Ni de coña. Las web es sólo la capa de presentación de la aplicación. Es cierto que una mala web te puede arruinar la aplicación y merece su trabajo, pero por detrás hay un potente trabajo de análisis, un diseño de la aplicación, una fase de pruebas y una explotación. El uso de metodologías
ágiles no evita que como algo nazca torcido sea muy jodido enderezarlo (como todo, cuanto antes detectes el fallo, antes lo arreglas) El problema es cuando el cliente no tiene muy claro lo que quiere o presiona para que las cosas se hagan a toda prisa (el famoso "Si funciona no lo toques") Aquí sale un
ejemplo de ello en clave de humor. Claro que cuando has sufrido algo similar ya te hace menos gracia.
3.- Si funciona, no lo toques.
Esta es la mayor falacia en el mundo de la informática. Funcionar funciona pero ¿funciona bien? No es lo mismo funcionar (hacer algo) que funcionar bien (y rápido, claro) Si una aplicación interactiva tarda cinco minutos en resolver una consulta a la BD la cosa no funciona bien aunque la respuesta sea excelente. Recuerdo haber tenido un compañero que era un fiera del
SQL pero no dominaba tanto las bases de datos con lo que le gustaba más el
JOIN que a un tonto una tiza. La consecuencia es que la BD tiraba a hacer FULL SCAN por menos de nada. Alguien podrá decir "pues mete un índice" y la idea de no es mala ... salvo cuando los administradores de la BD no te dejan (pasa y mucho)
A priori, un sistema, hasta que no ha pasado un tiempo en producción y es estable, va rápido, no pierde iformación, ... no se le puede considerar que funciona (y aún así) De hecho, a los errores y/o problemas que se encuentra un sistema en sus inicios se les conoce como errores de infancia.
4.- Esto falla y no he hecho nada. Ayer iba bien ¿qué ha pasado?
 |
Yo no toco nada ... además, las fotos de gaticos
atraen visitas al blog. |
No has tocado nada ... ¡LOS COJONES! no has hecho nada cachoperrohijodemilpadres ¿a quién quieres engañar? Las cosas no pasan por que sí. Siempre hay una relación causa efecto y las cosas no se estropean de un día para otro porque sí. O bien degeneran poco a poco (véase el ejemplo del punto anterior) o si no fallan desde el primer día, no fallan de golpe. Algo han hecho. Volviendo al modo abuelo Cebolleta, recuerdo un caso es que un sistema se nos empezó a caer de un día para otro. El número de usuarios no había cambiado. La última actualización había sido hacía tres meses al menos ... y el cliente no había hecho nada ¡Y UNA MIERDA! El muy perro había desplegado otro sistema que atacaba nuestra BD cada dos minutos con una consulta sin índice. Eso sí, la culpa había sido nuestra, no suya ni de los otros que ni siquiera lo habían probado. Por suerte, se hizo un índice y asunto resuelto tras un rapapolvo por no ser proactivos, no cuidar al cliente ..... (exacto. Como puta por rastrojo)
5.- Un sistema ¿funciona solo, sin nadie que le moleste?
Pues que suerte has tenido ya que desde que comencé a trabajar con entornos en red la mayor pesadilla se encuentra en una cosa llamada interfaces. Incluso cuando trabajábamos con sistemas stand-alone ya tenían interfaces muy simples, a base de ficheros y demás para por ejemplo llevar las facturas del sistema de gestión al de contabilidad.
 |
| ¿Qué estarás tramando, cacho perro? |
Los sistemas han nacido de su padre y de su madre con la tecnología de moda en cada momento y con los presupuestos de cada empresa/departamento. Entonces ¿qué le espera al informático del S.XIX? Pues un batiburrillo de interfaces entre los diversos sistemas de cuidado, eso cuando no se mete un sistema a hacer lo que no debe en la BD del otro o te encuentras que cuatro departamentos, porque ellos lo valen, hacen cuatro aplicaciones similares, cada una personalizada para ellos. Al final, las cuatro van una BD central, sacan una serie de datos de la tabla y se los presentan como les interesa ¿consecuencia? La empresa paga a cuatro equipos de desarrolladores, cuatro instancias de BD (de la buena, de la caras, no de esas baratitas) y explota cuatro sistemas (eso si, creo que al menos compartían algunas máquinas) ¿te piensas que es coña? Pues te aseguro que no.
6. No hay nadie imprescindible. Todo el mundo puede ser sustituido.
Eso es una gran verdad. Lo que no se cuenta es el dolor que lleva detrás esa sustitución. Lo que suele haber es un economista que no tiene ni idea de otra que de números. Esa persona es muy cara ... pon otra más barata. Y te cepillas al que llevaba dos años y se conocía el sistema de pe a pá y te resolvía los problemas en dos horas. El/los sustitutos salen más baratos por jornada pero resulta que lo que el anterior hacía en dos días a estos les lleva dos semanas (y a veces más) y no te digo cuando se hace el off-shroring a la India. Esos ingenieros que cambian de empresa cada seis meses ... lo ideal para la estabilidad de un proyecto.
Vamos, si hay que sustituir a alguien, se le sustituye, pero sustituir por vicio, es tontería.
7. Se ha caído ¿cómo es que no hay un sistema de respaldo, una copia, un plan B?
Pues por una sencilla razón: eso es caro. Las empresas serias suelen tener sus sistemas duplicados o al menos con copias. La cosa no es simple ni barata (el precio anterior en HW y licencias, pues multiplicado por dos) precisamente con lo que me temo que hay muchas empresas y aplicaciones que están ligeramente (por decirlo de manera eufemística) en precario. Y aunque el HW suele ser bastante decentito a veces se cae y luego vienen los lloros. Cierto es que no nos podemos blindar ante todas las circunstancias, pero si se puede hacer una protección bastante razonable, aunque como he dicho, eso es caro pero no veas la tranquilidad que da cuando sientes que tu CPD está seguro.
 |
| Responsable de IT cuando confía en el sistema de respaldo. |
Eso sí, los sistemas de la empresa funcionando en precario, pero luego el economista presume de la pasta que ha ahorrado en esos derrochadores de IT.
8. Pero si cruzar una base de datos con otra es solo apretar un botón.
No sé quien fue el genio que dijo esto, pero cruzar BD de ayuntamientos (por poner un ejemplo) con las de Hacienda para detectar el fraude puede ser una de las cosas más complicadas que existan (con gran alivio de Bárcenas, Fabra, Ignacio González y otros) Supongo que la cosa habrá mejorado algo, pero claro, cada ayuntamiento (en este caso) ha elegido una tecnología según le han dado entender en cada caso, con un esquema de BD, con una serie de datos, con una serie de relaciones entre los datos que han sido las que necesitaban en cada caso. Ahora alguien puede pensar ¿y no había nadie para poner orden? Pues no y olvídalo, aunque lo hubiera habido, hubiera seguido siendo un caos. El Ayuntamiento de Madrid ya estaba informatizado cuando al Ayuntamiento de Bustelfollado ni siquiera había llegado el teléfono. Por aquella época las posibilidades de haber caído con IBM eran muy altas, ahora vamos a SW libre, BD relacionales cuando no a otras cosas más avanzadas. Casi hay que hacer los interfaces entre ellos uno a uno. Se pueden intentar definir una serie de interfaces estándar, pero en ocasiones, hay información de éstos que no hay de dónde sacarla.
9. Si esto es un decálogo ¿cómo es que no hay 10 puntos?
Bueno, nunca dije que fuera un decálogo. A cambio te pongo esta foto (trucada por si alguien no se ha dado cuenta) que le tiré a la última luna llena.
 |
| Pues si, el otro día estuve viendo Los Pitufos. |
10. Vale, esto es un desastre ¿se puede mejorar?
Pues por supuesto que se puede mejorar, como casi todas las cosas. No es demasiado complicado .... o sí. Todos los costes que hemos visto en el Ayuntamiento de Busltelfollado son bastante elevados y muy complicados de reducir ... para un sólo ayuntamiento. Si en lugar de utilizar el sistema en exclusiva para un solo sitio lo hacemos para dos, los costes bajan no a la mitad, pero bastante cerca, depende de la complejidad que tenga el otro Ayuntamiento pero gran parte de las cosas que hacen los ayuntamientos son las mismas, con lo que mucho se puede reutilizar. El HW por lo general está ocioso, con lo que con el mismo HW se puede dar servicio a más de un ayuntamiento (quizás si son pequeños hasta tres o cuatro) con lo que el coste de las carísimas licencias se diluye entre varios eso sin contar que no es lo mismo llegar a VMware y comprarle media docena de licencias que pedirle cien al comercial (se te puede hacer pis encima de la emoción)
Pero claro, una vez que los ratones han visto la solución a los problemas surge la otra pregunta ¿quien le pone el cascabel al gato? O lo que es lo mismo ¿quien va a coordinar a diversos ayuntamientos para que compartan infraestructura? Y esto no pasa sólo en las AAPP, pasa también en las grandes empresas, cuando más grandes, más atomizadas y con mayores reinos de taifas.
 |
| Alguna foto de ordenadores tenía que poner ¿no? |
No hay comentarios:
Publicar un comentario