Ciclos de renovación del software

 Con  Hans discutíamos el otro día acerca del debate planteado frente a la renovación tecnológica. Hablábamos, por ejemplo, de las distintas sensaciones que causan en el público empresas como Microsoft o IBM cuando renuevan sus productos y sus API’s de desarrollo, y luego pretenden que la industria se suba a los cambios o caso contrario sus aplicaciones irán mansamente entrando a la categoría de "legacy".
 
Con .NET el mensaje fue "COM is done". Del mismo modo la Enterprise Library de PAG tiene como filosofía ser, en cada versión, la mejor manera de poner en práctica un concepto (de arquitectura, diseño o desarrollo); y como tal no garantiza compatibilidad hacia atrás. Está en el software "cliente" de Enterprise Library el evolucionar hacia la nueva versión para -en contrapartida- aprovechar los beneficios de la misma, o bien quedar en una versión previa si esos beneficios aportados no compensan el costo de tal evolución. Cuando presenté esto en la conferencia MSDN de Mayo de 2005, me acuerdo que los developers me miraron con inocultable malhumor.
Ni que hablar de Indigo y Avalon frente a WSE, System.Message o WindowsForms.
 
Pero no sólo en el mundo Microsoft se manifiesta esta crisis derivada por evolución de componentes o productos: JavaServer Faces (JSF) implica una mejor modelo, más versátil y adaptado a las necesidades actuales, de desarrollar capa de presentación que el que planteaba JavaServer Pages (JSP) más biblioteca estándar de Tags Java (JSTL), que a su vez surgieron como una forma mejorada de desarrollar capa de presentación que los Java servlets.
Del lado cliente ya había habido un cambio radical cuando Swing reemplazó a AWT aunque en aquel entonces Java era tan nuevo y aún casi no usado en misión crítica. El grueso de los desarrolladores Java se subieron con Swing ya en el podio. Para desgracia de los muchos que se salvaron: SWT y JFace pareciera que vienen a aguar la fiesta, si es que logran convertirse en parte de la especificación como muchos recomiendan que ocurra.
Lo mismo con el nuevo modelo de programación de Enterprise JavaBeans (EJB 3.0 y los que se vienen) frente al 2.1 o el anterior.
 
Logicamente, en todos estos casos también se podría optar por no migrar de tecnología, o migrar parcialmente. Por ejemplo construir hacia adelante con el nuevo modelo y oportunamente migrar lo viejo, pero eso conlleva un costo de doble expertise que simplemente hay que asumir (no despreciar).
Con Hans hacíamos una analogía con los autos. Vos te comprás un coche hoy y capaz que en 6 meses sale uno mejor. Además de que la nueva oferta en el mercado deprecia aún más tu auto que el uso mismo que le estás dando… hay realmente necesidad de cambiarlo?
 
Claramente hay 3 posturas:
-Tener siempre el último modelo
-Aguantar el modelo actual hasta que la misma vida útil "ordene" comprar un nuevo auto o salir en bicicleta
-Esperar el momento adecuado ("adecuado" es cientificamente difícil de definir) para cambiar
Concluíamos que las posturas extremas de las dos primeras opciones son simplemente malas, que la correcta era la tercera. Pero claro, hablando en términos de software, cómo precisar realmente el momento!!??
 
Y se me ocurre que el "momento adecuado" -como todas las cosas, no voy a deslumbrar a nadie- lo debe marcar la necesidad real de la organización. Voy a intentar ser más preciso en el bosquejo de ese "momento adecuado":
-una organización está enmarcada en un determinado negocio (una telco, por caso, pertenece al negocio de las comunicaciones; una fábrica de indumentaria al negocio de la moda, etc). Los negocios evolucionan a una determinada velocidad (no constante en el tiempo, desde luego). Las organizaciones también evolucionan, aunque no necesariamente al ritmo de su negocio. Algunas lo hacen por necesidad de no perder competitividad -esto significa que sus rivales ya han evolucionado antes y pueden estar "comiendole" participación-. Evolucionan, pero a una velocidad menor a la de su negocio.
Otras lo hacen para marcar tendencia: si las demás luego la imitan serán reconocidad por innovadoras ("cutting edge"). Estas evolucionan a mayor velocidad que su negocio.
 
Por otro lado la tecnología evoluciona a su velocidad!
Hay empresas de TI que evolucionan porque necesidades de otros negocios demandan esa evolución (Microsoft evoluciona Visual Basic for Applications -VBA- en Visual Studio Tools for Office -VSTO- porque otros negocios demandan integrar Office al resto del escritorio, así como a web services de una organización o de sus socios, proveedores, etc). Cuando la evolución tecnológica va marcada por necesidades de otros negocios, podría decir que la tecnología evoluciona reactivamente para satisfacer una demanda, por ende, más lento que el resto de la industria.
Empresas de TI que invierten a riesgo en Investigación y Desarrollo (familiarmente I+D), evolucionarían más rápido que el resto de la industria.
 
Quiero volcar ahora este concepto de la velocidad de evolución de un tipo de negocio (comunicaciones, moda), y la velocidad de evolución de la tecnología que ese negocio consume, para tratar de definir cuál debiera ser la velocidad de evolución de una organización (una telco, una fábrica de ropa) que marque cuál es el "momento adecuado" para adoptar nueva tecnología:
Si una determinada evolución tecnológica nos va a permitir seguir, alcanzar la evolución del negocio asociado a nuestra organización, me atrevo a decir que estamos frente al momento adecuado. El beneficio de evolucionar tecnológicamente va, al menos, a compensar el costo de dicha evolución.
Si no es así, la evolución puede ser aconsejable aunque quizás no tan imprescindible. No tan vital.
 
Quiero mostrar como ejemplo una clásica duda: cuándo migrar de COM a .NET o a JEE. Varias empresas ya me han manifestado el interés que les despierta la plataforma .NET en cuanto a disponibilidad en múltiples dispositivos (tablet, devices) e interconexión de sistemas (Office, legacy, JEE, etc) pero encuentran aún a COM lo suficientemente bueno (good enough) como para justificar el costo de la migración, readiness de los desarrolladores, etc.
 
Cuándo es el momento adecuado para migrar? Si el costo de seguir manteniendo las viejas aplicaciones reduce la velocidad de evolución tecnológica, y esto a su vez impacta en la velocidad de evolución de la organización, es hora de pensar en serio en .NET, JEE o la tecnología novel que se plantée como sucesora.
 
Cerrando con la analogía del auto, ponerle A/C o cambiar el pasacassettes por un CD player deriva en beneficios inmediatos en tanto que no aparentan tener costos tales que superen a los de cambiar el vehículo actual. Ya si el negocio (picking-up girls o similar) requiere el "techo que se saca" o un motor más potente es otro cantar.
Esta entrada fue publicada en Software Management. Guarda el enlace permanente.

4 respuestas a Ciclos de renovación del software

  1. Danijel dijo:

    Es interesante ver el articulo “C#: Is the Party Over?” publicado en ultimo JDJ (http://java.sys-con.com/read/117741.htm). Uno de los temas tocados es parecido, pero la conclusión diferente: en articulo Java es ganador por imponer un ritmo de cambios mucho mas medido.

  2. Hans dijo:

    Con respecto a la tecnología de una organización y la razón de cambio del negocio, quiero profundizar en el tema que causa la disociación entre ellos: adaptabilidad.Cuando hablo de adaptabilidad me refiero a la capacidad de un sistema para avenirse a las condiciones variables de un medio. Esta alcanza su mayor expresión cuando una variación no afecta al comportamiento del sistema, en aquel caso, este cambio es referido como ‘compatible’. En la Ingeniería de Software se tiende a pensar como un objetivo último de la disciplina el mantener la compatibilidad a toda costa. Esencialmente, esto es deseable, aunque no suficiente, para responder ante lo que muy bien explicas en tu blog como ‘velocidad de un tipo negocio’.En muchas organizaciones, la manera de implementar esta adaptabilidad es del estilo que Martin Fowler acuña como “codifica y arregla” (code & fix). Este método funciona mientras la naturaleza del cambio este acotada a parte del sistema y sea soportada por el diseño del mismo. En el extremo de esta tendencia, se encuentran casos de sistemas que han sido acondicionados al máximo a través del tiempo con el fin de mantenerse actualizados. En la analogía de los Autos, esto sería lo más similar a los automóviles preparados (tunned cars) usualmente modelos clásicos con características de vanguardia, pero con la mayoría de sus partes originales. Tanto en la analogía de los autos como en el desarrollo de software el drawback es el mismo: los costos de mantención y adaptabilidad aumentan en función del tiempo.Existen ocasiones en el que la solicitud de cambio es tan radical que no es soportado por la adaptabilidad del sistema y es lo que hace a un sistema ser ‘incompatible’ con el negocio, lo cual provoca la molestia en los developers por sentirse ‘obligados a romper la arquitectura’. Lo que sucede en este caso es que hay que poner en la balanza la conveniencia de asumir un cambio a gran escala para mantener la vigencia del antiguo sistema versus evolucionar a un nuevo sistema que provea un grado mayor de adaptabilidad.

  3. Unknown dijo:

    Diego, aunque no tengo el gusto de conocerte, mis felicitaciones por tu blog. Por lejos de los mejores que he leido ultimamente en relacion a tecnologias de programacion en particular MS.Te escribo por que me parecio muy interesante tu articulo en relacion a los ciclos de renovacion de software. En particular la distincion de renovacion de software por tecnologias o por procesos de negocio. Se que este post es bastante antiguo y no he leido los demas anque los revisare cuando tenga mas tiempo.Por mi parte escribi ultimamente en mi blog un post que esta relacionado inderectamente al tema que mencionas aqui, escribo el tema general del desarrollo y futuro del software en relacion a sistemas empresarial especificos (de logica de negocio mas propietaria). Mi Humilde aporte teorico por cierto es en relacion a la evolucion  de herramientas de programacion de sistemas empresariales cercanos a los de tipo ERP.Por cierto ya suscribi tu blog a mi lista.Saludos CordialesJavier Urrutiahttp://MisBytes.wordpress.com

Responder

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. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s