3002008060502. Entrevista: Alberto A?lvarez, NetManage

La primera pregunta sobre SOA es A?CA?mo definirla?

Desde el punto de vista tA�cnico, hay que entender SOA como una arquitectura que va a transformar la manera en que escribes las aplicaciones. Es una forma de trabajo, una disciplina, y tambiA�n un conjunto de herramientas que permiten aplicar esta disciplina. Como ha ocurrido con todas las grandes revoluciones informA?ticas. QuizA?s la primera que herramientas que te permiten gobernar aplicaciones, monitorizar el negocio, planificar y, en definitiva, entender y conocer mejor cA?mo funciona el negocio. QuA� tipo de servicios informA?ticos

((Es una forma de trabajo, una disciplina, y tambiA�n un conjunto de herramientas que permiten aplicar esta disciplina.))

A?CuA?les son los puntos clave de una arquitectura SOA?A?Por dA?nde se comienza el trabajo en una empresa a la hora de abordar SOA?

Lo mA?s importante a la hora de iniciar un proyecto SOA es comprender cA?mo funciona el negocio. Los empleados trabajan con las herramientas informA?ticas todos los dA�as, pero a pesar de contar con estas herramientas para alimentar y gestionar los datos, la direcciA?n no tiene una visibilidad clara. AsA� que lo primero es realizar un anA?lisis de negocio, ver quA� es lo que se estA? haciendo y cA?mo. De ahA� se van a extraer las unidades de servicio que van a formar la base de tu proyecto. Y no vas a intentar cambiar de hoy para maA�ana todo en SOA, sino que se debe ir paso a paso. Se trata sin duda de un trabajo incremental, buscando las funciones que den mayor rentabilidad.

A partir de ahA�, segA?n vas creciendo en aplicaciones que se basan en esta arquitectura, vas incluyendo nuevas herramientas e incrementando el volumen de complejidad e incluso de activad sobre esta arquitectura.

A?Es correcto pensar en SOA como una soluciA?n global? A?Permite crear una soluciA?n llave en mano?

SOA es bA?sicamente una vA�a de evoluciA?n de los ERP y CRM, que, sobre todo, permite que las soluciones sean mA?s abiertas y basadas en componentes de negocio reutilizables. Al mismo tiempo es una evoluciA?n para tus propias aplicaciones. Para que poco a poco se vayan transformando en generadores de nuevos componentes. Porque lo que todos tenemos que admitir es que no hay una herramienta estA?ndar que cubra todo lo que necesito en mi negocio. Sobre todo, porque si lo hubiera, significa que mi compaA�A�a es idA�ntica a otra compaA�A�a, que ademA?s posiblemente tambiA�n es mi competencia.

AsA� que necesito un factor diferencial respecto a cA?mo trabajan otras empresas. Lo que no quita que cada vez mA?s haya toda una serie de mA?dulos que pueden compartirse en mA?ltiples empresas, como la contabilidad, el pago de las nA?minas, asA� como otros que son de carecer legal y administrativo, pero que no ofrecen un carA?cter diferencial de mi compaA�A�a. Por eso sigue habiendo mucho desarrollo propio, y por el mismo motivo en este paA�s los integradores y las consultoras resultan ser los principales fabricantes de software.

((PrA?cticamente todas las compaA�A�as estA?n cambiando hacia sistemas de informaciA?n que se sean mA?s flexibles, que permitan adaptarse a las necesidades de tu negocio))

A?Las empresas empiezan a entender la importancia de SOA?A?Hay que evangelizar en ese sentido?

No, por el contrario, las compaA�A�as entienden la necesidad de modernizar sus infraestructuras tecnolA?gicas y han visto rA?pidamente los beneficios de SOA. PrA?cticamente todas las compaA�A�as estA?n cambiando hacia sistemas de informaciA?n que se sean mA?s flexibles, que permitan adaptarse a las necesidades de tu negocio, asA� que por ese lado no se necesita una evangelizaciA?n. Aunque las empresas entienden que es necesario una arquitectura mA?s liberal, quizA?s es mA?s una revoluciA?n del comportamiento de la compaA�A�a en cuanto a colaboraciA?n y entendimiento entre negocio y tecnologA�a.

Antiguamente habA�a una relaciA?n entre la direcciA?n y la parte tecnolA?gica del tipo a�?tA? pide lo que quieras que yo te darA� lo me parezcaa�?. Las compaA�A�as estA?n evolucionando para tener personas tA�cnicas mA?s orientadas a lo que pide el negocio y menos al detalle de los productos y la tecnologA�a informA?tica. Y al revA�s, la gente de negocio debe volcarse en conocer quA� le puede pedir a la tecnologA�a para mejorar y dar valor a mi negocio. No se trata de que se conviertan en expertos en informA?tica, ni falta que les hace ya que al fin y al cabo se trata de una herramienta tecnolA?gica, pero tienen que aprender a ver los valores que les puede aportar.

Es decir que la parte de negocio debe aprender a quA� y cA?mo puede pedir las soluciones de negocio

SOA lo que tiene es que requiere un trabajo en equipo. Cada uno debe asumir su responsabilidad y su papel, pero con la idea del trabajo conjunto. BA?sicamente se trata de llegar a decisiones colegiadas, de hacer mA?s trabajo en equipo. Cada uno asume su parte de la pregunta y de la respuesta. AsA� pues SOA establece un mecanismo de colaboraciA?n y normaliza la cooperaciA?n entre la parte de negocio y la de informA?tica. fortunadamente cada dA�a hay directivos jA?venes mA?s preparados, que entienden esta visiA?n.

SegA?n lo anterior, parece que la parte de negocio entiende las nuevas reglas de trabajo, pero A?ocurre lo mismo con los desarrolladores? A?Cambia mucho su trabajo?

Para los desarrolladores es fundamentalmente una cuestiA?n de tiempo. Lo que dicen todos los informA?ticos es a�?dame tiempo y yo te hago bien lo que pidesa�?. Inicialmente, hacer una soluciA?n con SOA requiere mA?s tiempo que hacer una construcciA?n a la antigua. Sobre todo porque no se ven obligados a pensar en cA?mo generalizar la soluciA?n, sino que se atiende la necesidad del momento.

Desgraciadamente en las compaA�A�as empujan a la secciA?n de informA?tica a que resuelvan los temas a�?para maA�anaa�?. Y el para maA�ana y SOA resultan dos mundos difA�ciles de compaginar. De ahA� que nosotros apostemos por reutilizar lo que tengo, y no volver a reescribir para construir SOA, para poder ganar ese tiempo que en caso contrario se emplea en escribir de nuevo con una filosofA�a distinta algo que ya tengo en producciA?n.

La clave para los informA?ticos estA? en entender que se pude reutilizar mucho de lo que ya se tiene, pero hay que reestructurarlo con una filosofA�a flexible. Si miras cualquier programa que estA? atendiendo tu negocio verA?s que los mA?dulos del programa estA?n orientados a la tarea, porque esta era la mecA?nica de la programaciA?n antigua. Alguien encomienda una tarea y el programador la resuelve. Lo que no siempre se dan cuenta es que una tarea es un servicio Web.

((Las compaA�A�as estA?n evolucionando para tener personas tA�cnicas mA?s orientadas a lo que pide el negocio y menos al detalle de los productos y la tecnologA�a informA?tica))

AsA� pues la mecA?nica de construcciA?n estaba orientada a la tarea, y ahora hay que buscar los mecanismos tecnolA?gicos para acceder a esta tarea mediante tA�cnicas vA�a Web. De manera que se pueda dotar de un interface a esta tarea que cumpla los estA?ndares Web.

Y en la prA?ctica A?cA?mo se realiza esto?

Pues segA?n nuestra filosofA�a, una vez que planificas quA� deseas, generas los primeros servicios que cumplen con la filosofA�a SOA, generalmente mediante Web services, los pones en funcionamiento en un primer piloto y observas cA?mo se comportan. AsA�, una vez que los ves operando, puedes hacer mejoras, por ejemplo en cuanto a disponibilidad, como ocurre con cualquier aplicaciA?n informA?tica. Es decir hacer una evoluciA?n, basada en los resultados que obtienes, de las pruebas de carga, etc.

Creo que nosotros combinamos muy bien con la tecnologA�a existente, lo que ayuda a que el departamento de informA?tica aprenda a reutilizar lo que tiene, y a transformarlo en pequeA�o componentes. Y esto resulta mA?s fA?cil de lo que parece, ya que, en general las aplicaciones estA?n mejor construidas de lo que aparentan a primera vista, y acumulan una experiencia en hacer las tareas que resulta muy valiosa. Simplemente hay que saber extraer ese valor.

Es decir que hay que volver a revisar las aplicaciones actualmente en servicio.

Ciertamente, hay que volver a mirar la aplicaciones, pero no porque estA� mal construidas, sino porque cuando piensas dos veces una tarea, se te ocurren mejores mecanismos para solucionarla. Es decir, hay que buscar una nomenclatura estA?ndar para el mecanismo de arranque de la tarea, que es lo que SOA impone. Pero la tarea en sA� misma no cambia. Una factura es una factura, la entrada de un camiA?n tiene el mismo tratamiento que antes, y eso ya lo recoge el sistema informA?tico que estA? actualmente en servicio. AsA� que puedo aprovechar que el sistema toma esos datos del funcionamiento real de la empresa y se estA? en disposiciA?n de generar con ellos un componente SOA.

((SOA establece un mecanismo de colaboraciA?n y normaliza la cooperaciA?n entre la parte de negocio y la de informA?tica))

AquA� es donde entramos nosotros. Si tratas de hacer esto con el esfuerzo de tus programadores, estos tienen que aprender las nuevas mecA?nicas de programaciA?n para escribir ese interface. Y eso es justo lo que nosotros automatizamos con nuestras herramientas. TA? eliges la tarea y la arrancas, con independencia del proceso de traducciA?n del interface. Junto con el arranque, tambiA�n hay comunicaciA?n de control de errores, respuestas que da el sistema, etc.

Esto es lo se denomina orquestaciA?n de SOA A?No es asA�?

Cierto, la orquestaciA?n de los procesos de SOA aparece en un segundo paso. Una vez que tengo lanzados una serie de servicios, que es cuando me planteo si puedo organizarlo mejor. En general, la orquestaciA?n de los servicios SOA se realiza con una herramienta estA?ndar, y ahA� puedo elegir una tecnologA�a Microsoft, una tecnologA�a Java, una herramienta BEA, etc, porque tendrA� la libertad de elegir el fabricante para las herramientas de gobierno construidas alrededor de SOA.

((Inicialmente, hacer una soluciA?n con SOA requiere mA?s tiempo que hacer una construcciA?n a la antigua, ya que no se estaba obligado a pensar en cA?mo generalizar la soluciA?n, sino que se atendA�a a la necesidad del momento))

El proceso de orquestaciA?n es simplemente un beneficio asociado. Pero lo primero que tienes cuando llegas a una arquitectura SOA es el mismo mecanismo que anteriormente tenA�as, y que ahora es llamado de forma mA?s eficiente. El paso a SOA conlleva que realmente sorprende el potencial que se tenA�a en la empresa y en segundo lugar que se generan mA?s fA?cilmente nuevos servicios, que no son otra cosa que combinaciones de tareas ya existentes previamente.

Para los programadores A?supone un cambio importante el paso hacia SOA?

Pues las herramientas se van especializando. Dentro del clA?sico esquema en tres capas, SOA se sitA?a en la capa de negocio. Por ello cualquier programador que aspire a ser experto en SOA debe ademA?s conocer cA?mo funciona la capa de negocio. Si desea evolucionar hacia SOA sin duda debe aprender nuevas tA�cnicas de programaciA?n, pero no por el hecho de estar en SOA, sino porque carece de la especializaciA?n necesaria en un terreno que no sA?lo es tA�cnico sino tambiA�n empresarial.

((Crear soluciones rA?pidamente y desarrollar bajo arquitectura SOA resultan dos mundos difA�ciles de compaginar, salvo cuando se logra reutilizar procesos existentes en la empresa))

Si no conoce las necesidades de la organizaciA?n difA�cilmente serA? un buen programador de la capa de negocio, porque el punto de vista que tiene que tener para los algoritmos que escribes informA?ticamente debe resolver problemas de negocio. Luego, ademA?s, debe ver cA?mo estos procesos son reutilizables.

Un programador clA?sico tiene mucho avanzado ya que posee la disciplina relativa al control de errores, basada en su experiencia, ya que antiguamente los programas estaban basados en que un cA?digo debA�a tener un mecanismo de control de errores. Sin embargo los programadores noveles no piensan inicialmente en ese tipo de detalles. Una de las cosas buenas de cara a SOA es que precisamente los programas que estA?n funcionando, es decir, los sistemas en producciA?n, contienen ese tipo de mecanismos de control y correcciA?n, con lo que se puede reaprovechar fA?cilmente esa capacidad. Y esto hace que resulten candidatos ideales para incluirlos en un proyecto SOA.

Hoy en dA�a A?hay todavA�a empresas que continA?en con desarrollos Legacy, aunque sean muy antiguos?

Esa pregunta tiene una respuesta sencilla. Ninguna compaA�A�a que se precie desecha un programa que funcione. AsA� que todas las empresas que iniciaron de forma temprana su automatizaciA?n, mantienen dichos programas, porque aquellas piezas de su aplicaciA?n que estA?n operativas, sirven para resolver problemas actuales de negocio. Lo que ha cambiado es la distribuciA?n de las tareas. Han dado entrada a programas de CRM y ERP para los mA?dulos de carA?cter estA?ndar, aquellos que no tocan el corazA?n del negocio. Con ello han logrado soluciones normales a problemas corrientes.

((Antes la mecA?nica de construcciA?n de los programas estaba orientada a la tarea, y ahora hay que buscar los mecanismos tecnolA?gicos para acceder a esta tarea mediante tA�cnicas Web))

El resto siguen siendo desarrollos a medida, resueltos tanto internamente como externamente. AllA� donde el cliente reconoce una ventaja competitiva, nunca utiliza una soluciA?n estA?ndar, porque ello le situarA�a a la misma altura que su competencia.

Precisamente SOA permite reaprovechar esa parte propia y vital que ya existe en los sistemas corporativos. Y, ademA?s facilita la integraciA?n de todas las piezas distintas que necesitas. En cualquier compaA�A�a actual hay sistemas heterogA�neos que se emplean a lo largo de diversos procesos. Precisamente SOA permite aprovechar de forma eficaz todos esos sistemas dispersos y heterogA�neos y, a la vez, centralizar la informaciA?n. Esto permite ademA?s, mayor libertad a la hora de construir las nuevas aplicaciones.