Arquitectura Tecnológica Empresarial


Una pregunta frecuente que se escucha de los ejecutivos de tecnologías de información, al menos los que tienen la inquietud, porque conozco bastantes casos en los cuales la pregunta ni siquiera existe. Volviendo al primer grupo la inquietud que surge es: ¿cuál es la arquitectura tecnológica adecuada para mi organización? creo que un buen punto de partida para analizar esto es un estudio realizado por el MIT, el cual me parece muy atingente y que permite caracterizar adecuadamente los diferentes niveles de madurez de las organizaciones en esta área.

El estudio al que nos referimos fue realizado por el Sloan Center for Information Systems Research del MIT en el año 2005, en el cual se pudo tipificar la evolución de las organizaciones respecto del estado de sus arquitecturas tecnológicas empresariales en cuatro niveles de madurez, lo cual se ve reflejado no sólo en las características de su arquitectura sino también en sus prácticas de gestión asociadas. Cabe señalar que los niveles de madurez tienen asociadas buenas y malas prácticas y no nencesariamiente hay que mirarlos con un análisis peyorativo para los primeros, ya que este es un proceso por el que deben transitar todas las organizaciones.

Nivel I: Silos (Departamentales)
Las organizaciones buscan maximizar el aporte a requerimientos y funcionalidades específicas del negocio. Focalizan sus inversiones en tecnologías para resolver problemáticas puntuales y acotadas. No se miran los estándares como un aporte. El rol de las tecnologías (TIC's) es automatizar procesos específicos. Habitualmente las inversiones se justifican en base a reducción de costos. Una buena gestión en esta fase se caracteriza por diseñar procesos de negocio y la tecnología específica requerida para soportarlo.

Nivel II: Estandarización
Las organizaciones buscan mejorar la eficiencia de las TIC's, vía su estandarización y centralización. En esta etapa se mueven arquitecturas basadas en modelo locales a modelos compartidos. Se reduce la cantidad de plataformas diferentes existentes. La definición y administración de estándares corporativos es lo central. Se producen procesos de centralización y consolidación de infraestructura.

Nivel III: Optimización del Nucleo
Se transita a una arquitectura empresarial que da cuenta de procesos y datos estandarizados. Las organizaciones se mueven desde una mirada local de los datos y aplicaciones a un enfoque global (corporativo) y que abarca a toda la organización. El área informática elimina la redundancia de datos y desarrolla aplicativos con un mirada corporativa. Las inversiones en TIC buscan mover la infraestructura con un carácter local y funcional específico a uno global buscando soluciones empresariales. El desafío de gestión informática en esta etapa es construir plataformas reusables que reutilicen los datos y procesos de negocio existentes

Nivel IV: Modularización
En esta etapa se busca modularizar y flexibilizar la etapa la etapa anterior permitiendo un mayor grado de adaptabilidad de la arquitectura con los cambio del negocio.

Los niveles anteriores corresponde a un proceso evolutivo y de madurez normal de las organizaciones y es muy difícil que una organización se salte alguna de estas etapas.

A partir de esa segmentación la misma institución realizó un análisis de la inversión en tecnologías muy sugerente, el cual refleja claramente donde se ponen los acentos



Adicionalmente realiza una análisis de basado en la misma segmentación de madurez del rol que debe jugar el máximo ejecutivo de tecnologías dentro de la organización, cuales deben ser sus competencias y habilidades.

Silos:
  • Conocimientos técnicos que permitan tomar decisiones basadas en estándares.
  • Habilidad para estructurar proyectos tecnológicos de alcance acotado y local con el uso de metodologías probadas.
  • Habilidad para trabajar en equipo con altos directivos de la organización.
  • Desarrollar casos de negocios.
Estandarización
  • Conocimiento detallado del negocio.
  • Administrar proceso de cambio importantes.
  • Credibilidad por parte de áreas usuarias y sus directivos.
  • Entender la arquitectura como un habilitante del negocio.
Optimización y Madurez
  • Capacidad para facilitar la innovación
  • Conocimiento detallado del negocio y como las TIC's lo promueven
  • Entender y promover los beneficios estratégicos de una arquitectura bien definida
En todas las etapas salvo la primera (Silos) la dependencia del ejecutivo de tecnologías es directa Gerente General, en el caso de la primera etapa su depedencia generalmente es del área de administración y finanzas.

Creo necesario que las organizaciones de todo tipo puedan evaluar donde se encuentra y a partir de allí iniciar un proceso de diseño y/o formalización de su arquitectura.


Me pregunto que ocurrirá en Chile y creo que sin estar muy lejos de equivocarme nuestras empresas y me refiero a las con mejores prácticas se concentran el primer nivel y segundo nivel. Adicionalmente se ve poco que nuestros gerentes de tecnología les preocupe el diseño de una arquitectura empresarial, salvo cuando el mercado o influencias de casas matrices obligan a ello.

En el mundo público, si consideramos al estado como una gran corporación uno podría realizar un análisis similar y el resultado es aún peor que en el caso privado, el comportamiento de Silos está más presente y son muy pocas las iniciativas con una mirada de estandarización y menos aún de optimización del núcleo. Algunos países de la OCDE han visualizado esta situación y se encuentran en un proceso serio de pasar del nivel I a II, buscando fuertemente la estandarización, tal es el caso de Finlandia, Canadá y Dinamarca entre otros.

Es de esperar que luego de una año perdido en el desarrollo de iniciativas de mejoramiento y modernización del estado podamos retomar la senda definiendo un modelo de arquitectura con una mirada corporativa.

¿Gula Tecnológica?

"Nikesh Arora, vicepresidente de Google para Europa predice: Dentro de cinco años un Ipod podría almacenar el contenido emitido por una cadena de televisión durante todo un año. Dentro de diez, toda la música creada por la humanidad a lo largo de la historia; y dentro de solo doce años todo el contenido audiovisual de nuestra especie, incluidas las películas, programas y videos domésticos" (Que Pasa, 1 Diciembre 2006).

Hoy en día estos disposittivos mp3 de 80 gbytes pueden almacenar 20.000 canciones, a un promedio de 3 minutos por canción, se puede almacenar música para 60.000 minutos, el equivalente a 1.000 horas, es decir, más de 41 días (con sus noches incluidas) de música initerrumpida, ¿no será mucho?

Esto me lleva a otra reflexión que tiene más relación con los artículos de esta columna, ¿no estaremos sufriendo de gula tecnológica?, es decir, entendemos muchas veces el soporte tecnológico como compra de tecnología y no como servicios de valor agregado al negocio.

En nuestro país tenemos ejemplos paradigmáticos de como algunas instituciones, tanto públicas como privadas, que priv
ilegian la compra de infraestructura (servidores, discos, software básico, computadores de escritorios y hasta salas de procesamiento) por sobre los servicios.

Recuerdo el caso de una institución pública que luego de gastar varios millones de dólares en infraestructura, finalmente el servicio al ciudadano siguió siendo el mismo (malo y lento!). Para colmo algunos gerentes/directivos muestran ese tipo de gasto como un gran logro de la organización.


Por otra parte son pocas las ocasiones en las que realiza un análisis de la arquitectura tecnológica requerida para un determinado negocio y la adquisición de tecnología se transforma en una lista de supermercado. No son pocos los administradores de tecnología que piensan que renovando la infraestructura tienen la pega hecha, ¿será por que es mucho más facil comprar hardware que desarrollar proyecto TI exitosos?

Todas las instituciones deben pasar por un proceso de diseño arquitectónico detallado que de cuenta de los requerimientos del negocio tanto actuales como futuros y estos los lleve al mapa tecnológico: sistemas, equipamiento y servicios necesarios para soportar el negocio con adecuados niveles de servicio para los clientes o usuarios.

El proceso es una cadena que parte en los requerimientos del negocio, para luego modelar el soporte tecnológico necesario expresado en una arquitectura, para finalmente traducir dicho mapa en una estrategia de implementación compuesta de todos los elementos que plasmarán esa arquitectura en el soporte tecnológico requerido. Revisando este proceso en forma más detallada:


Negocio: Se debe evaluar el estado actual del negocio, su entorno (mercado, comptencia, clientes, proveedores, regulaciones), para luego definir un estado deseado u objetivo. Con estos análisis se debe evaluar la brecha y como cubrirla (mecanismos y procesos).

Arquitectura: Con una visión clara del estado actual y futuro del negocio, esto permite definir los criiterios de diseño de la arquitectura, luego hay que realizar un inventario de todas las componentes de la arquitectura actual (plataforma, sistemas, organización, proyectos), para proceder al modelamiento de la nueva arquitectura tomando como telón de fondo la evaluación del negocio y el estado de desarrollo actual de su soporte tecnológico.

Proyectos: Producto de la nueva arquitectura esto se refleja en una cartera de proyectos, los que deben priorizarse y calendarizarse. Como una activiadad posterior cada una de los proyectos deben definirse en destalles, esto es, sus alcances, objetivos, enfoques metodológicos, WBS, costos y métricas asociadas.

Organización: Como una actividad complementaria se debe evaluar la organización informática, su estructura, roles y las capacidades (competencias) necesarios para abordar la ejecución de los proyectos que instancian la nueva arquitectura.


Factores Críticos de Éxito
Como antecedente complementario me parece relevante tener presentes algunos de los factores críticos de éxito para diseñar un arquitectura tecnológica:
  • Claro entendimiento del negocio, donde se encuentra hoy y hacia donde se dirige.
  • Cubrir todos los elementos en forma simple y efectiva
  • La arquitectura debe permitir transformar su diseño en un conjunto acotado de proyectos adecuadamente definido (objetivos, alcances y resultados claros)
  • La arquitectura debe contar con un administrador


Principios Rectores
Algunos de los principios que deben regir a una arquitectura son:
  • El negocio y su entorno
  • Entendimiento de la información y los sistemas como un activo de la organización
  • Contar con un modelo de desarrollo de sistema y del ciclo de vida del software
  • Uso de estándares comunmente aceptados
  • Decisiones de compra deben estar alineadas con la arquitectura en sus diferentes componentes.
  • Consolidación de infraestructura (hardware y software) esto permitirá reducir costos y mejorar el servicio
  • Capacitación y actualización al personal de informática con las nuevas tecnologías
  • Adoptar prácticas de aseguramiento de la calidad y metodologías que permiten su desarrollo (ITIL, ISO, CMM entre otras)

Mientras más se incrusta la tecnología en el corazón del negocio (core business) de una organización más imprescindible se hace contar con un mapeo de la arquitectura tecnológica y su vinculación con los procesos de negocios. Es de esperar que la gula tecnológica no nos atrape sobre todo en período navideños y de fin de año.

Proyectos TIC en el Sector Público



Proyectos TIC en el Sector Público

“Esfuerzo temporal emprendido para proveer un producto o servicio únicos” - Project Management Institute



Algunas cifras

El estado chileno según un estudio desarrollado por la Dirección de Presupuestos con cifras presupuestarias del año 2003, gasta en tecnologías de información y comunicaciones (TIC) aproximadamente 205 millones de dólares anuales, lo cual representa un 2.3% del gasto total del estado y aproximadamente 0.2% del PIB. Lo cual si bien es un buen porcentaje comparado con el gasto promedio en TIC a nivel nacional correspondiente al 1.66% de la facturación, está muy por debajo del gasto en tecnologías de información en otras latitudes como en el caso del Reino Unido donde llega al 1% del PIB. Según el mismo informe se demuestra que el gasto se concentra mayoritariamente en el ítem servicios computacionales.

¿Qué ocurre con los proyectos?
Las cifras respecto del desarrollo y comportamiento de proyectos TIC existentes no son muy alentadoras, según estudios realizados por Standish Group en USA y la Universidad de Oxford en el Reino Unido, sólo el 16% de los proyectos TIC son exitosos (se considera exitoso, proyectos que han terminado utilizando los recursos y tiempos inicialmente planificados). Si el análisis se restringe sólo a proyectos de desarrollo de software esta cifra baja al 1%.

Otro elemento interesante de destacar de dicho estudio es que tanto el sector privado como público mantienen tasas de éxito equivalentes.

Estructura de Proyecto
El ciclo de vida de un proyecto podemos identificar básicamente tres grandes fases, diseño, ejecución y operación. Los factores de riesgo los podemos visualizar en un espacio tridimensional en el cual los ejes son: tamaño del proyecto, calidad de la definición de los requerimientos y nivel de conocimiento de la tecnología necesaria. En la medida que al momento del diseño del proyecto pueda situar mi proyecto en dicho espacio, esto me va a dar ciertas luces del riesgo asociado.

Caracterísiticas de Proyectos TIC en el Estado
Los proyectos TIC tienen singularidades propias dentro del sector público, las cuales deben ser atendidas y analizadas al momento del diseño y análisis del mismo. Estas se pueden segmentar en tres áreas:

Gobierno:

  • Los gastos en el estado tienen el escrutinio público (accountability)
  • Con mucha frecuencia se promocionan proyectos antes de su puesta en marcha, lo que pone una presión excesiva para su término
  • El ámbito público tiene un marco jurídico y regulatorio bastante rígido. El derecho público regula lo que se puede hacer (sólo lo que está dicho)
  • En muchos proyectos se requiere de coordinaciones interinstituciones lo que complejiza los proyectos.


Tecnológicos:

  • La velocidad del cambio tecnológico es extremadamente acelerada, lo que no está de acuerdo con las velocidades de cambio en el sector público.
  • En general las soluciones tecnológicas en el estado están asociadas a grandes volúmenes transaccionales y de procesamiento, lo que plantea un gran desafío al momento de definir las arquitectura tecnológicas necesarias
  • El nivel de desarrollo tecnológico dentro del estado es muy heterogeneo, lo que hace muy complejo definir soluciones de carácter global.


Gestión:

  • Se requieren habilidades de gestión y administración de proyectos tecnológicos complejos
  • Los contratos son de alta complejidad, tanto en su diseño, como en su posterior administración.
  • Existe una pobre administración de proveedores, ya sea por desconocimiento y/o por restricciones reglamentarias

Causas de Fracasos de Proyectos TIC
Entre las principales causas de fracasos de los proyectos tecnológicos puedo mencionar:

  • Falta de vínculo entre el proyecto y las prioridades estratégicas de la institución
  • Falta de habilidades de gestión de proyectos y administración del riesgo
  • Falta de liderazgo y ownership del proyecto
  • Poco conocimiento de la industria TI local y de lo que realmente puede proveer.
  • Presupuestos mal definidos
  • Evaluación de propuestas con mirada de corto plazo sustentado en oferta económico y no en valor del gasto
  • Pocas iniciativas para segmentar los proyectos en tamaños más manejables
  • Arquitectura tecnológica mal definida
  • Niveles de servicio (SLA's) mal definidos y/o no administrados

Iniciativas de Mejora

Creo que el estado debe abordar iniciativas de mejora que apunten a reducir los riesgos asociados a los proyectos TIC, entre ellas puedo mencionar:
  • Aumentar el esfuerzo en las etapas tempranas del proyecto (diseño) considerando todas las etapas
  • Conformación de los equipos de trabajo con las competencias y habilidades requeridas
  • Establecer owner de los proyectos complejos al más alto nivel de la institución
  • Compartir experiencias (éxitos y fracasos) a nivel de ejecutivos TI del estado
  • Establecer programas de certificación y competencias en gestión de proyectos tecnológicos
  • Establecer centros de competencia que puedan servir de referencia y apoyo
  • Establecer relaciones adecuadas con proveedores

Creative Commons License