domingo, 10 de junio de 2012

La importancia de conocer nuestros límites y saber manejar cosas “pequeñas”



La importancia de conocer nuestros límites y saber manejar cosas “pequeñas”

El ser humano tiene sus límites y, en particular, cada uno de nosotros tenemos los nuestros que difieren de los del vecino. De la misma forma las organizaciones tienen los suyos, pero no sólo en las factorías de software, call centers of fuerza de ventas, también lo tienen en las oficinas de proyecto (PMO), estrategia, e incluso en el board de directors.

Muchas organizaciones fracasan en su estrategia porque no son capaces de entender dónde están sus límites, cuáles con sus capacidades como organización, y por establecer objetivos inalcanzables o irrealistas que se convierten en auténticas losas rígidas, inflexibles y desmotivadoras para los empleados, partners y proveedores.

TOGAF habla de Architecture Capabaility Framework como una serie de técnicas y herramientas para conocer nuestros límites y establecer procedimientos, normas y políticas que gobernarán nuestra transformación, desde las fases preliminares del ciclo ADM (Architecture Development Methodology), hasta las fases finales F.Migration Planning, G. Implementation Governance, o H. Architecture Change Management.

Desde mi experiencia, muchas organizaciones son capaces de avanzar en el ciclo ADM pese a tener limitaciones de recursos, presupuesto o información en la elaboración de la target architecture, incluso definen con éxito los proyectos e iniciativas que cubren el gap entre la arquitectura actual y la arquitectura objetivo (business, information systems, and technological), pero donde rotundamente fracasan es en su puesta en marcha, implementación y control y monitorización.

Es normal que se identifiquen cientos de proyectos/iniciativas como resultado del ciclo ADM. Yo suelo deccir que no sé manejar 200 cosas distintas, que enseguida pierdo el control de muchas de ellas. Sin embargo sí puedo gestionar y controlar 20 ó 30. La agrupación de Proyectos en Programas facilita esta labor.

Recordemos la definición que da el Project Management Institute (PMI) en el libro ”The Standard of Program Management” (2nd Edition) relativa a programas y proyectos: En concreto, define Programa de la siguiente manera: 
  • A Program is a related group of projects managed in a coordinated way to obtain benefits and control not available from managing them individually”. Que básicamente viene a decir que un Programa es una serie de proyectos relacionados en los que si se coordina su ejecución se obtendrían más beneficios que si se ponen en marcha individualmente.

Un Enterprise Architect aporta mucho valor añandido en la fases E. y F. del ciclo ADM si es capaz de agrupar proyectos relacionados entre ellos en programas que sí sean manejables. Muchos equipos fracasan porque no son capaces de entender esto y, en concreto, muchos líderes y ‘decision makers’ de grandes corporaciones naufragan ante una lista interminable de proyectos con dependencias que no entienden, costes agregados y plazos que van más allá de sus expectativas de permanencia en el puesto.

Hagamos la vida más fácil y conozcamos nuestras limitaciones y las de nuestra organización para hacer realidad nuestros objetivos.


sábado, 2 de junio de 2012

El valor de los Viewpoints en TOGAF


El valor de los viewpoints…

Hoy en día nos dedicamos a representar sistemas desde un punto global que cubren las necesidades y preocupaciones (concerns) de negocio de los stakeholders. Preparamos vistas (views) de negocio, de sistemas de información, tecnológicas… con la idea diseñar de la manera más clara posibles las funciones de ese sistema en cuestión.
Todo esto está bien y es estupendo cuando realmente se hace. Chapeau!

Respecto a lo enunciado anteriormente aclaremos dos conceptos dentro del mundo de TOGAF:
  • un Sistema es una colección componentes organizados de manera estructurada para realizar una o varias funciones específicas.
  • Concerns es definido por TOGAF como los intereses clave y cruciales de los stakeholders relacionados con el sistema y que determinarán la aceptación del propio sistema.


Que es lo que ocurre en el mundo real? Pues que muchas veces los stakeholders no entienden estas vistas y no responden a sus necesidades específicas de negocio. En concreto, en muchas ocasiones no tendrían necesidad de verlas y es que un stakeholder quiere ver el sistema desde su propio punto de vista de negocio para ver cómo va a dar respuesta a sus necesidades (concerns). Y ya que en el mundo real puede haber muchos stakeholders, TOGAF  propone una serie de Viewpoints específicos para dar respuesta a este problema tan habitual. 

No nos asustemos, no hace falta crear tantos Viewpoints como stakeholders!


Las Viewpoints de TOGAF son vistas con una perspectiva de negocio específica. Hay un clásico ejemplo de un sistema aéreo con dos stakeholders: el piloto y el controlador aéreo. Ambos utilizan el mismo sistema pero tienen intereses de negocio distintos y un buen Enterprise Architect les facilitara unos Viewpoints específicos para cada uno derivado de la Vista del sistema con la que trabaja el EA. Al final el sistema diseñado dará respuesta a sus concerns y el sistema estará diseñado para realizar una serie de funciones en las que ambos roles participarán de otra manera.

El Enterprise Architect siempre busca la respuesta a una necesidad de negocio desde un punto de negocio aplicando las diferentes arquitecturas empresariales: Business, Applications, Data and Technology. El gran EA es el que sabe elegir que Viewpoints son los mejores para dar respuesta a los stakeholders.

No olvidemos que si hacemos bien esta tarea, la aceptación del sistema será mucho más fácil.