Cómo adoptar una estrategia SOA a prueba de crisis

Business IntelligenceDatos y AlmacenamientoEmpresasERPFabricantes de SoftwareProyectosSoftware
0 0 No hay comentarios

La crisis económica actual está afectando tanto al gasto tecnológico como a los presupuestos para 2009, por lo que los directores de TI deben esforzarse en reducir costes en estos tiempos de incertidumbre.

Ross Mason, colaborador del Knowledge Center de eWEEK, explica cómo poner en marcha una estrategia de Arquitectura Orientada a Servicios (SOA) a prueba de crisis.

Los directores de TI se enfrentan ahora a la proverbial tarea de “hacer más con menos”. Cuando uno tiene que enfrentarse con la orden incuestionable de reducir costes innecesarios y prepararse para la criba, el instinto natural nos dice que hay que eliminar todos los nuevos proyectos y centrarse en la racionalización y el mantenimiento de la infraestructura existente. Sin embargo, en un mundo en el que las TI ocupan un lugar cada vez más importante en la empresa, este “hacer menos con menos” es contraproducente y puede provocar consecuencias indeseadas.

Si la eliminación de nuevos proyectos carece de sentido, ¿qué puede hacer un director de TI que quiera sacar el máximo provecho a sus inversiones en un entorno de presupuestos ajustados? Recurrir a la arquitectura orientada a servicios, es decir, los proyectos conocidos como SOA. Si en un principio esta iniciativa SOA se puso en marcha por razones de negocio (como mejorar la agilidad, la visibilidad de la empresa o la eficiencia operacional a través de la integración), abandonarlos ahora no haría ningún bien a dicho negocio.

Afortunadamente, las herramientas disponibles se han incrementado considerablemente en los últimos años. SOA ya no representa una opción de alto riesgo y coste para la empresa. En muchos casos, los estándares alterados (por ejemplo, SOAP/WS-*) y el software complejo y pesado están siendo sustituidos por otras opciones más simples (por ejemplo, el REST, o la transferencia de estado representacional) y herramientas ligeras y de código abierto.

Esto significa que las organizaciones pueden aprender de los errores de los que primero adoptaron esta arquitectura y adquirir SOA de una forma mucho más pragmática y orientada a sus necesidades. SOA, como iniciativa construida desde arriba, se queda definitivamente “fuera”, ya que las organizaciones no pueden permitirse rediseñar las cosas desde cero en estos tiempos que corren. En vez de eso, para que un proyecto SOA triunfe tiene que aprovecharse de las nuevas herramientas y técnicas, exprimiendo hasta la última gota de los sistemas ya instalados.

A continuación se exponen cinco pasos para que las empresas que estén pensando en desplegar una estrategia SOA lo haga de la manera más provechosa posible.

Paso 1: Identificar los objetivos de negocio y la manera en la que las TI pueden responder a ellos

Las inversiones en tecnología que facilitan procesos de negocio (por ejemplo, mercadotecnia o cadenas de suministro) pueden aumentar hasta en 10 veces el impacto de los esfuerzos tradicionales de reducción de costes de TI. Llevar a cabo los objetivos de negocio no significa que las TI se conviertan en una “utility”, en donde se aceptan las órdenes de los propietarios de las empresas. Significa que las TI colaboran con los propietarios de las empresas y les ayudan a entender qué posibilidades hay para convertirles en los defensores del cambio tecnológico.

Paso 2: Priorización de proyectos

Separar lo que es “necesario tener” de lo que “sería bonito tener”. Una vez identificados los objetivos tecnológicos de la empresa, conviene hacer una selección en la carpeta de proyectos. Conviene mantener sólo aquellos proyectos que responden estrictamente a los objetivos marcados. Este no es simplemente un ejercicio de reducción de costes, sino más bien una manera de centrarnos en los recursos limitados que tendrán un impacto inmediato en el negocio.

Para exponerlo de una forma clara, la priorización no significa necesariamente terminar con la experimentación o la evaluación de nuevos proyectos o herramientas. Al contrario, se deben dedicar recursos adicionales para intentar resolver los problemas más prioritarios, y aceptar algunos riesgos mientras se construye un sólido plan B.

Autor: DRosolen
Leer la biografía del autor  Ocultar la biografía del autor