Lily Sullös, astróloga húngara radicada en la Argentina, en momentos en que se le pre- guntó qué dicen los astros sobre el futuro de Java y .NET

 Tuve  recientemente acceso a un informe realizado por una empresa independiente respecto del futuro de las plataformas de desarrollo empresarial. En el mismo se dedicaron a investigar el escenario empresarial y cuál iba a ser la tendencia de las principales plataformas habilitadoras de SOA (por lejos Java Enterprise Edition y Microsoft .NET, el resto del stack como Ruby o PHP no son jugadores fuertes por el momento) de acá al año 2012. Repasemos algunas de sus interesantísimas conclusiones:
 

• Si bien .NET 2.0 está fuertemente afianzado, .NET 3.0 no va a ganar masa crítica de desarrolladores antes del año 2010. En el mismo punto, en cambio, el informe estima que va a ser difícil que esa situación no haya cambiado para el año 2012. En ese momento, estima, .NET 3.0 va a gozar de una legión de desarrolladores (*)
   
• C# y Visual Basic.NET van a seguir liderando las preferencias de lenguajes dentro de la plataforma .NET, llegando entre los dos a un 85% en el año 2010. Sin embargo el informe anticipa que para el año 2012, C# habrá superado a VB.NET en proyectos grandes, a escala empresarial. VB.NET seguirá siendo fuerte en proyectos de menor escala
   
• Mono, la versión multi sistema operativo de la plataforma .NET, seguirá adelante no obstante -esto siempre el vaticinio del analista- no tendrá apoyo directo de Microsoft, lo que seguirá limitando su uso en empresas
   
• En lo que hace a herramientas de desarrollo Java, si bien Eclipse y NetBeans seguirán gozando de buena reputación y uso, en el ámbito empresarial no van a ser jugadores fuertes por su falta de soporte out-of-box al ciclo de vida completo de los proyectos. En el ámbito empresarial, jugadores como IBM y Compuware seguirán mandando
   
• Las futuras versiones de Java EE seguirán la senda de simplificación inaugurada en la versión 5 (que permite reemplazar descriptores de despliegue -deployment descriptors- por anotaciones en el código -similar a las subclases de System.Attribute en .NET- o servicios Web; mayor sencillez para crear los componentes empresariales -Enterprise JavaBeans o EJB- o configurar el acceso a recursos mediante inyección de dependencias, entre otros adelantos). No obstante, siempre según este informe, .NET seguirá siendo visto como "el sencillo" y Java EE "el vueltero"
   
• En el peor caso, hacia el año 2009 estará lista y certificada la versión open source del Java Development Kit (JDK) y la Java Virtual Machine (JVM) como por ejemplo el bien encaminado proyecto Apache Harmony
   
• Habrá mayor recompilación de aplicaciones para plataforma de 64 bits (que quizás no ofrezcan una gran ventaja en rendimiento, respecto de 32 bits -la ventaja se aprecia más en aquellas aplicaciones de cómputo intensivo-, pero permiten direccionar espacios de memoria mucho más amplios (2 a la 64 contra 2 a la 32; en otras palabras, 16 terabytes contra 4 gigas). Actualmente lo que se hace es ejecutar en 64 bits las aplicaciones que se habían compilado para 32 bits. Se estima que más adelante se compilarán versiones para ambas arquitecturas, aprovechando que tanto .NET como Java EE abstraen estos detalles con sus máquinas virtuales. Los que sí se las van a ver negras para migrar son los desarrolladores C/C++
   
• En tanto que a .NET se lo percibe, siempre en el ámbito empresarial, más inseguro, menos escalable, con poco apoyo de la comunidad open source, a Java se lo asocia con desarrollo robusto pero complejo y lento. También, se lo relaciona con aplicaciones de escritorio que no aprovechan a fondo las ventajas de la plataforma. Justamente lo que no se le percibe a uno es lo que sí se le percibe al otro y viceversa. No obstante para el futuro se vislumbra que Microsoft seguirá ganando terreno en proyectos de misión crítica de clase empresarial, en tanto que Java seguirá simplificando su proceso para ganar mayor agilidad
   
• Testimonio de lo anterior lo da cierta estadística que muestra que en pequeñas organizaciones la penetración de .NET goza de un soberbio piso de 70% contra un techo de 5% para Java. Pero esa película cambia completamente en las organizaciones más grandes, donde la penetración de Java alcanza el 50% en tanto que la de .NET apenas un 25%. La predicción es que a pesar de los esfuerzos de ambos bandos por parecerse más "al otro", esta tendencia se va a mantener en los próximos 5 años
   
• Los que eligen Java, en general pretenden consistencia a lo largo de varias plataformas, fuerte adherencia a principios técnicos como Orientación a Objetos (OO). Históricamente estas aplicaciones estaban centralizadas en personal de TI altamente entrenado
   
• En el otro wing, los que prefirieron .NET querían explotar al máximo la sinergia de una plataforma monovendor pero altamente integrada, están influenciados por procesos de desarrollo rápidos y sencillos, eventualmente realizables por desarrolladores ajenos a la organización
   
• En definitiva, Microsoft resigna flexibilidad tecnológica (el poder elegir la plataforma) a cambio de un uso más productivo de la misma, mientras que Java cede espacio al aprovechamiento de las singularidades de una plataforma para poder cubrir un espectro más amplio de ellas
   
• Ya como conclusión acerca de Java en la empresa, se prevé que en tanto que por una parte las versiones abiertas de la plataforma seguirán avanzando, una polarización en extensiones propietarias (esto es, no "run anywhere" o "ejecutables en cualquier lado") que aprovechen mejor características particulares emergerá. El lenguaje se seguirá simplificando aunque seguirá quedando atrás de .NET en ese aspecto. Finalmente, soporte para lenguajes dinámicos o de scripting alternativos se estima que será una realidad. Si bien oficialmente hoy no hay ninguno, Groovy es una extensión open source que con un estilo similar a Python o Ruby produce Java bytecodes
   
• Por su lado, .NET seguirá ganandose una respetable reputación en ámbitos empresariales, y el uso de Visual Studio Team System (particularmente el servidor de proyectos Team Foundation Server) avanzará hasta cubrir casi todo el campo de desarrollo empresarial .NET (entiendase: ese vaticinio lo que dice es que "si en una empresa desarrollan con .NET, será muy probable que usen Team Foundation Server"). Como noticia no tan feliz, si bien .NET 3.0 será un gran contribuyente al respaldo empresarial hacia la plataforma de Microsoft, su adopción real será lenta y atada a la adopción de Windows Vista. En otras palabras, la posibilidad de poder correr WCF, WPF y el resto de .NET 3.0 en Windows XP o Windows Server 2003 no implicará uso efectivo

 
___________________________
(*) .NET 3.0 es una versión de la plataforma de desarrollo de Microsoft que incorpora, respecto de la versión anterior, APIs específicas para interoperabilidad (Windows Communication Foundation, o WCF), experiencia de usuario (Windows Presentation Foundation, o WPF), actividades orquestadas (Windows Workflow Foundation, o WF) e identidades (Windows CardSpace)

• Diego Dagum: quién suscribe. Arquitecto jefe de contenidos del portal de arquitectura MSDN Architecture Center. Moderador del Foro de Arquitectura General MSDN
• Atanu Banerjee: arquitecto estudiando formas de aplicación del stack de tecnologías de Microsoft, particularmente en industrias manufactureras (alimenticias, automotrices, etc). Atanu liberó hace unos meses una aplicación de referencia que concreta varios casos de uso relacionados con administración de cadenas de aprovisionamiento (supply chain management) con una implementación basada en Office Business Applications (OBAs, de las que recientemente publicó un libro). Actualmente Atanu está estudiando el espacio de aplicaciones compuestas (composite applications)
• Frederick Chong: arquitecto actualmente analizando formas de resolver las problemáticas principales de las aplicaciones provistas como servicios (Sofware as a Service o SaaS). Fred, al otro día de este video, liberó una aplicación de referencia para estudiar posibles formas de implementar aplicaciones SaaS
• Michael Platt: arquitecto actualmente analizando tecnologías, plataformas y maneras innovadoras de alcanzar la cola larga (the long tail) mediante la aplicación del mix Software + Servicios (por ejemplo, enlazando sistemas internos de las organizaciones con lo que nos provée Web 2.0). Es muy fácil entender qué es esta "web reescribible, web de la participación" desde el punto de vista del consumidor de servicios como los que ofrecen Google, Virtual Earth, Flickr, el flamante SoapBox, etc, pero... desde el punto de vista de las organizaciones, dónde está el revenue? Mike publicó hace poco un artículo clarificador al respecto
• Simon Guest: arquitecto director de contenidos del AST y editor en jefe del Journal de Arquitectura

Bueno, habiendonos presentado todos, vamos a la transcripción de los comentarios:

• Diego Dagum: yo empecé a decir que era arquitecto antes de serlo realmente, ya que no tenía la experiencia aún. En consecuencia llegué a serlo cometiendo errores -claro, por inexperto, por arrogante, por ignorante, ...- pero así me dí cuenta qué fue lo que falló para hacerme cargo y arreglarlo
• Atanu Banerjee: hacen falta dos cosas principalmente: interesarse en un entorno amplio de tecnologías y a la vez desarrollar perfiles comunicacionales. Algunas de las personas a las que hay que llevarles un mensaje tecnológico son desarrolladores, otros son ejecutivos y en el medio tenés todo un rango de perfiles
• Frederick Chong: arquitectura es parte ciencia y parte arte. Así que tenés que ser lógico cuando un enfoque científico sea el adecuado, y tenés que ser creativo cuando lo que se necesite sea arte
• Michael Platt: no es cuestión de que te las sepas todas, eso es imposible. Tenés que saber sólo aquellas áreas que te hacen ir directo al fondo del asunto, pero no necesitás saber más allá de ahí. Para cada situación necesitás entender dónde está el problema y conocer a partir de allí cuál es técnico necesario (nota mía: desarrollador, DBA, operador, etc) para resolver ese problema. Tu rol va a ser clave para comunicarte con los demás. Necesitás conocer de administración de aplicaciones e instrumentación, y a la vez saber con qué productos cuenta la industria, pero no conocerte detalles de los mismos para ponerlos en práctica. Es interesante esto porque, alcanzar ese nivel de conocimiento equilibrado, es lo que a la mayoría le resulta más dificultoso
• Simon Guest: lo que vas a necesitar seguramente es experiencia, y al respecto te digo que la mayoría de los arquitectos somos diferentes, es decir que los perfiles de arquitecto que desarrollamos son distintos. Ahora, lo que sí creo que todos los colegas tenemos en común son "años de experiencia". Y eso nos permite desarrollar un panorama completo
• Mike Platt: pensamiento lógico y un par de cosas más: buenas capacidades comunicacionales y una buena comprensión de las características de la organización, también. Se necesita conocer cómo la organización trabaja, cómo su gente hace el trabajo, y además entender cómo la tecnología encaja en ese cuadro, porque en realidad de eso se trata: personas y tecnología. De esa manera tu rol consiste en poner a la tecnología como parte de un sistema más grande, siempre que apoye a estas personas
• Diegum: ser un arquitecto implica cometer algunos errores al principio pero entenderlo y asumirlo luego, no? Así que vos podés cometer errores toda tu vida, pero ése no es en todo caso el problema: el problema es cuando nunca aprendés a parar de cometer el mismo error una y otra vez
• Mike Platt: lo que la mayoría de la gente encuentra más complicado, y probablemente lo sea, es domar la abstracción. Porque hacer un conjunto de modelos abstractos quizás es lo fácil, pero comunicarselos a través de un pizarrón a una serie de tipos y que todos entiendan de ahí que es lo importante, qué lo crítico, etc. Es difícil pero a la vez esa es la parte central de la actividad que hacemos
• Fred Chong: se trata de construir aplicaciones de misión crítica. Escribir código es una manera posible de seguir las tendencias, conocer los verdaderos puntos de interés, tratar de imaginarse qué problemas podrían venir para estar preparados cuando de veras llegue el momento. Yo creo que el rol del arquitecto tiene mucho que ver con eso: con resolver problemas
• Diegum: para llegar a ser arquitecto realmente hay que invertir tiempo en leer mucho acerca de los distintos puntos de vista, las distintas formas de resolver un mismo problema ya que, el típico error que cometemos como arquitectos es el pecado de la arrogancia en el sentido de que... "ah no... Mi solución en realidad es LA solución así que no necesito aprender nada más". De manera que la mejor práctica para no caer en eso es tratar todo el tiempo de discutir contra uno mismo, jugar al abogado del diablo, probar de encontrar nuevas formas de resolver un mismo problema, incluso cuando considerés que con lo que ya tenés la batalla está terminada. Por supuesto, eso te implicará invertir cierto tiempo, y seguramente será difícil encontrar ese tiempo. También la mano pasa por participar en foros de discusión (nota mía: el Foro de Arquitectura General MSDN es un claro ejemplo). Y, definitivamente, la regla de oro en todo esto es tener la real experiencia de todo, no contentarse con solamente hablar sobre arquitectura y nada más. Vos necesitás tener la experiencia y probar en la práctica de que tus ideas, tus pensamientos realmente tienen sentido
• Mike Platt: también hay que aprender escuchar, por supuesto. Todo viene y va en diferentes direcciones. Hay que saber escuchar a diferentes personas que vienen de diferentes lugares. Algunos son analistas de negocios, otros profesionales de TI, por lo tanto tienen diferente background. Pero vos tenés que entender todo el tiempo de dónde viene cada uno de ellos y no hay una respuesta correctamente entendible para todos ellos al mismo tiempo porque tienen diferentes puntos de vista, intereses e incluso estilos. Y vos también tendrás que entender cuando alguien más te esté hablando a vos, y ser capaz de alinearte a su visión. Ser hábil en entender todos los puntos de vista y habilitar una solución que sea capaz de contemplar los intereses de todas las partes
• Diegum: vos no podés abandonar. Vos no debés abandonar. Vos tenés que continuar la carrera y tenés que lidiar con la frustración de modo de no abandonar nunca. De esa forma yo tengo fé que un día vas a llegar. Yo tengo un montón de casos, no sólo el mío propio, de un montón de amigos míos a quienes conocí cuando ellos apenas si eran desarrolladores juniors y puedo decir al respecto que ellos hoy en día son arquitectos probos. Puedo decir que ellos pueden aplicar para la certificación porque ellos hoy tienen los antecedentes, el conocimiento, en definitiva, los deberes hechos para poder aplicar a eso