EscucharRealmente no importa por qué el mundo está cambiando tan rápidamente; lo importante es darse cuenta de que la velocidad del cambio sigue en aumento y de que no hay razón para pensar que vaya a disminuir, ciertamente no en el corto o el mediano plazos.
Independientemente de la importancia que la tecnología haya tenido en el aumento de la velocidad del cambio, debemos reconocer el valor que tiene como herramienta para afrontar el cambio.
La tecnología de información (TI) es, sin duda, una de las muchas herramientas de que disponen las empresas e instituciones para afrontar el cambio.
Afrontar el cambio con éxito implica cambiar rápidamente; esto puede ser para afrontar nuevas condiciones de mercado, para afrontar nuevos competidores, afrontar usuarios que cada vez tienen menos paciencia o incluso para aprovechar nuevas tecnologías. Pero el cambio no tiene por qué ser reacción a cambios en el entorno; los visionarios anticipan los cambios en el entorno, mientras que los revolucionarios los producen.
Mayor agilidad. Es claro que, para sobrevivir en este siglo, las organizaciones deben ser mucho más ágiles que en el siglo pasado. La opción de detener el ritmo del desarrollo, la evolución y el progreso solo se le puede ocurrir a un tarado. La realidad es que todas las organizaciones, tanto públicas como privadas, deben hacerse más ágiles. Esto es un verdadero reto pues, cuanto más grande y antigua es la organización, más tiesa suele ser.
Las grandes organizaciones con muchos años de servir a un pueblo o a un mercado han creado formidables barreras de entrada a sus posibles competidores y de salida a sus clientes o usuarios. Estas barreras han servido bien durante décadas, pero ¿aguantarán la presión de las nuevas tecnologías? La evidencia dice que no, debido a que las nuevas tecnologías no atacan las barreras de frente: las hacen irrelevantes (por ejemplo, derrotando la distancia y la geografía).
La TI a su vez puede ser lastre en muchas organizaciones, e impide la agilidad requerida para sobrevivir. Sistemas de información desarrollados y mantenidos durante décadas han demostrado ser más tiesos que un lagarto enyesado. Cada vez que los gerentes solicitan nuevas funcionalidades de esos sistemas, la respuesta es insatisfactoria. El tiempo, el esfuerzo y los riesgos involucrados en hacer que viejos sistemas hagan cosas nuevas están discapacitando a muchas organizaciones.
Necesaria explicación. La respuesta es una adecuada arquitectura del software empresarial. Desafortunadamente, arquitectura y software no son dos palabras que vayan bien juntas. Todo lo contrario, cuando líderes organizacionales oyen mencionar la arquitectura de software , se les nubla la razón y se les cierra el entendimiento. Como la gran mayoría de los líderes organizacionales son gente inteligente y razonable, la culpa de esa reacción la tienen necesariamente los técnicos que hemos sido incapaces de explicar de manera articulada qué es y por qué es necesaria una arquitectura de software orientada a servicios.
El término “arquitectura de sistemas de información” lo acuñó John Zachmann en 1987. Durante los últimos 10 años se ha hecho evidente la necesidad de una arquitectura basada en componentes que permita la reutilización y la estandarización.
Durante los últimos 5 años se desarrolló el consenso de que dichos componentes deben ser muy cercanos (o muy ligados) a los servicios del negocio. Ya hay muchas experiencias exitosas con la arquitectura orientada a servicios (SOA por sus siglas en inglés) y las herramientas para implementarlas.
Seminario. El próximo 14 de septiembre, el Object Management Group (OMG) y el Club de Investigación Tecnológica realizarán un seminario-taller en el que se presentarán y analizarán casos reales de organizaciones, como el National Cancer Institute y la National Archives and Records Administration.
El factor común de todos los casos que se presentarán es la búsqueda de la agilidad empresarial mediante la arquitectura de software .
La tarea de articular y explicar bien qué es y por qué deben nuestras organizaciones invertir en una arquitectura de software , sigue pendiente. Esperamos que el estudio de estos casos nos ayude a todos a lograr dichas articulación y explicación para el beneficio de nuestras organizaciones.
