Algunas preguntas sobre LexNet

El 9 de enero de 2016 escribí en este mismo blog un post titulado «LexNet: siete pecados capitales» que, al parecer, mereció cierta atención en redes sociales y en la prensa especializada. Para mi sorpresa uno de los lectores del artículo fue Don José L. Hernández Carrión (Subdirector General de Nuevas Tecnologías según su perfil en tuíter) quien, desde esa red social me respondió con lo que se ve en la imagen que sigue

IMG_2588

 

Han pasado ya más de dos meses desde que realizó su generosa oferta de transparencia y, salvo error u omisión de mi parte, no ha cumplido su ofrecimiento (créanme que lo entiendo, LexNet debe de estar causándole demasiados quebraderos de cabeza) por lo que, con ánimo de facilitarle la tarea, me gustaría formularle sobre LexNet una primera serie de preguntas sobre las que, espero, pueda arrojar alguna luz pues, como dije entonces y mantengo ahora, LexNet es opaco y la información técnica que hay al respecto no pasa de manuales de información al usuario y algún documento antiguo con visiones muy generales del sistema. Lo que hace o no hace Lexnet más allá de la interfaz de usuario es algo que cae bajo el velo del misterio.

Así pues, si me lo permiten, formularé una primera serie de preguntas que me gustaría ver respondidas en algún momento siquiera sea para que LexNet pase de ser un sistema absolutamente opaco a algo más traslúcido. Conste que las preguntas que hago son para saber e informarme y que sospechar mala intención tras ellas está muy lejos de la intención de este post. Ahí van:

Primera. ¿Porque se siguió apostando por un applet a partir de 2007 cuando estaba claro que el soporte de navegadores iba a ir de capa caída? O, si no, al menos desde 2009 cuando se empezó a ver que la falta de cuidado de Oracle en la resolucion de vulnerabilidades iba a ser un limitante para el lado del cliente.

Segunda. ¿Porque no se migró la aplicación de un applet a una aplicación java nativa con el reducido coste que hubiera supuesto esto desde el punto de vista de desarrollo y después provisionada con Java Web Start para asegurarse de que se ejecutaba con la versión mayor y minor apropiada en cada cliente? La AEAT hizo aplicaciones de escritorio para el programa PADRE y con las apps de formularios de declaraciones y esas aplicaciones JAVA funcionan suficientemente bien. No tiene sentido que sea una aplicación de escritorio para la AEAT y un applet para los ordenadores de los letrados, es un sinsentido.

Tercera. Aunque en último término fuera la SGNTJ la responsable del proyecto, ¿que empresa u organismo público tomó la decisión de continuar por este camino de implementación fallida: IECISA, INDRA, AVALON o SATEC?.

Cuarta. ¿Quién recomendó o aprobó la concesión a AVALON de un nuevo pliego en Noviembre de 2015, previendo el desastre que la obligatoriedad traería en Enero de 2016? ¿Pudiera serque la SGNTJ no pueda delegar el proyecto a otra empresa distinta porque el código implementado por AVALON no es fácilmente descifrable y por ello se perpetúa en el proyecto?

Quinta. ¿Como es posible que para actualizar la versión de la aplicacion se esté interrumpiendo el servicio cada 5-10 dias con una parada de servicio de dos horas? ¿No es posible acaso desplegar los cambios de la aplicacion en el servidor realizado un split-restart de los servidores? ¿Hay un cluster detras del servicio? ¿Qué pruebas de rendimiento y alta disponibilidad han pasado la aplicación y esos servidores? ¿Cómo es posible que el rendimiento sea tan bajo?.

Me quedan muchas más preguntas para tratar de comprender por qué a LexNet le pasa lo que le pasa; ocurre, sin embargo, que, como sospecho que ni siquiera estas serán respondidas, me temo que habré de reservarlas para formularlas en otros foros. E insisto, no vean en ellas mala intención de ningún tipo, tan sólo las humildes ganas de conocer algunos aspectos de un sistema que se nos ha impuesto por ley y del que me gustaría conocer algo más que su nombre.

3 comentarios en “Algunas preguntas sobre LexNet

  1. Ignoro si conoce usted cómo funcionan los proyectos a riesgo. Existe un pliego, se gana el concurso con un precio y unas especificaciones cerradas y el proveedor se ciñe al pliego digan lo que digan las tendencias tecnológicas porque es por lo que le pagan, por cumplir las especificaciones del pliego. Si se quieren mejoras o actualizaciones de las especificaciones hay que pagarlos. Culpar al proveedor de unas especificaciones incorrectas es muy injusto. Viendo las cantidades de dinero que se mueven uno puede pensar que con eso hay margen para hacer los cambios que haga falta pero si realmente esos márgenes existiesen alguien habría presentado una oferta más baja. Cuando se ha cambiado de proveedor la administración debería haber aprovechado para incluir en el nuevo pliego las mejoras que fuesen necesarias. Y esto sirve tanto para el tema del applet como para la alta disponibilidad que usted demanda. Todo eso se especifica para que se pueda estimar, ofertar, ejecutar y cobrar. El proveedor no tiene por qué hacer absolutamente nada más que lo que esté en el pliego.

    Me gusta

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s