Como cualquier nuevo paradigma tecnológico o de TI, SOA esta teniendo el mismo problema en el que generalmente siempre se empieza a trabajar con él desde la implementación, cometiéndose el error de querer implementar algo que no se tiene claro, de lo cual no se tiene conocimiento. Y es que el público en general cree que SOA es que la aplicación tenga un Web Service o que las aplicaciones expongan Web Services. Esto apoyado con la tarea de los grandes proveedores de software que prometen implementar SOA en todas las aplicaciones son haciendo clic.
Primero que todo, SOA inicia como una estrategia de arquitectura empresarial, esto quiere decir que, como toda estrategia empresarial debe tener el sponsorship de la alta gerencia (Quien es tu papá?), al fin y al cabo a ellos les interesa es el ROI (Soportar al negocio). Además de esto esta basado en servicios que hacen parte de un proceso, ya sea de soporte o de la cadena de valor, pero al fin y al cabo procesos, que deben ser definidos antes que todo para implementar SOA (Tener una visión).
Para poder definir los procesos organizacionales, se debe empezar a pensar en las labores de cada uno de los empleados de la compañía y a su vez para implementar SOA se debe tener un respaldo fuerte de los actores de los procesos, porque es muy probable que varios cargos o actividades se vean afectados por la nueva estrategia organizacional y tal vez puedan presentarse cambios de cargos, actividades o en ultima instancia despidos.
Ahora, SOA no cabe en todas las organizaciones, SOA es exitoso para compañías donde los procesos pueden tener puntos transversales comunes, se tengan long running process, no basta con querer que la nomina “hable” con el aplicativo de proveedores.
Y si esto no es suficiente, todos dicen, “Queremos que la aplicación tenga una arquitectura SOA”, aun sabiendo que las aplicaciones no tienen arquitectura SOA, es la estrategia de TI, las aplicaciones se pueden hacer SOA-Enabled, esto quiere decir, que expongan servicios y que puedan ser integradas (Definir proyectos alcanzables). Esto demanda una muy buena definición del negocio, una excelente definición de casos de uso, y algo a lo que no se esta muy acostumbrado. Una buena correlación entre casos de uso y componentes de negocio. Esto a su vez implica un cambio en los paradigmas de ventas y de gestión de los proyectos actuales. Ya que los componentes deben ser reutilizables, se requiere que se requiere mucho más tiempo en el diseño y en la documentación de las interfaces que en la implementación. Y esto debe ser un común denominador para todos los proyectos de software, porque al fin y al cabo “NO TODO EN LA VIDA ES ECHAR CÓDIGO”. Para esto se requieren INGENIEROS DE SOFTWARE o SISTEMAS y no PROGRAMADORES (Lo cual lastimosamente, parece que se nos está olvidando).
Ahora, hablando de que las aplicaciones deben ser SOA Enabled, quiere decir que exponen servicios (La flexibilidad ante todo), teniendo en cuenta que servicios no son Web Services y que Web Services no es SOA. Un servicio puede ser creado con cualquier tecnología de acceso remoto (http, RMI, COM+, DCOM, CORBA, Sockets) y los Web Services pueden ser creados con SOAP o con REST. Por otra parte, es difícil exponer servicios en un sistema legado COBOL, no es solo hacer clic como lo prometen.
Ya para concluir, desde el punto de vista de la compañía (nuestros clientes) no se puede estar pensando todavía que la implementación de estrategias de TI se empiezan con la compra de software, se debe empezar con la definición clara del panorama tecnológico organizacional y esto implica muchos cambios organizacionales y mucha inversión en reestructuración de la compañía y cambio en la mentalidad de los empleados (Perder el miedo al cambio). Y que desde el punto de empresa de desarrollo (Avansoft en este caso), no se puede hacer software solo con “código ventiao”, existen métodos, metodologías, patrones, artefactos, etc. Que deben ser ANALIZADOS y DISEÑADOS con mucho mas tiempo que el que gastamos mirando como lo hacemos en Java o .NET (y esa es otra discusión, es que el desarrollo de software no es solo decir que .NET es mejor que Java porque tiene menos código, o lo contrario). Ojo: Solo el 50% de los proyectos de TI son exitosos.
Una nota de Matt Hotle de Gartner, “para el 2008, el desarrollo de software se debe enfocar en Workflow (Y eso que es? Como se come?), funcionalidad y procesos (Procesos? Será que pensamos en eso? Y cuando boleamos código?), no aplicaciones tipo SILOS o CHIMENEAS. Los desarrolladores tendrán que escribir aplicaciones compuestas una vez y REUTILIZAR sus componentes muchas veces en todo el negocio”. Y continua “Una cultura de REUTILIZACIÓN será aceptada y el desarrollo de aplicaciones orientadas a servicios dominará” “El código será bien usado y los desarrolladores deben estar motivados para hacerlo”.Porque esperara hasta el 2008? No podemos empezar ya?.
posted by Unknown @ 11:05 a. m.
0 Comments:
Publicar un comentario
<< Home