Voy a empezar una serie de artículos que tienen que ver con las Arquitecturas, estando más cerca de los conceptos de metodología de desarrollo, arquitecturas empresariales y lineas de productos software, que cerca de la tecnología de implementación de las mismas. Evidentemente al hablar de desarrollo de arquitecturas todo el mundo vuelve la cabeza para mirar Java y .net principalmente.
Hace unos días me comentaba un amigo que se encontraba trabajando en la nueva versión de la arquitectura y que iban a pasar a la versión 4.2, en ese momento le pregunté ¿y porque no la 5?, a lo que me respondió con una serie de argumentos técnicos (todos muy acertados), que justificaban claramente el porque solo un crecimiento en el digito de menos peso.
Muy probablemente en su empresa siguen criterios cercanos a los de Apache http://apr.apache.org/versioning.html , que desde luego me parece un gran acierto y un planteamiento más que respetable.
En resumen lo que dice Apache respecto a su versionado, siendo esto una política muy extendida. Se basa en tres niveles separados por puntos, MAJOR.MINOR.PATCH, aplicando a cada uno criterios diferentes:
* PATCH VERSION: Solo se realizan correcciones, que no cambian el comportamiento de la aplicación, no cambian los parámetros y llamadas. Por tanto al instalar la versión la aplicación no cambia.
* MINOR VERSION: Introduce nuevas funciones, o cambia y modifica el comportamiento de las existentes pero no rompe la compatibilidad con otras Minor Versions.
* MAJOR VERSION: Cualquier tipo de cambio son aplicables a Major Version y no tiene porque guardar compatibilidad con minor versions. Normalmente se aplica cuando se introducen importantes grupos de nuevas funcionalidades.
La verdad es que se trata de un criterio de versionado robusto, pero no olvidemos que normalmente una arquitectura debe ser proporcionada a un usuario de la misma, bien interno (linea de productos sw, departamentos de la compañia, etc) o externo cara a la venta de un proyecto o venta de una arquitectura empresarial o sectorial, a un determinado cliente.
Desde el punto de vista anterior y teniendo en cuenta que un equipo de desarrollo de Arquitectura no lo hace para si mismo, para un agente externo aparenta más solvencia otra manera de presentar versiones. Pensemos que a todos nos da más garantías un producto que se encuentra en la versión 2.2, que uno que está en la versión 1.3... Aunque ambos pueden tener el mismo número de mejoras y correcciones, solo que aplican criterios diferentes.
Si algún lector no me cree, solo tiene que hacer la prueba, muestre dos productos diferentes que tengan funcionalidad similares, apuesten a que en la mayoría de los casos el cliente o usuario se decantara por el de la versión más alta.
¿Por qué? Porque piensa que lleva más tiempo en el mercado, porque piensa que se ha invertido mucho esfuerzo en él, porque si ha llegado a 7 versiones es que será bueno, etc.. La mayoría de estas valoraciones aveces serán acertadas y aveces erróneas.. pero en cualquier caso se basan en un criterio de apariencia.
Por tanto desde este punto de vista, es más fácil vender, justificar presupuesto, etc , aplicando un criterios de versionado ágiles. ¿Es un engaño? No, es Marketing Tecnológico.
Evidentemente no se puede caer en el abuso, y de repente encontrarnos en la versión 23 de un producto. Hay que poner todo en la balanza y aplicar tanto criterios técnicos como marketinianos.
Cara a introducir un nuevo enfoque voy a contar una anécdota empresarial:
Hoy en día, todo el mundo, o gran parte de el, conoce a una empresa como Nokia. Por increíble que parezca Nokia en sus orígenes fabricaba botas de goma para pescadores, y el nombre proviene de un río existente en Finlandia el Nokia.
Sin embargo el mayor acierto de Nokia en su historia, probablemente no ha sido realizar teléfonos móviles, sino ser pionera en el branding, de este modo su marca siempre aparece en todos sus productos, incluso cuando hacía botasSupongo, que ya vais viendo a donde quiero llegar..
Si tenemos en cuanta las 100 marcas más conocidas en el mundo encontraremos muchas tecnológicas y bastantes dedicadas a los Sistemas de Información.. La primera es Google (¿quién la conocia hace 10 años?), y entre las diez primeras Mocrosoft, IBM , Apple y Nokia . Nadie duda que la marca les ayuda a vender..
¿Por qué no aprovecharnos de este concepto y que nuestra arquitectura tenga marca?
Sin duda, nos costará poco y ganaremos mucho. Algo que tiene nombre existe y es importante...
¿Que necesitamos?
Un nombre y un logo. (por supuesto nada que pise otras marcas)
¿Como lo usamos?
Poniéndolo en toda la documentación, presentaciones, etc.
En mi antigua y querida empresa nadie se dio por enterado que teníamos una arquitectura hasta que le pusimos nombre y logo. En ese momento todo cambió, parecía que las horas no se gastaban sino que se invertían, que teníamos un producto que vender, que ahorrábamos costes empleándola, etc.. Pero ella era la misma, con sus defectos y virtudes..
Eso si, bautizada.
