Dejar de empezar para empezar a terminar, o como un arquitecto IT puede organizarse

Empezar a terminar

El trabajo de un arquitecto IT en una empresa requiere muchas veces de enfrentarse a tareas de diferente índole, tamaño o prioridad. Estas, llegando a "la mesa de entrada" del departamento de arquitectura se convierte de manera muy fácil en un continuo inicio de nuevas actividades, y cuando nos queremos dar cuenta tenemos en nuestro backlog decenas de tareas sin terminar, lo que nos termina convirtiendo en un cuello de botella, y nos transforma en una pelota de stress y nervios.

Pensando en como resolver este tema y comenzar a destrabar tareas y ser mas eficientes, es necesario manejar de mejor manera el flujo de actividades que pasa por arquitectura. 

Una alternativa podría ser buscar la forma de que nos lleguen menos tarea, revisando si debiéramos hacer todo lo que hacemos, y definiendo claramente los procesos y límites del área. Muchas veces esto no es posible o, aún haciéndolo, seguimos en la misma situación. En estos casos, debemos dejar de empezar una tarea tras otra, y enfocarnos en comenzar a terminarlas.  De esta manera seremos mas eficientes, aumentaremos la calidad de lo que producimos, minimizaremos el riesgo de nuestras actividades y reduciremos el nivel de stress al que estamos sometidos. 

Gerald M Weinberg, en su libro Quality Software Management - System Thinking estima que el cambio de contexto entre tres tareas nos consume un 40% de nuestro tiempo de trabajo. Esto quiere decir que si tengo un proyecto A, B y C y tenemos 40 hs netas productivas por semana (eso con suerte, muchos tenemos la agenda abarrotada de reuniones y nos quedan menos de 20 hs productivas por semana), estaremos gastando 16 hs en el cambio de contexto entre las tareas, tratando de volver al nivel de conocimiento que teníamos antes de dejarla por iniciar otra actividad. Y solo nos están quedando 8 hs semanales para invertirle a cada proyecto.

Supongamos por un rato que podemos priorizar los proyectos A, B y C del párrafo anterior, y que decidimos arbitrariamente que vamos a hacer una tarea por vez, eliminando el cambio de contexto. En este escenario, tendríamos las 40 hs por semana para cada proyecto, lo que nos permitiría terminar el mas prioritario en menos tiempo. Siguiendo con este ejemplo, y para que nos quede claro el impacto que tiene el multitasking, supongamos que cada uno de los proyectos A, B y C se pueden hacer en 4 hs cada uno, y que el orden en que están nombrados indican su prioridad. Haciéndolo de la forma en que trabajamos habitualmente, los tres en paralelo, la línea de tiempo sería:

Para hacer el ejemplo mas simple, tengamos en cuenta que el cambio de contexto nos lleva una hora (es menos, y depende mucho de las tareas). En este caso, terminaríamos el proyecto A en la hora 19, la tarea B en la 21 y la tarea C en la 23. Pero el proyecto A era el mas prioritario, y solo lo entregamos dos horas antes del C!. Creo que podemos hacerlo mejor.

El siguiente cuadro muestra la línea de tiempo de ejecutar los proyectos anteriores uno a la vez:

Como se ve, se elimina el cambio de contexto, lo que nos produce una mejora enorme en nuestra productividad. El proyecto A lo terminamos en la hora 4 (versus la hora 19 de nuestra forma de trabajo habitual), el B en la hora 8 (versus hora 21), y el C en la hora 12 (versus hora 23).

Se que el ejemplo es bien simple, y que en el día a día trabajamos con tareas y proyectos mas complejos, con interdependencias, y con muchas distracciones que nos distancian de este mundo ideal planteado. Pero ver las cosas de esta manera nos permite acercarnos a una primer aproximación de como mejorar la forma en que hacemos las cosas.

Una buena forma de poner en práctica esta forma de trabajo es seguir los principios de Kanban en nuestro día a día. Lo bueno es que no requiere cambiar de procesos ni estructura. Podemos seguir organizados y trabajando con el mismo proceso, pero debemos hacerlo diferente.

Kanban

Kanban es una derivación de dos palabras japonesas: Kan - visual, y ban - tarjeta, lo que significaría algo como "tarjeta visual" o "visualización a través de tarjetas". Es un enfoque de trabajo basado en principios básicos, que busca asegurar un flujo continuo de actividades, y que las que se realicen primero sean realmente las mas importantes. Esto lo asegura siguiendo 5 principios simples:

1. Visualizar el flujo de trabajo, lo que asegura comprender el flujo y como funciona.
2. Limitar la cantidad de tarea en curso. Esto asegura que terminemos las tareas mas prioritarias, antes de comenzar con la siguiente tarea, limitando la cantidad de tareas en paralelo, reduciendo el context switch, lo que reduce los errores, el riesgo y los dolores de cabeza.
3. Gestionar el flujo, midiendo de manera simple, supervisando la ejecución y mejorando donde sea necesario.
4. Explicitar las políticas de proceso. Al visualizar como se trabaja, se hacen explícitos vicios ocultos o problemas no detectados, lo que es un disparador para la mejora.
5. Mejorar en forma continua y colaborativa. El proceso debe cambiar y evolucionar de manera continua, y evolucionar en forma constante.

Sobre como usarlo para arquitectura, ya lo dejo para otro post.

Leer mas

Que implica hablar de arquitectura IT en una empresa grande

Hace unas semanas tuve el placer de dar participar de Arqconf 2014, la primer conferencia de arquitectura de Argentina, organizada por un grupo de nerds en el cual me incluyo.
En mi presentación hablé sobre que significaba la arquitectura en una empresa grande. En este post voy a transcribir una parte de la presentación, sobre cuales son las cosas que impactan el pensar en arquitectura en una empresa grande.
No voy a hablar sobre la teoría económica que define que es una Pequeña, mediana o gran empresa por variables duras y aburridas que para lo que estoy intentando transmitir no viene al caso.
Voy a contar que es una gran empresa desde el punto de vista de IT (y mi punto de vista), y mas puntualmente desde un área de arquitectura de IT dentro de una gran empresa.

Para graficar y ayudarme a transmitir la idea, armé el siguiente gráfico, que tiene 4 áreas o ejes diferentes. 

Yendo en el sentido de las agujas del reloj, estos son:

• •Mercado: Todas las soluciones que hacemos desde IT la hacemos para alguien. Estas cuestiones se refieren a quien o quienes están apuntadas las soluciones IT que desarrollamos y mantenemos.

• •Tecnología: agrupa todos los conceptos relacionados a las tecnologías disponibles para crear soluciones IT, o sea con que herramientas técnicas contamos para poder pensar las soluciones que creamos.

• •Negocio: Trabajamos para crear soluciones que soporten un negocio, cualquiera que sea. Este grupo categoriza las cuestiones relacionadas al negocio, que tenemos que tener en cuenta desde IT.

• •Política: Las empresas funcionan en un entorno político interno y externo que nos golpea directamente a la hora de pensar en arquitectura en una gran empresa. 

Cualquier empresa no funciona sola, sino que también se ve impactada por cuestiones externas. Por ese motivo cada cuadro representando a cada una de las categorías tiene un cuadro en su interior. ] El cuadro mas interno tiene en cuenta los aspectos internos de la empresa, mientras que el externo las cuestiones fuera de la empresa.

Veamos cuales son las cosas que nos impactan en el desarrollo de soluciones IT en una gran empresa:

Mercado

Estamos hablando de empresas que tienen decenas de miles de empleados. Y no solo eso, sino que en empresas altamente dependientes de las tecnologías, como las empresas de servicios, la gran mayoría de esos empleados son usuarios periódicos de los sistemas que desarrollamos. 

Para no dejarla tan simple, estos miles de usuarios internos no piensan todos iguales, tienen diferentes grados de preparación y realizan diferentes tareas, por lo que existe mucha diversidad cultural.

Esto se acrecienta cuando vemos afuera de la organización. En empresas de servicios o ya cada vez mas en todos los rubros, cuando hablamos de gran empresa estamos hablando de compañías con millones de clientes, en algunos casos siendo estos usuarios activos y constantes de las soluciones IT que mantenemos. 

Piensen en una empresa de telefonía, cada vez que ustedes llaman por teléfono, cada bit que consumen de internet, eso repercute en alguna solución IT de la empresa que les provee este servicio. 

Es mucho! Y, obviamente, como estamos hablando de personas, y de millones, hay diferencias culturales importantes, que debemos tener en cuenta.

Tecnología

En general se da que las grandes empresas fueron creciendo a partir de soluciones mas simples, integrándose con otras compañías o desprendiéndose de otras unidades de negocio, lo que lleva a que el ecosistema IT este formado por una diversidad de aplicaciones “legadas” enorme (varios cientos de soluciones IT) que integradas brindan el servicio a los usuarios. Sería muy simple si estas soluciones estuvieran desarrolladas en la misma tecnología. Lamentablemente no es así, por lo que en las grandes empresas se pueden ver casi todas las tecnologías disponibles, a modo de un museo tecnológico en vivo.

A la hora de pensar soluciones nuevas, es necesario tener en cuenta no solo la diversidad tecnológica, sino también cuales son los perfiles disponibles en la empresa y afuera de la misma (no sea cosa que la tecnología que decidamos sea la mejor, pero que para poder implementarla debamos contratar a un grupo de 4 locos que inventaron la tecnología que queremos implementar, a los cuales no les interesa trabajar con nosotros).

También hay que tener en cuenta las tendencias de la industria, para poder validar que la solución que planteamos tenga vida en el tiempo (tengamos en cuenta que las grandes empresas les gusta juntar aplicaciones, es su hobbie).

Negocio

Hacemos soluciones IT para soportar un negocio. Las áreas internas nos piden soportar nuevos productos, nuevos mercados y mas clientes, para poder hacer frente a la competencia y seguir las tendencias del mercado. Es muy importante tener esto en cuenta e intentar adelantarnos.

Es necesario conocer la industria para la que trabajamos, las tendencias en la misma, y entender como las mismas nos impactan en las soluciones IT que creamos y gestionamos. 

Una de las misiones principales de un equipo de arquitectura en una gran empresa es adelantarse a los requerimientos internos, interpretando de antemano lo que pueda pasar y pensando las soluciones para poder soportar los requerimientos venideros. Es algo parecido a futurología o magia negra a veces, pero es también algo muy desafiante y divertido al mismo tiempo.

Política

Las empresas en cierto aspecto son entidades muy políticas, y cuanto mas grande es la empresa, mayor es su política interna. Es inevitable, por eso debemos tenerla en cuenta, comprender las restricciones que puedan existir, y lidiar con ellas.

Las empresas no funcionan solas, sino que se deben regir por las normativas del país o países donde funcionen, y la economía de los mismos. También debemos comprender como estas cuestiones impactan en el mundo IT.

Concluyendo...

Las empresas grandes son entidades muy complejas desde lo estructural, lo que lleva muchas veces a que la interrelación, comunicación y trabajo en conjunto para crear soluciones sea algo muy complicado. Así, en ese contexto, como dicta la ley de Conway, “Las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones.”. Yo iria un poco mas allá, y diría que las soluciones IT diseñadas por una empresa es fiel reflejo no solo de sus estructuras de comunicación, sino también de su historia, sus restricciones y políticas. 

Una de nuestras principales misiones como arquitectos es lidiar con estas cuestiones, para:

• Convertirnos en el nexo entre diferentes áreas y mejorar la comunicación, luchando contra la ley de Conway

• Conocer las restricciones, pero no vencernos ante ellas

• Conocer la historia y razones que llevaron a la situación actual, pero para poder cambiar el rumbo

• Conocer la política de la compañía, para usarla en favor de crear mejores soluciones.

Leer mas

¿Cual es el tamaño ideal de un equipo de arquitectura empresarial?

Según estuve leyendo en Gartner, establecen que según sus investigaciones el tamaño ideal de un equipo de arquitectura empresarial va inicialmente entre un 2% y un 4% del número total de personas que forman parte del área de IT de una empresa. No me cierra de esa frase que supone que Enterprise Architecture es solo IT, cuando tiene una gran relación con la tecnología, eso es cierto, pero también tiene mucho de estrategia y conocimiento del negocio.

No creo que se pueda establecer una relación tan clara y fuerte entre el tamaño de un equipo de EA y el área de IT, en primer lugar por lo antedicho, y en segunda instancia porque es necesario tener en cuenta muchas variables que son propias de cada organización, entre las que se me ocurren:

• El alcance que el área de EA tiene en la organización, ya que no es lo mismo un área que solo se encargue de definir la estrategia de la arquitectura aplicativa, que aquella que tenga dentro de sus funciones la definición de la estrategia de negocio, la arquitectura tecnológica y aplicativa y la definición de tendencias del mercado.
• El nivel de madurez de la organización, ya que si la organización ejerce una planificación estratégica ordenada, se requiere menos esfuerzo de arquitectura para llevarla adelante.
• El presupuesto alocado por la organización para las iniciativas de arquitectura hará crecer o decrecer la cantidad de personas que formen el grupo de EA.
• La madurez en la gestión de los proyectos, y la facilidad para hacer que cada proyecto tenga dependencia de las definiciones de EA definirá el nivel de esfuerzo requerido, y por ende la carga de trabajo que hará aumentar o decrecer al equipo.

Es necesario tener en cuenta muchas cuestiones para definir el tamaño del equipo, y no creo que exista una receta para definirlo. Pero creo que un buen comienzo es la definición de las actividades que realizará el equipo de arquitectura, los entregables que brindará y el nivel de servicio que se espera dar al resto de la organización. En base a esto, sumado a la cantidad de proyectos en ejecución y planificados y el nivel de participación, la tarea de definir el tamaño y capacidad de un equipo de arquitectura no es muy distante a la definición de un equipo para un proyecto cualquiera.

Leer mas

Organización de un equipo de EA

Una buena manera de establecer la organización de un equipo de arquitectura empresarial es tener en cuenta las funciones que debe cumplir el área, el valor que dicha función le brindará a la empresa, y la relación con los procesos de la empresa (como el ciclo de vida de desarrollo o el proceso de planificación estratégica).

Según lo veo, las funciones que cumple un área de arquitectura empresarial se pueden resumir en las siguientes:

• Definición, que cubre la creación y establecimiento de políticas, estándares y guías base, que son el entregable para ordenar la estrategia de arquitectura de los diferentes proyectos de la organización.
• Control, asegurando que los proyectos cumplan las políticas, estándares y guías base, y detectando la necesidad de cambio de dichos entregables definidos (ya que los mismos deben evolucionar y no quedar estancos). Esta función debe entregar un reporte del cumplimiento, excepciones o evoluciones necesarias.
• Acompañamiento de los diferentes proyectos, cumpliendo la función de consultor en cualquier etapa de los proyectos IT, y guiando sobre el cumplimiento de las políticas, estándares y guias base establecidas. Obtiene también información de los proyectos como retroalimentación al repositorio de información de arquitectura y a la planificación arquitectural. No solo se participa como un consultor que aporta conocimientos técnicos, sino también de estrategia y de negocio.
• Transferencia de conocimiento a todos los stakeholders de la organización o a quien requiera contar con los conocimientos generados por el área de arquitectura. Estos conocimientos no solo están relacionados a lo definido por la función de definición, sino también a lo que al área de EA conozca por su participación en todos los proyectos o la investigación sobre tendencias.
• Investigación, que es una función mas que importante, ya que sienta las bases de los conocimientos necesarios para permitir una evolución constante de la arquitectura para brindar siempre el valor requerido.
• Velar por que los activos generados por arquitectura (relacionados a arquitectura aplicativa, arquitectura de datos, arquitectura técnica, etc.) se encuentren actualizados y sirvan para la función que fueron creados, representar el cúmulo de información necesario para conocer el estado actual y establecer el estado futuro de la arquitectura.

Luego, es necesario mapear cada una de estas funciones a los procesos organizacionales, determinando claramente el valor que la función de EA le brindará a la o las etapas relacionadas. De esa forma, se comunicará claramente a los stakeholders el valor brindado (también es importante encontrar la forma de medir el retorno y el valor generado).

Teniendo estas funciones como base y el mapeo con los procesos organizacionales, se cuenta con una base para planificar la organización del equipo, establecer la cantidad de personas que deben formar el equipo de arquitectura, y comunicarlo a las personas adecuadas para la ejecución del plan de EA.

Leer mas

Intentando resolver los problemas de comunicación por email

Estoy convencido que los principales problemas en el día a día laboral, provienen de no saber comunicarse.

Y como una de las principales formas de comunicación a nivel corporativo es el email, la complicación es todavía mayor. ¿Porque? Creo que si existen problemas de comunicación interpersonal, se potencian cuando se plasman en escrito. Propongo algunos tips para poder evitar dichos inconvenientes. Muchas de estas cosas pueden parecer obvias o tontas, pero seguro si pensamos nos vamos a acordar de mails que no cumplian con dichos items.

Reglas básicas

Identificación: Es necesario que en el mail este identificado bien el remitente del mismo, y a quien esta dirigido. Una buena práctica es comenzar el mail con el o los nombres de los destinatarios, y firmar el mail al final.

¿De que estas hablando?: Personalmente, me molesta cuando los mails no tienen un subject relacionado al cuerpo del mismo. Es odioso. Es imprescindible, primero, poner un título a los mails, y que el mismo tenga relación con el contenido. Nada de "Hola", o "Eso que me pediste".

No gritar: No escribir todo el mail con mayúsculas. Queda muy chocante, y es complicado de leer. Utilizar este recurso solo cuando sea necesario, y para resaltar una parte muy acotada del texto.

Look & Feel: Que los mails sean agradable de leer. El hecho de no utilizar párrafos, o escribir todo en una misma línea, hace que se ahorre espacio (nada), pero hace ilegible el mensaje. Es útil dejar una linea en blanco entre párrafos (primero, usar párrafos), no escribir frases muy largas, y revisar ortografía y gramática.

No demorar la respuesta: La incertidumbre predispone de mala forma a la gente. Responder el mail lo mas rápido que se pueda, al menos para hacer saber que en un tiempo se le dará una respuesta mas concreta.

Practicar Yoga antes de responder: Cuando se reciba un email chocante, hiriente o que nos moleste por x motivo, no contestarlo en forma inmediata. Tomarse un tiempo necesario para enfriar el tema, y responder cuando nos encontremos tranquilos. Empeoraremos las cosas de otro modo.

No pedir confirmación automática de lectura: Pone en una situación incómoda al receptor. O hace pensar que no leyó el mensaje, o brinda información que tal vez no se quiera dar.

Longitud correcta: No escribir correos interminables, ni muy cortos que no digan nada. Una buena práctica puede ser releer el mail antes de enviarlo. O ponerlo a prueba en un grupo reducido (el grupo de trabajo mas cercano). Si es necesario enviar mucha información, es mejor escribir el detalle en un documento -que se adjunte, o en una wiki o blog, que se linkee.

Ordenar por importancia: Casi nadie lee los mails en forma completa. Aprovechémonos de la costumbre, y hagamos que el primer párrafo sea un resumen ejecutivo del resto del mail.

Ser cordial: Esto será muy obvio, pero es muy útil. Detalles como llamar al receptor por su nombre, o saludar al principio y final del mail, son tips que ayudan mucho. Sumado a escribir en forma amistosa y generosa o colaborativa, y no atacar a las personas, sino a las posiciones, casi asegura el éxito.

Aplicar reglas básicas de comunicación: Temas como el parafraseo para comprender, o no guardarse puntos por mas obvios que parezcan (no todos conocen lo mismo que uno), son reglas que ya se dan como aplicadas, y muy útiles.

No reenviar a los reenviados: Antes de reenviar un mail, corroborar quienes lo recibieron, para no generar mails repetidos en la casilla de nadie.

Cuidar el lenguaje: No utilizar lenguaje grotesco ni hiriente en los mails. Recordemos que quedan guardados!

Ser imparcial: No escribir el mail desde una posición de absoluto conocimiento, sino bajar a la tierra el concepto buscando que le otro no creo que estamos transmitiendo estar encima de otro. Usar palabras como: creo que, considero que, me parece que, entiendo que, según mi punto de vista, desde mi perspectiva.

Reglas básicas de redacción

Algunos tips básicos de redacción, útiles para tener en cuenta. Conocer estos elementos es interesante, mas que nada para no repetir conectores y no aburrir:

ELEMENTOS DE ENLACE: Son partículas o expresiones que ayudan a lograr la continuidad en el enlace de ideas dentro de los párrafos, o para relacionar unos con otros. Estas son:

• Las que indican sucesión de la misma idea: al principio, en segundo lugar, a continuación, por último.
• Las que indican limitación: pero, no obstante, con todo, sin embargo.
• Las que indican exclusión: por el contrario, antes bien.
• Las que indican concesión (derecho a ): aunque, si bien, es cierto que.
• Las que indican distribución: bien (unos)... bien (otros).
• Las que indican consecuencia: por lo tanto, pues, luego, por consiguiente.
• Las que indican continuidad: pues bien, ahora bien, además, por otra parte, como decíamos.

CONECTORES: Relacionan conceptos mostrando un efecto de relación particular entre los mismos:

• ADICION Y, también, además, más, aún, por otra parte, sobre todo, otro aspecto.
• OPOSICION Pero, sin embargo, por el contrario, aunque, no obstante.
• CAUSA EFECTO Porque, por consiguiente, por esta razón, puesto que, por lo tanto, de modo que, por eso, en consecuencia, esto indica.
• TIEMPO Después, más tarde, antes, seguidamente entre tanto, posteriormente, ahora, luego.
• AMPLIACION Por ejemplo, en otras palabras, es decir.
• COMPARACION Tanto como, del mismo modo, igualmente, de la misma manera, así mismo, de igual modo.
• ENFASIS Sobre todo, ciertamente, lo que es peor.
• RESUMEN O FINALIZACIONFinalmente, en suma, en conclusión, par terminar, para conclusión, etc.
• ORDENPrimero, segundo, siguiente, luego, a continuación, seguidamente, en primer lugar, por último, aún, al final, al principio, al inicio, pronto.
• REAFIRMACIONCon todo, decididamente, en efecto, en realidad, decisivamente, a pesar de todo, de todos modos, justamente.
• CONTRASTEPor otra parte, en cambio, por el contrario, de otra manera, por otro lado.
• CONDICIONSi, supongamos, supuesto que, siempre que, dado que.
• EJEMPLOSTal como, como caso típico, en representación de, como muestra, verbigracia, por ejemplo.

Principalmente, no olvidemos que del otro lado hay PERSONAS

Leer mas

Cambiando el enfoque de la arquitectura empresarial

Cursando la MGSTT, en UDESA, me pregunté como los conceptos de negocios que estaba adquiriendo podían ayudar a la mejora de la estrategia de arquitectura empresarial. Leyendo la nota de InfoQ sobre el mismo tema, me di cuenta que es factible aplicar los conceptos (algunos, no todos) para mejorar el alineamiento entre EA y el negocio. Algunos:

• Porter: No creo que ver las cinco fuerzas puede ayudar a mejorar la forma en que la EA soporta los requerimientos del negocio (aunque nunca esta de mas ver que esta haciendo la competencia), pero el diamante de competitividad seguro dará una visibilidad sobre las capacidades estratégicas de la empresa, y mapear eso hacia los activos de arquitectura podría ser muy útil. Por otro lado, el diamante de competitividad permite ver que hace falta para seguir en el mercado, lo que permite ver a que debe adaptarse la arquitectura.
  
• Métricas: Es importante que la EA sea medible y medida, publicando las resultados para ser conocidos por toda la empresa, y asi ganar apoyo. Algunos ejemplos de métricas de EA que sería util mostrar para demostrar la alineación EA-Negocio: Reutilización de activos de EA (lo que redunda en mejora en el time to market), % adopción a arquitectura de datos por los sistemas (lo que redunda en menor acoplamiento, por ende mas adaptabilidad), % de adopción de estándares de integración, tiempo de implementación de proyectos EA compliance VS non EA compliance.
• Modelar en base al negocio. La velocidad con la que cambia el negocio, y la lentitud que IT tiene para adaptarse, hace que la EA deba adelantarse a los requerimientos. Lo que la EA debe hacer es tener la capacidad de visualizar la estrategia de negocio, tal vez observando que es lo que pasa en otros mercados (por ejemplo, en telecomunicaciones ver los mercados europeos o brasilero es bueno para ver que puede llegar a pasar en uno o dos años en Argentina), y mapear los futuros requeriemientos utilizando una estrategia de modelado orientada al negocio, como la que se nombra en BusinessModelAlchemist.
• Finanzas. La EA debe tener en cuenta como las soluciones serán soportadas por el presupuesto asignado. Tener conocimientos básicos de manejo de finanzas es importante para soportar la EA. Conocer los flujos de fondos, o la gestión de un presupuesto o forecast sirve para que las soluciones propuestas sean "vendidas" al negocio.
• Negociación+Coaching. La negociación es otro punto importante a la hora de establacer una EA, para poder llevar a cabo la estrategia IT definida para dar soporte al negocio. Todo, sumado a un coaching activo en las áreas de IT.
  

Como se ve en los puntos anteriores, el enfoque propuesto para la nueva EA tiene poco que ver con aspectos técnicos, sino que tiene mucho que ver con aspectos de negocio, entendiendo como funciona la empresa donde se desea establecer una estrategia de EA, para ver como definir el camino a seguir. Es por eso que concuerdo con la nota de InfoQ, y veo que los frameworks existentes para EA se quedan cortos con el soporte que se necesita. Van solo a como se mapean los activos de negocio contra los activos IT, pero no a como alinear la arquitectura al negocio. Es necesario "ablandar" la arquitectura empresarial para que sea un éxito.

Leer mas

Estrategias y principios de EA

Hace unos días me entretuve leyendo el artículo "16 Enterprise Architecture Strategies Learned The Hard Way", que habla sobre que hay que tener en cuenta para definir y establecer una arquitectura empresarial. A continuación voy a plasmar mi parecer a cada uno de lso puntos, según mi experiencia. Intentaré no ser muy exhaustivo con cada item, de otra forma haré demasiado largo el post. Pero que da claro que cada uno de las estrategias planteadas generan una discusión bastante grande.

1. Es virtualmente imposible crear un blueprint exhaustivo de toda la empresa. Concuerdo en parte con este dicho. Creo que es muy dificil llevar a cabo una definición detallada de la arquitectura de una empresa, y si uno quiere hacerlo como primer paso para establecer una arquitectura empresarial, se esta introduciendo en una tarea que demandará mucho tiempo y esfuerzo, y cuando termine, ya estará desactualizada. Es necesario tener una metodología de creación contínuo del blueprint, que vaya enriqueciendose y creciendo poco a poco, a medida que el equipo de EA trabaja a la par de los proyectos.

2. La mejor estrategia mezcla un blueprint centrado en la empresa, con blueprints de dominio y de unidades de negocio. Como dije en el punto anterior, para crear el blueprint general, es necesario tener una estrategia que haga crecer gradualmente a los registros de activos y sus relaciones. No llevando a cabo un proyecto salomónico que nunca termine. Una buena estrategia, podría ser comenzar por unidades de negocio o dominio, para luego interrelacionarlos. Prefiero trabajar a la par de los proyectos.

3. Llevar a cabo la contabilidad de EA de manera centralizada es un factor de éxito. Estoy de acuerdo con esta afirmación, pero creo sumamente difícil que esto suceda. En lo que respecta a catalogación de activos, evaluación y seguimiento, creo que es imprescindible llevarlo a cabo en forma centralizada desde EA, pero el seguimiento de budget para llevar a cabo la estrategia, si bien es importante y ayuda a eliminar muchas trabas, es complicado a nivel organizacional.

4. Es crítica la existencia de un grupo central de EA, guiando con estándares y prácticas. Esto es fundamental. Pero la sola existencia no hace nada. Si el grupo de EA solo se dedica a generar estándares y prácticas, se convierte en un grupo de documentadores teóricos muy lindos. Es necesario que esas prácticas y estándares se relacionen con los proyectos, trabajando en conjunto y generando un circulo virtuoso entre EA y grupos de desarrollo.

5. Los arquitectos deben ser asignados a proyectos como "miembros core" 100 % de acuerdo. Es la mejor manera de que los arquitectos salgan del marco teórico definido, y se fogueen con el día a dia. Por otro lado, demuestran el valor de su trabajo al resto de la compañía. Es necesario, para lograr esto, que el grupo de EA tenga los suficientes integrantes como para afrontar la carga que esto supone.

6. EA debe medirse de dos formas: la capacidades de negocio entregadas, y los costos de los servicios. Debido a la forma en que trabaja un grupo de EA, es casi imposible generar métricas que demuestren su éxito. Una buena estrategia, es medir las capacidades de negocio brindadas como fruto del grupo de EA (o sea, medir el éxito de los proyectos en que participo EA), y por otro lado los costos asociados al grupo de EA, para obtener el rendimiento total, y demostrar el valor monetario del trabajo realizado.

7. Medir a la EA como un activo. No estoy tan de acuerdo. Al verlo como un activo, se esta comparando al grupo de EA con una máquina que tiene datos de entrada, y produce una salida, comparando solo el costo y el producto de dicho activo. Es mas profunda la medida, y tiene que tenerse en cuenta los factores limitantes de las definiciones: restricciones de tiempos, costos, restricciones técnicas etc, que limitan el éxito del trabajo de EA.

8. Para tener liderazgo en la arquitectura, es necesario tener capacidad de management, negocio y técnicos. Agregaría que es mas importante el primero y segundo que el tercero. Generalmente, el equipo de EA se encarga de mediar entre diferentes posturas, y muchas veces trabaja como un negociador o facilitador para destrabar proyectos. Pero es cierto que tienen que tener profundos conocimientos técnicos, en base a experiencias anteriores en el mejor caso. Pero sin saber como comunicarlos o transmitirlos, los conocimientos técnicos no sirven para un arquitecto.

9. Los métodos y el governance debe ser integrado al proceso actual. Si en lugar de integrarlo al proceso de trabajo actual, se crea un proceso paralelo, se dificultará la implementación, hasta hacerla imposible. Es necesario integrar las prácticas de EA al ciclo de trabajo existente, a nivel gestión de proyectos, generación de presupuestos, manejo de requerimientos IT, y formular y llevar a cabo modificaciones, en caso de ser necesarias.

10. No siempre el nombre Arquitectura Empresarial es el mejor para comunicar la función: Tal vez Planeamiento y estrategia, o Transformación empresarial es mejor. Me gusta Planeamiento y estrategia, creo que muestra lo que realiza EA, pero deja afuera aspectos técnicos. Transformación empresarial pone demasiado peso sobre el grupo de EA, pero le da la facultad de modificar la estructura organizacional, muchas veces necesario. Creo que se debe llamar Arquitectura Empresarial, pero comunicando claramente el objetivo y funciones del equipo de trbajo.

11. Las mejores empresas tienen equipos de "arquitectura de negocio" reportando al negocio, o a este e IT al mismo tiempo. Podría ser una buena decisión hacerlo depender de IT y el negocio al grupo de arquitectura, o crear un grupo de arquitectura de negocios, que modele la estrategia de negocios y trabaje muy cerca del grupo de EA, hasta como un departamento de este, para definir como esa estrategia de negocio se mapea contra las plataformas IT.

12. Las empresas líderes tienen arquitecturas de referencia para el 90% de los dominios técnicos. Es necesario contar con modelos de referencias para diferentes tecnologías y dominios técnicos, que brinden información de soporte para la implementación correcta de los proyectos, que encajen dentro del blueprint definido a nivel general. Estas arquitecturas deben definirse teniendo en cuenta los atributos de calidad y requerimientos funcionales que deben cumplirse dentro del dominio, para que puedan ser aplicados en forma exitosa.

13. Los EA seniors deben tener los skills culturales correctos y la conciencia para integrar a los socios de negocio y los referentes técnicos. Volviendo la punto 8, las habilidades blandas son muy importantes para un arquitecto empresarial. Deben poder ser el nexo entre el mundo de negocio y el mundo IT puros, y entenderse con ambos. Es necesario explotar y hacer crecer las capacidades de comunicación, negociación, coaching y liderazgo.

14. Los grupos de mayor performance mantienen un involucramiento consistente de EA en el ciclo de desarrollo, para trasladar los blueprints en la arquitectura inicial de cada proyecto, y para asegurar la estimación de costos y recursos. Relacionado al punto 9, el grupo de EA debe estar involucrados activamente en el ciclo de vida de los proyectos de desarrollo, instaurando sus políticas o prácticas para que sean llevadas a cabo dentro de cada proyecto, alineandose con la arquitectura macro definida.

15. Las organizaciones maduras destinan un 40% del tiempo de EA para planeamiento estratégico, y un 60% para participar en el ciclo de vida de proyectos. Según lo veo yo, la tarea del grupo de EA debe estar dividida en partes iguales, entre el planeamiento y la participación en los proyectos. Ya que existen momentos donde se planifica totalmente, y no se participa de ningún proyecto, pero en la participación del ciclo de desarrollo, no se realizan puramente tareas relacionadas al mismo, sino que se planifica como llevar a buen puerto el proyecto o desarrollo en cuestión, teniendo en cuenta lo planificado. Se puede decir que el arquitecto empresarias siempre tiene que estar planificando, mirando a mediano o largo plazo, y midiendo sus decisiones en base a eso.

16. La obtención de credibilidad y confianza entre el negocio e IT es un prodictor del exito de EA. Este es un tema fundamental. La credibilidad y confianza que el negocio e IT tienen de EA se va ganando paso a paso, proyecto a proyecto, mostrando resultados. No hay otra manera. No se puede imponer una arquitectura, se debe vender y demostrar su validez. Este es el punto fundamental del éxito de una EA. Si no se gana la confianza de las áreas de una empresa, la iniciativa esta destinada al fracaso tarde o temprano.

Leer mas

Enterprise Architecture Training - Dia 2

El día de ayer asisti a la segunda clase del curso de Arquitectura Empresarial. Esta vez, trató sobre arquitectura de negocios.

La clase estuvo dividida en dos partes, la primera orientada directamente a la arquitectura de negocios, o como un arquitecto tiene que estar orientado o siguiendo siempre la estrategia de la empresa, y otra parte enfocada a la arquitectura de datos.

Arquitectura Empresarial
Se puede definir como "Un blueprint formal de estructuras de gobierno, semánticas de negocio y cadenas de valor a través de toda una empresa".

Existen diferentes disciplinas dentro de una arquitectura de negocios. Estas son:

• Visualización: Describir la arquitectura de negocio. Es crear vistas que permitan de una forma simple entender la arqutiectura de negocio.
• Agregación: Unir diferentes vistas para facilitar el reconocimiento de comportamientos, entender redundancias e inconsistencias
• Alineamiento: Transformación del negocio y IT, por fases, para que IT sea un facilitador de la estragiar, y el negocio vaya guiando a IT en la implementación de facilidades.

El negocio y IT deben estar alineados, definiendo como alineamiento a:

• Estado en el cual las estructuras de gobierno, semánticas de negocio y reglas interactuan en armonía con los sistemas automatizados y datos.
• El alineamiento de la arquitectura es un camino por recorrer, no es un objetivo a alcanzar. Es algo que se debe buscar en forma continua
• Requiere la creación de un entorno que facilite la alineación continua, asi como la sincronización, entre el negocio y la arquitectura.

Estrategias de negocio y tecnológicas
Con el fin de conocer, analizar, y documentar la visión del negocio y porque no, de la arquitectura, tenemos diferentes estratégias o herramientas:

• Las 5 fuerzas de Porter
  
• La rueda cuadrada de Benson y Parker
• Roadmap de tecnología, que busca alinear el roadmap tecnológico con la estrategia del negocio
• Nuevas formas de ver al negocio: Tecnologías disruptivas, The long tail (o el nuevo Pareto), Diferenciación retrazada y diferenciación extrema.

Ciclo de vida de las entidades
Algo que me pareció muy bueno, fue este tema del ciclo de vida de las entidades. Este concepto lo creo Michael Jackson (no el de los guantes, sino el guru del sw), en los 70s. Lo que hizo fue crear una forma de describir los estados de una entidad desde su nacimiento, hasta la muerte de la misma. Esta entidad puede ser un producto, cliente, o lo que sea.


Cadena de valor de Porter
Una buena forma de definir o mostrar las areas que dan valor a un determinado producto, en una empresa, es la cadena de valor de porter. Lo que hace es definir los diferentes sectores de la empresa que van agregando valor a un determinado producto o servicio, de manera de identificar aquellos pasos que pueden mejorarse, agregarse, o eliminarse.
Ahi me pregunte, ¿es solo para una empresa, o podemos hacerlo nosotros para el area de arquitectura?

Rummler - Brache Enterprise System Model
Este modelo muestra a la empresa como una caja negra, con entradas y salidas. Las salidas son los productos o servicios que genera, a la que se le pueden aplicar metricas (como six sigma), para obtener una realimentación de lo producido. Estos servicios o productos son adquiridos o utilizados por clientes, que también nos dan un feedback. Dichos feedbacks tienen que ser utilizados para aplicar mejoras al proceso, dentro de la caja negra.
¿Podría aplicarse esto a un area de arquitectura, que da servicios a otras areas? Creo que si.

Arquitectura de datos
Después de habernos sentido como que estabamos en una clase de marketing (y teniendo regresiones de una semana que tuve el año pasado, investigando sobre marketing para una presentación), pasamos a un tema mas técnico, como la arquitectura de datos.
Se ve que este tema no le gustaba mucho a Mike, porque lo paso mas o menos de largo.

Principios de la información de negocios

• La información es la base para el éxito del negocio
• La información es un activo estratégico
• El dueño de la información es el negocio
• La información debe ser transparente y clara a todos los participantes interesados
• La semántica debe ser la misma en toda la empresa.

La arquitectura de la información

• Se trata de generación de vistas de la información empresarial
• Se debe distinguir entre la información operacional y la informacional, o de análisis.
• La arquitectura de datos esta basada en la arquitectura de negocios
• Es una herramienta que permite la implementación de estrategias de negocio y tecnológicas uniformes.

¿De donde vienen los modelos de datos?

• Los elementos clave en todos los buenos modelos de datos provienen de los modelos de negocio
• Cuanto mejores sean los modelos o requerimientos del negocio, mas facil es crear buenos modelos de datos
• Los modelos de datos simples toman mucho trabajo, es ucho mas facil producir modelos complejos (se debe pensar mas para simplificar los modelos).

Hasta aca, lo mas importante del segundo día.

Leer mas

Enterprise Architecture Training - Clase 1

Hoy asisti a la primera de cuatro clases de Enterprise Architecture, cuyo orador es [Mike Rosen]

A continuación les dejo los puntos que mas me quedaron de este dia:

Comenzo hablando de para que es necesaria una arquitectura (complejidad del negocio y la tecnología, requerimientos de una semántica uniforme a toda la empresa, relacionar todos los activos implicados en el desarrollo de las soluciones, ...), y siguió definiendo que es una arquitectura. La definió de la siguiente manera:

• "El diseño y especificación de la estructura de un sistema completo" David Garlan and Mary Shaw
• "El concepto de mas alto nivel de un sistema en su entorno" IEEE
• "La organización o estructura de los componentes significativos de los sistemas, interactuando a través de interfaces" RUP
  

Personalmente, no me cerró ninguna completamente.

Yendo al tema en cuestión del curso, Arquitectura Empresarial, se la definió como el entendimiento de todos los elementos que forman la empresa (personas, procesos, sistemas), y las decisiones necesarias para que estos elementos se relacionen de una forma tal que acompañen la estrategia empresarial.

La arquitectura debe responder las tres principales cuestiones:

1. ¿Cuales son los conceptos importantes?
2. ¿Cuales son las relaciones entre los mismos?
3. ¿Como provee valor al negocio?

Objetivos de la arquitectura Empresarial

1. Interoperabilidad entre sistemas
2. Tecnología consistente
3. Dar un maximo beneficio al negocio mediante el apropiado reuso de la tecnología
4. Tecnología cost-effective, mediante la centralización de principios, políticas, estándares, y productos aprobados.

Repositorio

Es importante para una arquitectura empresarial, la existencia de un repositorio de activos de IT, entre los que se encuentran:

Activos de negocio

• Estrategia de arquitectura
• Organización del area de arquitectura
• Productos de la empresa
• Cadenas de valor de la empresa y arquitectura

Activos de solución

• Procesos de negocio
• Definición de la información
• Diseño de Software
• Catalogo de servicios

Activos IT

• Aplicaciones
• Productos IT
• Plataformas SW
• Hardware

Activos de arquitectura

• Metamodelos
• Arquitecturas de referencia

Architecture-Driven Design Process

Resumiendo, lo que dice este proceso o metodología de desarrollo es, en primera instancia, pensar el sistema totalmente agnóstico de tecnologías, basandose en los requerimientos del negocio (Arquitectura de Negocio).

Una vez definida la arquitectura agnóstica, decidir cual es la tecnología a implementar, y definir la arquitectura propia basada en la tecnología.

De esta manera, ganamos:

• Flexibilidad de la arquitectura
• No atar las decisiones de arquitectura a cuestiones propias de una tecnología
• Maximizar la reutilización de componentes

Principios de arquitectura

Los principios que guían a una arquitectura, son:

• Separación de incumbencias
• Tener el cuenta el futuro (versiones de productos, estrategias de la empresa, nuevas tecnologías)
• Ser riguroso en las definiciones
• Enfocarse en la comunicación
• Buscar el desarrollo de aplicaciones en forma consistente y efectiva
• Buscar una implementación de los cambios por fases

Definición del área de arquitectura
Un punto que me intereso, fue como ve Rosen los pasos para establecer un grupo de arquitectura empresarial. Estos pasos son:

1. Establecer un plan de implementación por fases (seleccionando los proyectos menos criticos pero mas visibles al principio, y luego buscar reutilizar lo maximo)
2. Definir la estructura y staff del equipo (teniendo en cuenta tamaño de la empresa, y tipos de arquitectura)
3. Definir interacciones con otros grupos de trabajo, y de que manera se va a realizar.
4. Desarrollar estándares EA y arquitecturas de referencia
5. Crear, mantener y distribuir un repositorio EA
6. Capacitación, auditoría, consultoría, y mentoring dentro del grupo de EA y con el resto de IT
7. Definir e implementar métricas

Para mi, le falta un punto antes, que es establecer en que estado se encuentra la arquitectura, y definir una visión para el grupo y un objetivo al que quiero llegar.

Factores de éxito
Para terminar, les dejo 10 puntos que segun Rosen son factores críticos para el éxito de una arquitectura empresarial:

1. Enfocarse en los resultados. Permitir que los otros sean exitosos usando arquitectura. Remover las barreras entre los distintos grupos y EA.
2. Entregar un valor al negocio en forma continua
3. Implementar los cambios necesarios teniendo en cuenta toda la empresa (SOA, Enterprise Architecture)
4. Integrar modelos empresariales para soportar los servicios de negocio, procesos de negocio, y procesos de desarrollo
5. Implementar, recolectar y reportar métricas para demostrar valor
6. Usar un enfoque de implementación por fases, teniendo siempre en cuenta la visión de la arquitectura
7. Proveer una infraestructura que facilite la reutilización
8. Integrar el programa de arquitectura con los procesos de IT
9. Implementar una separación entre los procesos e información a nivel empresarial, de los datos y APIS de las aplicaciones
10. Evitar esquemas de financiamiento complicados

Prometo agregar mas detalle de cada punto, pero como resumen, creo que me pase de largo!

Leer mas