[Serie] Enterprise 2.0: Parte 4- Siempre “Casi Listo”

 Continuando  con esta saga que inicié meses atrás sobre la Web reescribible y cómo las organizaciones pueden sacar tajada de ella, en esta entrega te voy a contar cómo son los ciclos de desarrollo de software dentro de este paradigma tecnológico. Lo que vamos a ver te va a sorprender no tanto por la perspectiva de quienes desarrollan el software para la Web 2.0/Enterprise 2.0 sino por la de quienes lo consumen

Empecemos por revisar un caso real: una traductora me comentaba el otro día que uno de los softwares más usados entre sus colegas, está por dejar de ser una aplicación que se distribuye en CD y se instala. A partir de ahora los traductores van a empezar a pagar un derecho de uso (similar a la licencia que pagaban cuando compraban el CD) pero no van a tener que instalar nada. En cambio, van a poder entrar a un portal web y someter el documento a traducir (normalmente un .doc, un .pdf, un XML, etc) en forma completamente on line. El beneficio de este cambio se puede medir en al menos tres aspectos

  • Más espacio en disco disponible, ya que no hubo que instalar nada localmente
  • No hace falta contar con un equipo pulenta en recursos (RAM, CPU, etc) ya que la traducción ahora se hace al otro lado de la nube
  • Como un navegador web estándar es lo único que hace falta tener para ejecutar la aplicación, la aplicación no nos condiciona a un determinado sistema operativo

Esta profesional me comentaba que las aplicaciones de traducción suelen trabajar con lo que se llama "memoria de traducción", que sirven para evitar traducciones literales de localismos como puede ser en Argentina "estar en el horno" (expresión usada para significar que se está en problemas), o en Chile "al tiro" (por "inmediatamente"). Estas expresiones, traducidas literalmente entre idiomas, no producen cosas con demasiado sentido por lo que los traductores deben elegir una expresión más adecuada. Bueno, las memorias de traducción ayudan a poner esto en práctica porque pasan a ser "diccionarios" de expresiones poco convencionales que van a ser de gran ayuda para evitar la intervención manual del traductor humano

Acá viene lo interesante de esta historia: en la versión desktopstand alone de la aplicación, la memoria de traducción la iba llenando uno a medida que iba encontrando traducciones literales incorrectas, por lo que cada nuevo usuario tenían su memoria vacía. Por ende el arranque era lento (y ni que contarte si ya habías logrado una memoria lo suficientemente madura y robusta y una vuelta se te corrompe el archivo donde se persiste: no, no creo que los traductores acostumbren a tomar backup frecuente -no lo hacemos nosotros que se supone que somos los que recomendamos hacer siempre eso, no vamos a esperar que lo hagan ellos-)
Bueno, con la versión web que se viene la memoria de traducción va a pasar a ser algo compartido -una clara aplicación del reaprovechamiento de la inteligencia colectiva que te comentaba en la parte 1 de esta serie smile_teeth-. En consecuencia, la versión web de la aplicación va a ser mejor cuanto más usada sea

Señoras y Señores… Cambió todo

Andá a competirle a un servicio tan liviano y a la vez tan incrementalmente poderoso. De vuelta el efecto red: cada nuevo traductor que usa este servicio, a la par que se beneficia él porque no van a tener que pagar el costo de crear su memoria, beneficia al resto porque retroalimenta la memoria de traducción compartida
Patadón al tablero, no? Te imaginás el quilombo que podrías hacer vos también si a tu aplicación la pensás para beneficiarse del efecto red?
Esto de ofrecer aplicaciones que no se instalan pero que están siempre ahí, en la nube de Internet se apoya en un par de técnicas:

  • Software as a Service (SaaS o software como un servicio)
  • Desarrollo Ágil (Agile Development)

Software as a Service (SaaS). Es el mecanismo de distribución del software que te conté que usaban estos traductores del ejemplo más arriba: no se instala nada. Todo está hosteado en el proveedor (quizás, en un host que el proveedor a su vez paga por)
Lo cómodo para el usuario consumidor de software como un servicio es que él o ella no sufre impacto (no debería, bah) ante cada upgrade de versión que el proveedor realice. La última versión está siempre "instalada" para él

El word y el excel de Google, al que recientemente le añadió su powerpoint es un clarísimo ejemplo de SaaS, por el que más de uno supuso "esto va a hacer puré a Microsoft". Las realidades están a la vista (y conste que no dije "a la Windows Vista" smile_tongue). Hasta el momento el negocio central (core business) de Microsoft giraba en torno del sistema operativo Windows (desplegado en el 90% de los escritorios y aunque no tengo el número exacto, también es el más desplegado en servidores). Eso más el Office, la suite de productividad y colaboración. Pero si con SaaS y su modelo browser-enabled el sistema operativo deja de ser relevante (todavía es temprano para decir que eso es real: los navegadores no son full compatibles entre sí, pero es de creer que van camino a serlo –máxime porque el mercado va cerrando filas en torno a dos de ellos: el Internet Explorer y el Mozilla Firefox que entre ambos se engullen el 95% de la pizza-), la posibilidad de correr las aplicaciones principales de la suite Office en formato SaaS podrían obligar a Microsoft a cambiar copernicanamente su modelo de negocio (mirate esta nota de lo que podría ser un posible naufragio)

 

 
Market share de los navegadores, todavía claramente liderado por el Internet Explorer
aunque el crecimiento del Mozilla Firefox es lento pero persistente

La industria informática está viviendo en estos días un momento de disrupción similar al que se vivió cuando IBM inventó la PC. Estoy haciendo ficción con esto que voy a decir pero al empleado de IBM que inventó la PC, si aún sigue laburando ahí, le deben dar todos los meses el galardón al "empleado pelotXXX del mes": su inventó, capitalizado en manos de empresas más ágiles como la joven Microsoft de aquellos tiempos (te hablo de más de treinta años atras), sumió a IBM en una crisis tan profunda que recién se iba a recuperar en la segunda mitad de los 90 cuando, inteligentísimamente, asumió la realidad y se reconvirtió en una empresa que provée ya no tanto hardware y software sino sobre todo servicios de consultoría tecnológica (y consultoría de negocios en general a través de la adquisición de Price Waterhouse o las alianzas estratégicas con Accenture y DMR, entre otras)

Microsoft estos últimos años se ha venido adecuando a las nuevas demandas tecnológicas para no ceder liderazgo -para no perder más liderazgo smile_tongue-, reconvirtiendose en una empresa multi negocios (al incursionar en el segmento hogareño de entretenimientos con su XBOX, su Windows Media Center, su iPod Zune, etc; en el terreno de los servicios para empresas con su división Microsoft Consulting Services -MCS-

También lo está haciendo en el terreno de Web 2.0, como te voy a contar más adelante

En lo q SaaS respecta, a mediados del año 2006 lanzamos (hablo en primera persona del plural porque fui parte del equipo que trabajó en eso) un portal de guías para arquitectos de aplicaciones distribuidas como un servicio. Los que van capitaneando la vanguardia son Gianpaolo Carraro, Eugenio Pace y Frederick Chong, quienes han ido lanzando una serie de artículos abordando las problemáticas -ahora las voy a comentar- de este tipo de aplicaciones y las distintas formas de encararlas. Pero también han liberado en Febrero pasa el LitwareHR, una aplicación SaaS de referencia que pone las guías en práctica (orgullosamente para nosotros sudacas, el LitwareHR se logró gracias al esfuerzo conjunto con una empresa sudamericana)

No obstante, desarrollar aplicaciones SaaS no es para cualquiera. Las problemáticas de SaaS son duales: para el lado consumidor de SaaS tendremos que preocuparnos de algunas, y respecto del lado servidor de SaaS tendremos que ocuparnos de otras totalmente diferentes. Por ejemplo, si el consumidor de una aplicación SaaS estaba abocado a montar su Arquitectura Orientada a Servicios (Service-Oriented Architecture o SOA) y ya había invertido unas buenas lucrecias en eso… qué rol le cabe a la aplicación SaaS en medio de esa orquesta? Cómo se maneja el login, de manera que el usuario no tenga que logonearse en varias aplicaciones? Qué pasa con sus datos que el consumidor ingresó, y que quedan hosteados en el proveedor, si discontinúa el servicio? (por ejemplo, en el caso del traductor en línea, toda la contribución que un usuario hizo a la memoria compartida… la pierde!? Uff, si es así estábamos mejor cuando estábamos mal y teníamos que instalar el software stand alone)

Pero para el proveedor de la aplicación SaaS la cosa no viene más fácil: cómo lograr una aplicación que sea configurable en forma múltiple por varios inquilinos (tenants), conservando la forma en que cada uno deseó hacerlo? Hablemos un cachito de Escalabilidad (Scalability): qué hacemos, metemos a todos los tenants en el mismo servidor o mejor ponemos un servidor para cada uno para que no se peléen? La modalidad "uno para cada uno" es cara y desaprovecha recursos, pero es más fácil de lograr. Lo que pasa es que si un servidor se cae, ese tenant fue. En cambio si la arquitectura de la aplicación SaaS prevé una granja de servidores, se cae un servidor y el resto de la granja se hace cargo de levantar al muerto hasta que el servidor esté up and running de nuevo (los principios detrás de esto son anteriores a SaaS y tienen que ver con tolerancia a fallosfault tolerance-, degradación suavegraceful degradation– y failover -la capacidad de reconocer que el servidor que venía ejecutando una tarea no está disponible y por ende reasignarle el resto del trabajo a otros-; esto último se puede hacer en forma proactiva mediante los llamados balanceadores de cargaload balancers-, que se paran en la entrada de la granja (farm) para recibir todos los requerimientos y se lo pasan al servidor que esté menos ocupado)
Y respecto de los datos? Estamos seguros que los tenants no van a querer adaptar ninguno-ninguno-ninguno? Por ejemplo, qué pasa si un tenant nos dice "quiero lanzar una promo para aquellos clientes míos que tengan más de cuatro hijos, no tienen celular en la casa y ganan entre tanto y tanto". Cómo sabemos de ante mano, según el tenant, qué datos habrá que modelar?
Gianpaolo, Eugenio y Fred se están ocupando de investigar todo esto y en el portal de SaaS que te comentaba están dejando sus conclusiones


Los cuatro niveles de maduración de SaaS
(Fuente: http://msdn2.microsoft.com/en-us/architecture/aa479069.aspx)

Desarrollo Ágil (Agile Development). Te comentaba recién de la ventaja de SaaS, del punto de vista del consumidor, de no tener que instalar el software en su propia infraestructura. Para el proveedor de SaaS esto también es un beneficio, porque se libera así de tener que estar distribuyendo diversas versiones a sus distintos clientes y comprarse así, para mañana, la obligación de dar soporte a versiones dispares. Porque creéme que no es tan fácil obligar al cliente a migrar siempre a la última versión: hay quienes migran a lo pavote pero son los menos; la mayoría es más conservadora porque no quiere ser la rata del laboratorio. Por ende, es cuestión de tiempo, vas a tener clientes en versiones distintas -casi tantas como las que fuiste liberando- y vas a estar condenado a dar soporte a todas. Los clientes se van a migrar luego de negociaciones muy duras y lo peor es que, si bien vos preparás tu aplicación para migrar fácil de la versión n a la n+1, tus clientes van a estar en la versión m<n. Creéme que migrar de m a n+1 ya no será tan sencillo y quizás tengas que intervenir manualmente convirtiendo datos y archivos de configuración
Entonces con SaaS, este lazo desatado del compromiso entre proveedor y consumidor ha ido adoptando una modalidad de liberación de versiones de software más dinámica, frecuente


A lo largo del tiempo, liberación de versiones del sistema operativo Microsoft
Windows
, comparado con la liberación de versiones de la aplicación
Flickr
(Fuente: http://www.oreilly.com/radar/web2report.csp)

Ante todo debo decir que el Desarrollo Ágil no es una consecuencia de Enterprise 2.0. Esta forma de desarrollar software privilegiando la frecuente integración de los componentes que los desarrolladores iban terminando en una forma iterativa e incremental, usando al usuario como un miembro fundamental del equipo de desarrollo (un aliado, por así decir, alguien que no sólo provée dirección sino que se compromete a probar, frecuentemente, las versiones que se van liberado al mismo ritmo) ha estado dando vueltas de un largo tiempo antes de empezar siquiera a hablar de Web 2.0

Uno de los beneficios sustanciales del Desarrollo Ágil es que, si algo debe cambiar (sea porque el usuario se dio cuenta mejor de lo que quería una vez que vio algo más o menos andando, sea porque el negocio demanda un golpe de timón y a poner foco en otra cosa) el feedback permanente del usuario lo va a poner en conocimiento de los desarrolladores en forma inmediata. Justamente en la piedra basal que los gurúes del Desarrollo Ágil, pusieron al firmar el Manifiesto Ágil incluyeron como principio "los cambios de requerimientos son bienvenidos, incluso con el desarrollo bastante avanzado" (aunque, la verdad? Le quisiera ver la cara a Kent Beck, a Ward Cunnigham y a Ken Schwaber -tres ilustres firmantes del Manifiesto– si veinte días antes del final del proyecto el usuario les dice "estuve pensando… todos estos últimos tiempos… y la verdad que llegué a la conclusión de que lo que necesitamos es otra cosa… me gustaría tirar todo y empezar de nuevo" smile_tongue)

Como sea, hace unos meses estrenamos en el portal de Arquitectura MSDN, una sección para Desarrollo Ágil, con el padrinazgo de Peter Provost (gurú del Desarrollo Ágil en Patterns and Practices) donde vas a conocer un poco más del asunto. Porque Desarrollo Ágil no es una metodología en sí sino una filosofía de trabajo. Pero después hacés doble click y te aparecen varias metodologías concretas (entre las que descollan especialmente eXtreme Programming -XP- y SCRUM) que ponen en práctica -cada una a su modo, ojo- los principios del Desarrollo Ágil

Así y todo, no es un lecho de rosas. Sólo por mencionar una de las contras del Desarrollo Ágil a tener en cuenta es que, aunque el usuario al principio va a estar muy pilas y colaborador, al cabo de un tiempo se va a ir agotando porque él no puede descuidar su día a día -y, después de todo, tu aplicación distribuida en forma paulatina no le resuelve TODOS sus problemas; ese switching de contexto cansa y se va a notar). Es muy probable que, llegado el momento, el usuario te diga "loco, yo no pertenezco al equipo de Desarrollo" (en otras palabras, lo que te estaría diciendo es "metete tu filosofía ágil sabés dónde, no?)

Otro de los inconvenientes -no digo que sea una contra del Desarrollo Ágil– sino tan sólo una circunstancia que lo afecta, es que implica un cambio cultural en las políticas de la organización de dimensiones copernicanas. A los gerentes que toman decisiones de negocio le gustan las cosas claras, no te van a bancar que les digas "yo te voy a ir tirando muestritas gratis, esto de a poco va a ir saliendo, con el correr del tiempo lo vamos a ir terminando". Es factible que te paren en seco y te digan "vos me traés una carta GANTT donde vea todo el timeline del proyecto, cuándo sale el módulo de Pagos, cuándo empezamos a probar el de Morosos, cuando se termina la carga incial de datos, etc, y entonces yo te libero la guita para el proyecto. Si no, haceme el favor, tomatelá de acá que ya bastantes problemas tengo". No es imposible hacerle cambiar la forma de pensar a este tipo de gerentes, pero si lo lográs, mejor que todo después te salga bien porque si inicialmente no se ven esos resultados parciales que se prometían… En fin, suerte macho smile_embaressed

Seguramente la cosa pase por aplicar un proceso ágil sin que los de la gerencia lo perciban smile_tongue. Para soltar este tópico te invito a recorrer el laboratorio de Patterns and Practices de la mano de sus anfitriones, Peter Provost y Eduardo Jezierski

 

El Imperio Contraataca. Microsoft no es ajeno a toda esta movida que sin duda alguna le obligó a replantear el modelo de negocio que venía liderando y que ahora corre el riesgo de perder (ocurra o no, es claro que ya nada es como fue). Microsoft viene impulsando desde años, frente a la dicotomía Desktop o Web Browser, una tercera alternativa conocida como Smart Client (por "Cliente Inteligente"). El Smart Client es una aplicación de escritorio más liviana que las stand alone, ya que no contiene toda la lógica de negocio sino que consume servicios disponibles en la nube (Internet). Preferentemente se basa en el framework .NET, y para eso toda la energía del gigante de Redmond -en lo que respecta a herramientas de desarrollo y guías de arquitectura- ha cerrado filas detrás de esa estrategia

Visual Studio es el entorno que permite agilizar el desarrollo de éste y otros tipos de aplicaciones (años luz por adelante de tratar de hacerlo con el Notepad, ni se te ocurra). Las guías las aporta el comité de Patterns and Practices, que desde hace años vienen escribiendo unos libros de arquitectura desde distintas perspectivas (seguridad, acceso a datos, distribución de la lógica en capas, etc). Ultimamente están proveyendo unos aceleradores del desarrollo conocidos como Software Factories, que son unas extensiones a Visual Studio que, si desarrollar software fuera cortar árboles, es como pasar de un hacha a una motosierra (perdón por la comparación poco feliz en tiempos en que deberíamos todos reflexionar por los desastres venidos y por venir como consecuencia del ataque a la naturaleza que por acción u omisión hemos venido llevando a cabo)
Entonces decía, la propuesta de Microsoft es "Software más Servicios" (Software + Services) para el consumidor (no uno o el otro). Hay un artículo muy interesante de Michael Platt, uno de los arquitectos top del equipo de Arquitectura de Microsoft, que comenta al respecto las oportunidades que se abren

Hay algo innegable en mantener una parte local de la aplicación (en la expresión "Software + Services" sería el Software, en tanto que Services hace referencia a lo que está disponible más allá de la nube) que es el aprovechamiento de los recursos locales (memoria, discos, pero sobre todo la CPU) que siempre han tendido a abaratarse y por ende no hay un gran dilema con eso de "es mejor no instalar nada y ejecutar todo remoto"

Por ejemplo, si la aplicación de traducción se instala localmente y se nutre de una memoria compartida (a la que, a la vez, contribuye a alimentar) distintas modalidades comerciales pueden estar disponibles. Por mencionar una, si se corta el contrato entre el traductor y la empresa que ofrece el servicio, al menos el aporte del traductor a la memoria queda almacenado localmente, de modo que pueda importarse a otra aplicación de traducción similar que el traductor contrate en un futuro

Yo personalmente no compro mucho eso de que es por necesidad de abaratar el costo de las compus (mediante poca memoria, CPU barata, disco con poca capacidad) porque en la práctica el abaratamiento del hardware siempre llegó solo en cada ciclo en que por el mismo dinero se podía ahora comprar una PC con -a veces- cuatro veces más capacidad de disco que lo que se podía comprar por esa plata el año anterior, el doble de memoria, dos CPUs en lugar de una, tarjeta wireless incorporada, aceleradora gráfica incorporada, etc. Quiero decir, el baseline de los equipos es cada vez más sofisticado por precios similares, entonces de dónde la necesidad de hostear todo afuera (si hasta incluso las supercomputadoras -conocidas como Clusters, Computadores de Alto Rendimiento o HPC, High Performance Computing– hace 15 años atrás eran tan caras que sólo los gobiernos y las empresas de más alto revenue los podían tener; hoy en cambio estos equipos son más potentes que nunca y los más básicos están al alcance de una PyME)

Admito que hay otras motivaciones para ir todo a Servicios que me estoy pasando por alto: la libertad de dejar todos los datos de uno en la web hace que nos podamos desplazar de un equipo a otro y que todo siga estando ahí. Qué modelo se va a imponer en el futuro dependerá de cómo cada uno de estos factores conmovió al consumidor
Otra motivación para darle masa a los Servicios, como decía Gianpaolo en uno de sus artículos sobre SaaS, es tercerizar la administración del host en alguien que entiende y que se va a hacer cargo mejor que uno

Microsoft puso en práctica "Software + Services" mediante Windows Live, un conjunto de aplicaciones individuales que pueden o no tener lado cliente. Definitivamente Microsoft no ataca a estas tendencias sino que claramente las acompaña (el asunto es si las podrá liderar con la claridad con que lideró la evolución de la industria hasta el momento)

 
Software + Services en acción:
Windows Live es un conjunto de utilidades de diversa índole,
disponibles para usuarios de Windows. Tenemos chat (instant messaging o mensajería
instantánea, como se lo llama hoy), correo electrónico, antivirus, blog con editor, etc
Todo instalando una mínima parte en forma local. El resto queda del otro lado de la nube
Por ejemplo, el blog de
Windows Live Spaces tiene un lado cliente en su Windows Live Writer


Así se veía el Windows Live Hotmail viejo, hasta que -sin que vos tengas que instalar
nada- Microsoft lo renovó por esta versión que ves abajo


En un primer estadío se permitía a los usuarios volver a la versión previa (sobre todo si
sus navegadores no aceptaban AJAX como tecnología -lo que degradaba notoriamente la
experiencia de usuario enriquecida por la nueva versión-)

 

Okay, suficiente por hoy. En la próxima entrega vamos a ver cómo la Enterprise 2.0 revolucionó la forma de exponer y vender productos a escala global. Hasta entonces!

Esta serie se compone de

Esta entrada fue publicada en Software Management. Guarda el enlace permanente.

Una respuesta a [Serie] Enterprise 2.0: Parte 4- Siempre “Casi Listo”

  1. Diego dijo:

    Quiero agregar una referencia interesante a los intentos de Microsoft por dar batalla en el terreno Web 2.0: hacer click acá 

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