Aplicaciones como componentes.

Estas en la oficina y recibes una llamada de uno de los Project manager (en perro: "gerentes de proyecto") para que asistas a una junta en donde se esta planeando el siguiente proyecto de la empresa, Al parecer el guey que define los proyectos se levanto con una revelación divina y antes de que se le olvide convoca a una junta.

Entras a la sala miras a tu alrededor y observas a los asistentes, algunos con cara de "no se que chingados hago aquí" otros con cara de "mta madre otra pinche junta" y alguno que otro con cara de "me la pelan putos" pero todos tienen algo en común y ese algo es que todos son considerados como los top lead tech (los chingones técnicos).

Te sientas y escuchas al gerente hablar acerca de la visión de la aplicación, jóvenes vamos a crear la ultra mega plus ultra de las aplicaciones financieras, trabaje el fin de semana en una aplicación de este tipo y me di cuenta de que para hacer toda la chamba necesito no solo una sino 4 pinches aplicaciones. Que les parece si hacemos una aplicación que proporcione TODA la funcionalidad que un usuario final espera, que use una solo app y no 4. Yo les propongo bla bla bla bla bla bla.

Después chutarte media hora de puras mariguanadas escuchas la pregunta del gerente --tons como le hacemos? y antes de que puedas articular palabra los demás empiezan a ladrar a un tiempo como perros cuando pasa el camion de la basura, atropellándose las oraciones, unos empiezan hablar mas fuerte, total se arma de la de dios es padre y como no, son puros geeks tratando de dar soluciones.

Unos hablan de implementar una arquitectura de 3 capas, otros que mejor sea de n capas, unos empiezan a hablar de la tecnología que van a utilizar para implementar la solución, otros con su guerra santa de quien es mas chingón si .NET o J2EE, etc. etc., etc., etc. pero con lo que todos están de acuerdo es que el desarrollo tiene que ser en capas, cuantas? sabrá la chingada pero todo tiene que ser en capas es la moda, y la funcionalidad tiene que ser modularizada pa que el desarrollo sea ágil y se le puedan vender partecitas a los clientes (léase versiones), se tienen que reutilizar componentes como los de UI, comunicaciones ya sea por mail u otro medio, uso de un framework para la capa de negocio, etc, etc,etc.

Te ha pasado? te suena familiar la historia? a mi si me ha pasado innumerables veces, en ocasiones he entrado a las juntas pensando que chingados hago aquí, otras veces pensando puta madre otra pinche junta pero siempre entro con actitud de ME LA PELAN!!!!!! :-) no se crean.

Bueno el punto es, que esta situación tan familiar y que empresa no quiere crear la killer app de la Web, y como suele suceder en este tipo de proyectos se toman las mismas decisiones y se tratan de implementar las mismas practicas que se han aprendido de la experiencia en el ramo, practicas como la reutilización de componentes de UI ya sea para Web o Windows, el uso de un armazón de capa de negocio, incluso la utilización de algún tipo de tecnología de portal, siempre apuntando a una arquitectura moddularisada. Pero alguna vez se han preguntado como le hacemos para reutilizar la funcionalidad de negocio de una aplicación existente?

Yo se que muchos de ustedes se han de estar preguntando que chingados fumo este guey. Pero si lo analizamos detenidamente la idea no esta jalada de los pelos.

Si bien en nuestro día a día es común que tengamos que utilizar un chingo de aplicaciones para desarrollar nuestro trabajo también lo es que empresas de IT ya identificaron esta necesidad y traten de consolidar la funcionalidad en una sola aplicación, el problema es que muchas empresas toman el camino largo, y conste que digo que es el camino largo y no el equivocado porque en el área de IT existen diferentes caminos para lograr un objetivo

Pero cual es este camino? se preguntaran bueno pongamos el ejemplo de una empresa que trata de desarrollar una solución integral para el manejo del departamento de recursos humanos, y bueno como parte de esa integración quiere ofrecer módulos de Administración de empleados, nomina, reclutamiento, desarrollo laboral por nombrar algunos. Bueno una tiiiipica empresa trataría de desarrollar cada uno de los módulos, aventarse la chamba de definir, analizar, desarrollar, probar e implementar por cada uno de los módulos, que si lo analizamos detenidamente en la actualidad esos módulos son aplicaciones existentes y quizás implementadas dentro de la empresa.

pero que tiene de malo esto, bueno nada y todo, porque bueno porque es perfectamente factible que cualquier empresa de IT desarrolle la aplicación que se le inche pero si tomamos el tiempo que se toma desarrollar una aplicación de este tipo nos enfrentaríamos a años de desarrollo ya sea utilizando métodos convencionales o ágiles, y siendo realistas años no es un termino aceptable y menos hoy en día, aunado a esto tenemos el echo que ya existen empresas que proveen este tipo de servicios y que tiene en el área años y volviendo a ser realistas esta cabron competir con estas con nuestra primera versión y recuerden que estamos hablando de un modulo digamos reclutamiento.

Una alternativa que están ofreciendo las empresas de IT par atacar este problema es la integración a trabes de una capa de presentación, y digo a trabes de una capa de presentación porque al usuario se le presenta como una sola solución, un lugar centralizado en donde el puede hacer su trabajo sin tener que usar otra aplicación.

Esto se logra utilizando aplicaciones ya existentes y creando un mecanismo de comunicación entre las mismas, poniendo una capa de UI que por lo regular es una capa Web, claro que no es fácil ya que involucra el desarrollo de una arquitectura completamente nueva y me refiero nueva en el sentido de que es un cambio completo de modo de pensar, otro paradigma ya que estamos acostumbrados a desarrollar nuestras aplicaciones con componentes y no con aplicaciones en si.

Arquitecturas que se pueden aplicar para este tipo de aplicaciones siempre han existido no son nuevas, y para muestra basta un botón alguno de ustedes ha oído hablar de la arquitectura basada en servicios o SOA por sus siglas en ingles? además de que muchas de las aplicaciones para usuario final ya cuentan con algún tipo librerías para poderlas extender ya sea a través de un API de funciones o de Web Services.

Una arquitectura similar a SOA se aplacaría para la integración de este tipo de soluciones claro con cierto sazón ya que tendríamos que definir el modelo de comunicación entre las aplicaciones, idear una manera de implementar el SSO o Sigle Sign On (en perro:- nomas ingresa tus credenciales una vez y se chingo), se tendría que definir que aplicación es dueña de los datos a nivel campo, o la manera en como los procesos offline de una aplicación afectarían a el resto. Haaa aun recuerdo los días en los que integrar aplicaciones era nomás escribir y/o leer un archivo plano para otra aplicación, que tiempos aquellos.

Pero que tipo de tecnologías necesitamos tomar en cuenta para esto? bueno les dejo una lista pero como todo en IT esto es relativo tecnologías como .NET, J2EE, Delphi, XML, Web cervices, XSLT, SQL, Work Flows, etc. nada del otro mundo.

Esta manera de desarrollar soluciones esta tomando mucha fuerza y conviene estar preparado por si tu jefecito amanece un día con dolor de guevos y quiere crear la aplicación perfecta que lo va a sacar de pobre.