Ingeniería informática

Esta semana terminé de impartir uno de los cursos más intensos e intensivos que me tocó impartir en mi dilatada carrera como profesor de informática. Fue un curso, puramente teórico, sobre como desarrollar arquitecturas de aplicaciones empresariales con tecnologías Microsoft.

El jueves de esta misma semana saltó la noticia, http://velneo.es/nuevo-ciclo-de-crecimiento-de-velneo/. Alfonso Gutierrez y Juan Múñoz-Cobos, CEO y arquitecto de Velneo V7 respectivamente, abandonan sus actuales cargos y colaborarán de forma externa.

Sobre esta cuestión me gustaría dar mi enfoque respecto a la importancia del Arquitecto en el mundo del software.

El arquitecto de software

La arquitectura de aplicaciones pretende tender un puente entre los requerimientos del negocio y los requerimientos técnicos. El objetivo de la arquitectura es identificar los requisitos que afectan la estructura de la aplicación. Una buena arquitectura reduce los riesgos de negocio asociados con la construcción de una solución técnica.

Un buen diseño tiene que ser suficientemente flexible como para ser capaz de manejar la deriva natural que se producirá con el paso del tiempo en las vertientes hardware y software, así como en los escenarios de uso y en los requisitos.

Un arquitecto debe tener en cuenta el efecto global de las decisiones de diseño, las inherentes disyuntivas entre atributos de calidad (por ejemplo, rendimiento y seguridad) y los cambios en los requerimientos del negocio, del sistema y del usuario.

La labor de un buen arquitecto de software es sentar los fundamentos, estructuras, prácticas y buenas costumbres, alineadas sobre la base para la cual desarrollas un cierto producto y con el objetivo fundamental de que perdure en el tiempo. Esta es la labor fundamental de un buen arquitecto. Cuando se logra, el arquitecto termina su trabajo. A partir de ese momento,  es hora de que otros asuman las riendas del proyecto.

El arquitecto tendrá que revisar, corregir los errores que los desarrolladores puedan inducir en la arquitectura (si son buenos no generarán problemas y no será necesario) y tendrá que retomar el proyecto si las condiciones fundamentales que condicionaron la planificación de la arquitectura cambian (el software es dinámico, no estático ya que las condiciones cambian en el tiempo). Si esto se tiene claro, no genera ningún problema que el arquitecto abandone el proyecto.

En mi vida profesional, ejercí esta función en diversos proyectos (de tamaño pequeño, mediano y grande) y en todos ellos, llegado el momento, abandoné dejando en buenas manos el trabajo consiguiente. Estos proyectos perduraron en el tiempo, cumpliendo las expectativas del cliente. No fue problema alguno mi abandono.

Para que el producto perdure es necesario solo un par de cuestiones que se tienen que tener claras:

1. La arquitectura tiene que estar completa y no puede haber pilares fundamentales por definir o rematar. Si queda alguno pendiente es necesario que el arquitecto lo remate.
2. Tienen que estar claras las condiciones necesarias para que el software se mantenga en el tiempo (en que cosas tienen que trabajar los programadores, en cuales no, cuales tienen que evolucionar y en que dirección).

Aparentemente, parece fácil llegar a este punto, pero lo cierto es que es una tarea titánica:

1. Hay mucho conocimiento que asimilar, especialmente en la base del conocimiento en el apartado de negocio y en el tecnológico.
2. Hay muchas decisiones que tomar (normalmente complejas, ya que la naturaleza del software es compleja).
3. Hay muchos riesgos que mitigar (con las contra-medidas necesarias).
4. Hay que conseguir fortaleza del grupo de trabajo (personal vinculado al negocio, ingeniería de sistemas e ingeniería de software) para que todos caminen en la misma dirección.
5. Hay que revisar y rehacer mucho código, para dejarlo de la forma más apropiada (sin miedo… “con un par”)
6. …

En este camino, normalmente largo, uno puede fracasar (ya que no siempre encuentras la solución arquitectónica adecuada a la primera). No es mayor problema, se para, se evalúa los motivos del fracaso y se rehace el diseño. Es necesario rehacer la arquitectura tantas veces como sea necesario, si hace falta tirar el código de lo realizado, se tira y punto… «con un par». En aquellas partes en las que no tomes esta decisión, si tu producto perdura, te arrepentirás más adelante (siempre habrá algunas cuestiones que no resolviste a la primera, seguramente te generarán algunos dolores de cabeza posteriormente).

Cuando uno desarrolla proyectos de software algo tiene que tener claro, las personas cambian pero los proyectos perduran si los fundamentos están bien diseñados.

Velneo V7, una nueva etapa

Parece ser que Alfonso Gutierrez y Juan Múñoz-Cobos, CEO y arquitecto de Velneo V7 respectivamente, tomaran nuevos caminos en sus proyectos de vida “profesional”. Estos cambios siempre suscitan dudas respecto el futuro y todos nos preguntamos que será de Velneo V7.

Intentaré aclarar lo que pienso del trabajo pasado y dirección futura respecto a los dos grandes cambios. Espero que esta reflexión no cree distanciamiento alguno con Velneo, trabajadores presentes o futuros:

1. En la parte técnica, el trabajo de Juan es muy bueno, su increíble visión y su acertada implementación de la arquitectura dotan a Velneo V7 de un diseño capaz de asumir los retos futuros a los que Velneo se tendrá que enfrentar. Tal vez quedan flecos, no tanto de arquitectura, más bien de cuestiones inacabadas o no presentadas (posiblemente Juan tenga terminadas muchas de las cuestiones a las que me refiero).
   Pero lo que más me preocupa, respecto al abandono de Juan, no es el tema de la arquitectura de producto, Juan es ante todo un brillante programador, insustituible y altamente productivo. Ningún grupo de trabajo estará a la altura de Juan, por muy buenos que sean los que queden (creo que son pocos), o los que se incorporen en esta nueva etapa.
2. Respecto a la parte de negocio, hay muchas cuestiones que Alfonso deja pendientes, especialmente en el área de movilidad, licenciamiento, nuevos mercados y orientación cloud. Creo que la salida de Alfonso era necesaria ya que su poca visión de las necesidades tecnológicas de las grandes empresas provocaba un estancamiento continuo en el producto. Me temo que esta falta de visión es el motivo por el cual V7 no llega a ser el producto que se espera. Sinceramente, me alegro mucho de su salida, aunque ya se sabe… más vale lo malo conocido, que lo bueno por conocer. Dudo mucho que Alfonso «coloque» a una persona al mando con una visión más ambiciosa que la suya propia, aunque el futuro, como futuro que es, está por ver.

Me siento afortunado de haber elegido Velneo V7 como plataforma de desarrollo para el futuro de una de las líneas de negocio nuestra empresa, la parte técnica es una delicia y el potencial es alto. Pero lo cierto es que a nivel de negocio Velneo no está avanzando en la internacionalización sobre mercados anglosajones, en la apertura y en el área de movilidad.

Velneo V7, carencias actuales

Menciono aquí algunas cuestiones que siguen pendientes en la plataforma V7 y lo hago con partiendo de un análisis que hice en su día al respecto https://tipesoft.com/velneo-presente-y-futuro/:

Velneo GENERAL

• No existe versión de 64 bits.
• ODBC sigue en fase beta (yo no lo llamaría ni alpha, la versión actual está plagada de problemas). Ahora un poquito mejor con los arreglos de la última versión (mejoras significativas en el rendimiento).
• Problemas conocidos sin resolver (http://velneo.es/problemas-conocidos-7-16-0/). Algunos menos, especialmente en la versión Android.
• Algunos bugs sin resolver (revisar vBugman). En las últimas versiones se resolvieron centenares de ellos, ya casi no hay.

Velneo CLOUD

• La API cloud sigue siendo manifiestamente mejorable (No podemos gestionar correctamente las instancias de las aplicaciones). Ahora podemos gestionar algunas cuestiones desde el vServer por medio de la SubAPI de usuarios y grupos.
• No hay ejemplos de integración de la API para PHP (estaría bien poder contar con ellos para WordPress, Joombla y otras plataformas ampliamente utilizadas).

Velneo MOBILE

• No hay aún garantías de ejecución para Android (La versión actual de Velneo es una versión Alpha/Beta). Podemos considerar que la versión v7.16 ya es una beta estable, pero no se puede considerar una versión definitiva ya que hay muchas cosas que aún no funcionan correctamente.
• No hay versión para Android x86 (Espero que pronto trabajen también en esta compilación).
• No hay versión para Linux ARM (La versión actual de Velneo para Linux solo es compatible con x86. El no disponer de versión ARM limita mucho las posibilidades de cara a desplegar v7 en dispositivos ‘low-cost’.). Algo que me preocupa sobremanera viendo como ARM está calado en el mercado, especialmente en el apartado de consumo.
• No hay versión para BB10 (Siendo BB10 una plataforma empresarial y desarrollada con base Qt debiera de estar presente casi de forma obligada).
• No hay versión para iOS (Poco a poco la posibilidad está más cerca. ¿Debiera Velneo estar presente en iOS al igual que en Android?).

Velneo DESKTOPS

• Problemas con los estilos en MacOSX (batalla perdida por el momento).

Velneo RIA

• El vWebClient solo funciona para windows (con algunos problemas). Ya no hay soporte para RIA y esto puede ser un problema a largo plazo ya que algunos grandes apuestan por nuevos enfoques al respecto.
• No existe ningún avance para llevar el vClient a HTML5 (aunque haya proyectos basados en Qt que estén trabajando en esta dirección).

Velneo WEB

• vModApache solo está disponible de forma pública y en fase beta para Windows. Ya tenemos la versión Linux de vModApache pero no hay ningún otro avance.

Velneo vServer

• En MacOSX no hay vServer (limita los despliegues).

Velneo vJavaScript

• Imposibilidad de ejecutar procesos (en 1º, 2º y 3er plano) mediante un manejador desde vJavaScript. Ya está corregido.
• Imposibilidad de ejecutar funciones de Velneo V7 desde vJavaScript.
• No disponibilidad del objeto XMLHttpRequest desde vJavaScript.

Velneo QML

• Falta de acceso a toda la API aportada por vJavaScript.

Otros problemas menores

• Hay algunas pequeñas cuestiones relacionadas con el refresco de formularios, la visibilidad de las variables locales y los eventos/señales.

Otras necesidades

• vClient QML desconectado
• Apertura para otras plataformas (iOS, BB10, Windows Phone y Windows RT)
• Nueva orientación de vWebClient (Arquitectura RIA)
• Exposición de funcionalidad basada en servicios (Arquitecturas SOA/REST)
• Facilidades para el consumo de servicios Web SOA/REST
• Escalabilidad en pantallas HDPI
• Debugger
• Objetos de representación gráfica integrados
• Cuarto plano y demonios en servidor

En definitiva

Según lo dicho anteriormente, puede parecer que Velneo está atascado en algunas cuestiones importantes de cara al futuro, pero si pensase de esta forma no haría justicia a los grandes avances que se hicieron en su día. QML, vJavaScript y las mejoras en el motor de eventos son desde mi punto de vista los grandes avances de V7. También hay otros avances importantes, mejoras de usabilidad, vReports y rejilla avanzada. Hay que reconocer todos estos avances como muy significativos y esperar a que Velneo siga avanzando en algunas de las cuestiones mencionadas.