El camino a Oracle Certified Master, Java EE 5 Enterprise Architect

Hace poco completé los requisitos para obtener la certificación de arquitectura JEE. A continuación les comparto mi experiencia en la preparación y presentación de los exámenes. Tal vez les sea valioso a quienes vayan a iniciar el proceso.

Pre requisitos

Esta certificación no tiene dependencias con otras certificaciones. Es decir no tienes que ser Java programmer ni nada parecido para poder aspirar al titulo de arquitecto JEE, pero debes cumplir con una serie de requisitos antes de poder obtener el papel. Este es el camino.

El camino

1. Completar el entrenamiento: Desde que Oracle adquirió Sun, obtener esta certificación paso a ser algo costoso pues aún teniendo los conocimientos debes realizar un curso. Este curso aunque aparece como pre requisito de todos los otros pasos lo puedes hacer al final. Su objetivo básicamente es que realices la consignación de su valor para que te autoricen la generación papel.

2. Pasar el primer examen: El primer examen se debe realizar en un centro de evaluación (Yo lo hice en la facultad de minas de la universidad nacional en medellin). El examen esta compuesto por aproximadamente 70 preguntas de selección múltiple sobre arquitecura, patrones Gof, Jee y la plataforma.

3. Completar el "assignment": En este paso debes realizar el diseño de arquitectura de un caso de negocio que te entrega Oracle. Tienes 6 meses para completarlo y subir los diseños a la plataforma.

4 Completar el "essay": Una vez hayas completado el "assignment" debes agendar una nueva cita en el centro de evaluación. En este paso debes justificar el diseño de arquitectura que se subió previamente a la plataforma. Son aproximadamente 10 preguntas que le darán al evaluador mas criterios para calificar el diseño. El "assignment" y el "essay" conforman una sola calificación

5. Llenar el formulario: Una vez hayas completado todos los pasos debes llenar un formulario para iniciar el proceso de generación del certificado. Ademas debes llenar otro formulario para que se genere y envié la copia física.

¿Como prepararse para el primer examen?

A continuación les comparto mi plan de estudio y entrenamiento para enfrentarme a los requisitos de la certificación:

• Los libros son una ayuda valiosa en mi caso estos fueron los libros que utilicé como referente:
• Mark Cade; Simon Roberts. Sun Certified Enterprise Architect for J2EE™ Technology Study Guide. 1ª ed. Prentice Hall PTR, 2002.
• Paul R Allen; Joseph J Bambara. 
  SCEA Sun® Certified
  

  Enterprise Architect for 
  Java™ EE Study Guide
  . Mc Graw Hill, 2007.
• Mark Cade; Humphrey Sheil. Sun Certified Enterprise Architect for Java™ EE Study Guide. 2ª ed. Prentice Hall PTR, 2004.

• Las especificaciones. En mi caso estudié Java™ Platform, Enterprise Edition (Java EE) Specification, v5. 

• Complementa el contenido de los libros con conocimientos sobre: Patrones de diseño GOF, JEE, Corba, Jaas, JEE security model, JTA, JMS, Clustering, Load balancing, principios y conceptos de diseño, 

• Hacer muchos exámenes simulados. Podrías pagar por ellos pero en internet hay recursos gratis. Estas son algunas de las URL donde puedes encontrar información.
• http://www.javabeat.net/cert/scea/mock-exam/
• http://certification.about.com/od/certifications/l/blscea_q1.htm
• http://www.skill-guru.com/test/40/gof-design-pattern
• http://www.skill-guru.com/test/19/scbcd-mock-test
• http://www.skill-guru.com/test/147/j2ee-architect-certification-practice-test
• http://www.skill-guru.com/test/20/servlets-and-jsp-interview-questions
• http://www.skill-guru.com/test/46/jms-interview-questions
• http://sites.google.com/site/sureshdevang/scea-part-1-mock-questions-and-ans
• http://sites.google.com/site/sureshdevang/free-sun-certified-enterprise-architect-for-the-java-platform-enterprise-test

• Hacer los exámenes de los libros de estudio.

Es importante que en todo momento tengas claro el nivel en el que te encuentras para que sepas cuando estas preparado para presentar el examen (Pasas con un 68%). En mi caso hacia las simulaciones una y otra vez y mantenía estadísticas. Es importante que los exámenes los repitas en intervalos largos de tiempo para verificar si tu conocimiento es adquirido o simplemente es memoria de corto plazo.

Es importante también que realices planes de capacitación respecto a los temas en los que tienes falencias (Lo verás al realizar los exámenes simulados). Estudia aquellos temas en los que debes profundizar e inténtalo nuevamente. La gráfica de progreso probablemente mejorará en el tiempo conforme complementes tus conocimientos.

¿Como prepararse para el segundo y tercer examen?

Esto te lo dará la experiencia. Tienes 6 meses para realizar el diseño y justificarlo. Todo depende de tu habilidades para diseñar y documentar con UML. La calificación es con puntos y pasas con un mínimo de 114.

Finalmente llena el formulario y espera el certificado!!!!

Nota: Es recomendable que contactes un asesor Oracle para que guié por todos estos pasos y te apoye en la compra de los vouchers, cursos y cualquier otra duda que se te pueda presentar.

Métricas de valor

Introducción

Hace poco tuve la oportunidad de participar en una charla sobre métricas que midan el valor real generado por los equipos de desarrollo y que sean de utilidad para mantener el proyecto por el camino correcto. Entre los asistentes había gerentes de proyecto, analistas de calidad, diseñadores gráficos y desarrolladores. Arrancamos discutiendo cuales son las métricas que utilizamos o hemos utilizado en los proyectos. 

• Productividad de los desarrolladores: Cantidad de líneas de código escritas por unidad de tiempo, cantidad de puntos de historias completados…
• Cumplimiento de compromisos: Cantidad de compromisos realizados Vs compromisos cumplidos
• Indicadores de calidad: Cantidad de criterios de aceptación Vs Cantidad de Bugs, tasa de resolución de Bugs por unidad de tiempo…
• Indicadores que permitan medir el avance del proyecto: Valor ganado, Cantidad de historias de usuario completadas Vs cantidad total de historias…
• Generación de valor de negocio y clientes felices: ¿?

Fue curioso ver como los asistentes tenían muy clara la forma de medir la productividad, el cumplimiento de compromisos, la calidad, y el avance del proyecto, pero no tenían idea de cómo medir la generación de valor al negocio y la satisfacción de los usuarios finales. ¿Acaso esto no es lo único que realmente importa? 

De esta manera iniciamos un ciclo de discusiones en el que analizamos cada uno de los grupos de indicadores que teníamos sobre la mesa.

Productividad de los desarrolladores (¿Cuánto puedes hacer en 8.5 Horas nalga?)

La productividad individual aniquila cualquier intento de trabajo en equipo que se quiera promover dentro de una organización. Cuando alguien requiere ayuda para terminar su trabajo y pide colaboración a uno de sus compañeros, ¿Creen que este le va a ayudar poniendo en riesgo el cumplimiento de sus metas? Nadie querrá afectar sus indicadores individuales por ayudar a otro. 

Por otro lado podríamos medir la productividad de todo un equipo y de esta manera promover una cultura de trabajo cooperativo (Tal y como lo hacen las metodologías ágiles con sus gráficos de velocity y burn down chart) lo cual está bien. El problema con esto es que completar muchas funcionalidades de software no hará tu cliente más feliz.

Lo que realmente lo hará feliz es ver como lo que has hecho le permite reducir la operatividad de sus procesos de negocio o como ha podido incrementar sus clientes sin tener que contratar más personal. Y esto no se mide con la cantidad de story points completados por sprint. Va mucho más allá, requiere sentido de equipo, transciende el desarrollo mismo del software llevando a los equipos hacia el diseño de productos que habiliten nuevas capacidades en los negocios y no se limita a terminar el desarrollo de la funcionalidad, termina solo cuando aquello que construimos está siendo usado por nuestro cliente en producción y está generando el impacto que teníamos previsto.

Hoy quienes trabajamos con metodologías ágiles medimos las eficiencia de los equipos de desarrollo a partir de sus gráficos de velocidad, pero no vemos que muchas veces el product owner esta priorizando tareas (De forma similar a lo que hacíamos con los cronogramas) y no se está enfocando en pequeños impactos de negocio que se puedan poner en producción de forma rápida y que puedan ser usados tan pronto como sean liberados. 

Ahora, con lo planteado ¿Creen que las métricas de productividad son realmente de utilidad para determinar el logro de los objetivos del proyecto? Yo pienso que si son de utilidad para medir la capacidad de trabajo del equipo y ajustar los compromisos realizados de forma más realista pero no más que eso. 

La pregunta ahora es ¿Cuánto podemos lograr en un periodo de tiempo?

Cumplimiento de compromisos

Este es un tema bastante complejo. Por un lado es difícil cumplir en ambientes cambiantes y de mucha incertidumbre, pero es importante porque los seres humanos nos movemos a partir de compromisos (¿Quién no se pondría furioso si la compañía de telecomunicaciones no instala el servicio de internet el día y a la hora acordados?). 

Cuando incumplimos frecuentemente, generamos un ambiente de desconfianza en el cual es difícil desenvolverse.  De modo que  si podemos comprometernos hagámoslo y cumplamos, pero si nos sentimos indecisos, es mejor abstenerse.

En este orden de ideas, ¿Realmente tiene sentido tener indicadores de cumplimiento? Más allá de estos, debemos preocuparnos por nuestra credibilidad y mantenerla en alto. Si eventualmente no podemos cumplir comuniquemos de la mejor manera y negociemos en el momento justo.

Indicadores de calidad

¿Y qué es la calidad? Finalmente un producto es de calidad si satisface las necesidades y cumple con las expectativas de quien lo adquiere. En este orden de ideas depende de las personas que interactúan con él. Entonces ¿Tiene sentido decir que el producto tiene una calidad del 50%? 

Es claro que si el sistema tiene fallas tendremos que conocerlas priorizarlas e implementarlas porque de otra manera no podrá ser usado ni generar el impacto deseado en el negocio, pero ¿Qué sentido tiene manejarlos como Bugs?, ¿Por qué no manejarlos simplemente como cambios realizados al sistema de igual manera como se hace con las historias de usuario?.

Los Bugs solo promueven una cultura de culpables, debilitan el trabajo en equipo y hacen que pasemos largas horas justificando lo que pasó.

Esto no quiere decir que se admitan productos de mala calidad. Significa que tan pronto como se presenta el error, este se corrige al igual que el proceso para que no se vuelva a presentar. Nadie es perfecto y una cultura que penaliza los errores solo desmotiva y genera temor en las personas. Y el temor es el peor enemigo de la creatividad.

Indicadores que permitan medir el avance del proyecto

¿Realmente necesito medir que tantas funcionalidades he completado en un periodo de tiempo? O es más importante saber ¿Qué tantos impactos positivos he generado en el negocio? Es muy frecuente tener grandes funcionalidades construidas que no se encuentran articuladas entre si y por ende no pueden generar el impacto deseado.

GENERACIÓN DE VALOR DE NEGOCIO Y CLIENTES FELICES 

Todo nuestro esfuerzo solo tiene sentido cuando logramos un impacto positivo sobre las personas y/o el negocio. Y esto no lo determina el nivel de productividad individual o del equipo, ni el haber cumplido todos los compromisos establecidos durante un periodo de tiempo, ni los bellos gráficos indicadores de Bugs por funcionalidades que ponen en evidencia cuan mal programadores podemos ser, ni mucho menos la cantidad de funcionalidades completadas en el tiempo.

Existen 3 métricas que pueden ser muy útiles y nos pueden ayudar a medir cuan eficientes somos al entregar valor. 

Cycle time (CT)

Es el tiempo total transcurrido para mover una unidad de trabajo desde el comienzo hasta el final de un proceso. Llevándolo a un proceso de desarrollo de software SCRUM, se trata del tiempo transcurrido desde que una historia de usuario es priorizada por el equipo hasta que se transforma en una unidad de software funcional e incluye el esfuerzo real realizado por las personas más los tiempos de delay que puedan retrasar la construcción tales como dependencias con otros procesos.

Pero… ¿Tener una funcionalidad completada genera impacto sobre el negocio?.

Lead time (LT)

Es el tiempo total transcurrido desde que el cliente realiza la solicitud hasta que se le entrega un producto terminado. 

¿Una funcionalidad de software es un producto terminado?, ¿La única forma de entregar un producto terminado es completar todas las funcionalidades que se solicitan?. 

Observen el siguiente escenario.

Un teatro desea ampliar su canal de ventas y ofrecer a los usuarios la posibilidad de comprar boletos de cine por Internet (Ese es su objetivo final de negocio). Después de realizar el análisis encontramos que se pueden generar varios impactos adicionales antes de tener el canal de Internet plenamente habilitado: 

Pequeños impactos de negocio	Funcionalidades
Permitir a los usuarios consultar la cartelera de películas disponibles y sus horarios.	Realizar el registro de las películas en cartelera Consultar las películas en cartelera …
Permitir a los usuarios ver la disponibilidad de asientos en cada película para que no pierdan el desplazamiento hasta el teatro si no hay disponibilidad.	Consultar La cantidad de asientos disponibles Mostrar la imagen del teatro y marcar los asientos ocupados en otro color. …
Permitir a los usuarios realizar la reserva de los asientos por Internet y que el pago lo hagan en la taquilla.	Permitir a los usuarios seleccionar una silla disponible y realizar el registro de la reserva. Validar que el tiempo que falta para iniciar la película sea menor a 2 horas. Si el cliente es VIP se le permite reservar sillas preferenciales. …
Permitir a los usuarios pagar con tarjetas débito por Internet	…
Permitir a los usuarios pagar con tarjetas de crédito por Internet.	…
Permitir a los usuarios cancelar las reservas por Internet.	…

Como lo vemos en el ejemplo anterior, en realidad podemos generar muchos pequeños impactos frecuentemente que empiecen satisfacer las necesidades del cliente. 

Funcionalidad no es igual a impacto 

Lo que veo hoy en la realidad diaria de los proyectos es que nos quedamos observando los gráficos de velocidad y decimos que vamos bien. El product owner se limita a priorizar funcionalidades en el backlog que muchas veces apuntan a objetivos diferentes y por ende el tiempo total de generación de valor al cliente es muy alto. Trabajamos en muchas funcionalidades con una velocidad y productividad muy buena como equipo, pero aún no logramos entregar valor a ese mismo ritmo.

Por supuesto que es importante mantener unos buenos niveles de productividad (Velocidad), esto demuestra la madurez del equipo en el tiempo, pero me parece más importante que como equipo nos empecemos a sensibilizar mas respecto a lo que debemos lograr y no tanto a lo que hay que hacer. WORK SMARTER NOT HARDER. Solo cuando logramos un pequeño impacto que pueda ser usado en condiciones reales por el negocio en producción recibimos un verdadero feedback y justo ahí empezamos a mejorar el producto. Las review en ambientes de prueba normalmente revisan que el software satisfaga los criterios de aceptación, pero ¿Acaso el product owner tiene la capacidad de pensar en los cientos de escenarios bajo los cuales se mueve un negocio en su realidad diaria?

Process efficiency

Finalmente podríamos utilizar un tercer indicador que nos permita conocer cuan eficientes somos a la hora de entregar valor. Esta eficiencia se puede analizar desde dos ángulos.

• Eficiencia del proceso de construcción (EC): Ya mencionamos que el cycle time (CT) nos permite conocer nuestra capacidad como equipo para construir funcionalidades pero este tiempo se ve afectado por dos factores.

Value Added Time (VAT): Es el tiempo invertido realmente por el equipo en actividades que aportan valor a la funcionalidad que está siendo construida. Es importante aclarar que el entrenamiento y slack time disponible para que el equipo mejore continuamente hace parte de las actividades que generan valor.

Non value Added Time (NAT): Es el tiempo muerto en el que el equipo no puede construir por dependencias con otros procesos o por cualquier serie de impedimentos que pueda tener.

La eficiencia del proceso de construcción es entonces EC= VAT/CT.

Ejemplo: Si soy capaz de construir 10 historias de usuario en 40 Horas o 1 sprint (Cycle time) y el esfuerzo invertido realmente en construcción fue de 30Horas (Value added time), estando las 10 horas restantes involucradas en actividades de gestión, llamadas, solicitudes para conseguir insumos (Non value added time), etc, la eficiencia de mi proceso de construcción es

EC=30/40= 75%

• Eficiencia de generación de valor (EV): ¿Qué tan eficientes somos para que lo que construimos impacte en el negocio o las personas? EV=CT/LT

Sprints 1 semana (40 Horas)	Escenario 1	Escenario 2
Sprint 1	Realizar el registro de las películas en cartelera	Realizar el registro de las películas en cartelera
Sprint 2	Validar que el tiempo que falta para iniciar la película sea menor a 2 horas.	Consultar las películas en cartelera
Sprint 3	Consultar La cantidad de asientos disponibles	IMPACTO: Permitir a los usuarios consultar la cartelera de películas disponibles y sus horarios.
Sprint 4	Consultar las películas en cartelera	Cycle time = 2 Sprints= 80 Horas Lead time = 2 Sprints = 80 Horas + (Tiempo de salida a producción) EV= 80/80= 100% (Podría ser menos si el proceso de salida a producción tarda mucho)
	IMPACTO: Permitir a los usuarios consultar la cartelera de películas disponibles y sus horarios.	…..
	Cycle time = 2 Sprints= 80 Horas Lead time = 4 Sprints = 160 Horas + (Tiempo de salida a producción) EV= 80/160= 50% (Podría ser menos si el proceso de salida a producción tarda mucho)	…..

Mientras más cerca esté el lead time del cycle time más eficiente será nuestro proceso.

No sé a ciencia cierta cómo medir la felicidad de los clientes (No he tenido dinero para comprar el felizómetro) pero si estoy seguro de que la ansiedad será menor cuando entregamos, pues las personas empiezan a ver el resultado de su inversión y muy probablemente esto los haga felices o la menos los tenga tranquilos.

Análisis de información en memoria RAM

Este es un resumen de una de las charlas a las que asistí en el Oracle OTN Tour Latino américa 2013. Su titulo: "Del Big Data a los analíticos en memoria".

En el mundo solo el 20% de la información es estructurada (Existente en tablas de bases de datos o estructuras controladas por las aplicaciones), y el 80% es no estructurada (Producto de redes sociales, google, correo electrónico, etc). De esta información no estructurada el 80% es texto, los datos pueden no ser confiables y se dispone de grandes volumenes (Terabytes, o Petabytes). A esto se le conoce como Big data.

Tradicionalmente para análisis de grandes cantidades de datos se hace uso de data ware houses que son alimentados por procesos ETL para su posterior procesamiento con herramientas de inteligencia de negocio. El problema con este enfoque es que no se da en tiempo real, muchas veces toma días e incluso semanas para entregar indicadores que apoyen la toma de decisión de las empresas. Hoy se habla de Analíticos en memoria que entregan información casi en tiempo real (Procesar en RAM es 50.000 veces mas rápido que hacerlo en disco). Todo esto es posible porque en la actualidad el costo de la memoria es considerablemente menor. Un módulo cuesta 25 veces menos que en el pasado y tiene 64 veces mas capacidad.

El siguiente es un proceso de análisis de negocio con procesamiento de Big Data en memoria:

• Adquirir: Conseguir los datos que van a ser objetos de análisis a partir de diferentes fuentes de información tanto estructurada como no estructurada. Normalmente los datos son almacenados en bases de datos no relacionales y bases de datos en memoria.

• Organizar: Su objetivo es convertir toda esta información en datos estructurados que puedan ser sujetos a análisis (Bases de datos relacionales, cubos, etc).

• Analizar: Se analiza la información organizada previamente y se generan indicadores para el negocio.

• Decidir: Las personas del negocio toman decisiones con base en los indicadores generados.

El proceso se ejecuta continuamente, generando indicadores en tiempo real que permitan a los gerentes actuar de manera pro-activa a través de una mejor toma de decisiones.

Imaginen la posibilidad de publicar una oferta de mercadeo y conocer en tiempo real lo que las personas están diciendo sobre el producto en facebook o twitter. Esto es posible con análisis de datos en memoria, el enfoque tradicional tal vez nos permita conocer la información un día después cuando sea demasiado tarde y no podemos hacer nada para salvar la campaña publicitaria.

¿Y que hago como profesional de TI?. R//. Estrategia de TI de colombia.

El pasado viernes asistí a un evento en el que el ministerio de TICs tuvo presencia y habló de la estrategia de TI del país en el mediano y largo plazo.

Sus pilares son:

• Prosperidad
• Buen gobierno
• Innovación y emprendimiento
• Talento y participación

Me llamó mucho la atención que dentro del buen gobierno se busca fortalecer el uso de TI en los sectores públicos coordinando y articulando los sistemas de información de cada sector a través de un marco de referencia para que las entidades públicas trabajen con tecnología  Todo esto plantean lograrlo principalmente a través de la definición de una arquitectura empresarial para el estado colombiano sustentada en los siguientes pilares:

• Definición de políticas y lineamientos en temas de contratación.
• Liderazgo para la implementación. A través del establecimiento de CIOs que apalanquen la estrategia de TI del gobierno.
• Modelo de gestión de TI.
• Modelo de seguimiento y monitoreo de la gestión de TI. A través de la definición de indicadores que permitan revisar el avance en adopción tecnológica por parte de la entidades.
• Optimización de la inversión en TI que hacen los entes de gobierno..

Es triste el hecho de que Colombia realmente no cuenta con el suficiente capital intelectual para llevar a cabo este plan y por ello el gobierno recurre a empresas extranjeras para que apoyen el proceso pero es interesante porque el área de arquitectura empresarial cobrará aún mas relevancia de la que tiene actualmente pues las oportunidades principalmente con el gobierno son inmensas dada la creciente necesidad de alinear las estrategias de negocio con soluciones tecnológicas que apalanquen los objetivos estratégicos de las organizaciones .

Actualmente el estado esta buscando formar personas como CIO con las siguientes habilidades:

• Habilidades gerenciales
• Habilidades técnicas
• Iniciativa propia
• Conocimiento del sector publico
• Nivel de estudio: Maestría
• Fundamentos jurídicos

Por esta razón los siguientes temas lucen atractivos si quisiéramos orientar nuestro futuro profesional hacia este mundo.

• Certificaciones en frameworks de arquitectura empresarial como TOGAF, OEAF, FEAF
• Maestrías en administración.
• Certificaciones técnicas como Oracle Certified Master, Java EE Enterprise Architect.

Análisis de escalabilidad de Drools

Hace poco estuve revisando con un equipo de trabajo la posibilidad de usar tablas de decisión de Drools Expert para la implementación de un componente de homologación de datos. La cantidad de registros a homologar era bastante grande (Aproximadamente 21.000) y en un futuro cercano podría crecer (Aproximadamente a 112.000 o incluso mas).

Nos cuestionaba principalmente la escalabilidad de la solución y por esta razón hicimos un perfilado de la memoria consumida por Drools ante diferentes escenarios de carga. Los resultados se encuentran en el siguiente archivo adjunto Análisis de consumo de memoria de Drools..

La conclusión a la que llegamos es que la herramienta no es la mas adecuada para este tipo de implementaciones pues el consumo de memoria aumenta exponencialmente conforme aumentan la cantidad de reglas de negocio a compilar (1 regla por cada fila en la tabla de decisión de Drools).

El control es tan solo una inutil ilusión

El día de ayer mi hijo me dio una lección de vida que ratificó mi idea respecto a que el control es simplemente un estado mental que le da al ser humano la falsa tranquilidad de garantizar el statu quo.

Cada día es un problema lograr que jerónimo termine toda su comida. En esta ocasión no fue diferente y después de estar sentado en la mesa con el durante mas de 2 horas mi paciencia se agotó y recurrí a lo que era la única herramienta de la que disponía para manejar la situación: "Le grité". En efecto el grito funcionó y logré el objetivo. Días después el se enfrentó a una situación similar con su madre. Ella le impuso algo con lo que el no estaba de acuerdo y su reacción fue gritarle.

Los seres humanos somos resultado del ambiente en el que vivimos y de forma inconsciente las herramientas que utilizamos para manejar las diferentes situaciones a las que nos enfrentamos son las mismas que han utilizado las personas con las que interactuamos.

Tal vez esta sea la razón por la cual en el mundo existe una preponderante inclinación a tratar de controlarlo todo: Un padre trata de controlar a su hijo imponiendo ciertas acciones orientadas a formar su carácter, un jefe impone a sus empleados algunas cosas orientadas a que su empresa no se salga de control, el novio cree que prohibiendo a su pareja salir con amigos hombres controlaría el hecho de que esta no le sea infiel. Pero la verdad es que nada de esto está garantizado.

Los seres humanos somos entidades tan complejas que nuestro actuar se ve determinado por millones de posibles combinaciones de variables que ningún otro ser humano es capaz de comprender y mucho menos controlar y estas variables pueden verse afectadas por infinidad de factores externos lo cual hace prácticamente imposible que ante una acción se tenga un resultado predecible.

Ahora, si controlar una persona es una meta difícilmente alcanzable ¿Que habría de esperarse del intento de controlar un grupo de ellas?. Sumen la complejidad de cada individuo que a su vez se ve afectada por la interacción con los otros miembros del grupo y obtendrán un ente mucho mas complejo que la persona misma. ¿Realmente es posible controlar esto?

Por su naturaleza los seres humanos, los grupos y en general la sociedad se encuentra dentro de un tipo de sistema bastante curioso llamado "Adaptativo complejo". Un sistema adaptativo complejo es una red en la que interactuan muchos agentes y que a su vez reacionan al comportamiento de otros para actuar o interactuar con el medio y adaptarse a este. Estos tienen una característica particular y es que son difícilmente controlables por entes externos pues ante estímulos del exterior simplemente se reorganizan y generan resultados impredecibles. Por esta razón las personas y los equipos pueden influenciarse mas no controlarse.

Un organismo vivo se caracteriza por un flujo y un cambio continuos en su metabolismo, comprendiendo miles de reacciones químicas. El equilibrio químico y térmico se da únicamente cuando estos procesos se detienen. En otras palabras, un organismo en equilibrio es un organismo muerto. Los organismos vivos se mantienen constantemente en un estado alejado del equilibrio, en el estado de vida. Siendo muy distinto del equilibrio, este estado es, sin embargo, estable a lo largo de períodos prolongados de tiempo, lo que significa que, como un remolino, se mantiene la misma estructura general a pesar del incesante flujo y cambio de componentes

Tomado de ONCOLOGÍA, CAOS Y SISTEMAS ADAPTATIVOS COMPLEJOS

Durante mucho tiempo el esquema de liderazgo estaba orientado a una persona que tenía una visión de meta clara y que también conocía el como llegar a esta meta asignando a las personas actividades que debían completar sin objeción alguna. Haciendo del líder una figura casi divina incapaz de equivocarse y con habilidades sobre humanas para sacar toda situación adelante.

Hoy los estilos de gerencia han cambiado radicalmente y ya no es el líder aquella figura que está por encima de sus subalternos sino quien está debajo de ellos sirviendo de soporte y entregando todo lo que sus colaboradores necesiten para alcanzar el objetivo (Liderazgo servil). La labor del líder hoy no se centra en dar instrucciones, se enfoca en transmitir una visión clara e inspiradora y de motivar y alinear a las personas para que lleguen allí a partir del camino que ellos consideren adecuado (Obviamente dentro de un rango de acción limitado). Cada jugador de football sabe que su meta es anotar un gol y el técnico no le indica cuando patear y en que momento ir de un lado a otro del campo pero si le deja claro que los goles realizados por fuera del área delimitada de la cancha no son válidos. 

Tratar de supeditar las personas a hacer cosas que alguien mas considera adecuadas puede funcionar y mas aún si se combina con las dosis adecuadas de miedo, otra herramienta tradicionalmente usada y con la que nuevamente se genera una ilusión de control. Pero el miedo es el peor enemigo de la creatividad y tal vez con este esquema se logre lo necesario mas no se conseguirá lo mejor y mucho menos lo imposible pues mas allá del poder individual prevalece el poder del grupo, del equipo, de las masas y con seguridad existirán infinidad de alternativas mucho mejores que las que plantea un iluso y controlador líder.

Daniel pink afirma que los seres humanos nos vemos motivados principalmente por tres factores:

• La competencia en la tarea, que se adquiere mediante el domino de la misma.

• La autonomía. El poder auto organizarnos.

• La intención, la sensación de sentir que aquello que hacemos tiene sentido mas allá de la tarea misma.

Una persona controladora tiende a dar instrucciones claras y precisas sobre las tareas que deben realizarse y no le da la oportunidad a quien ejecuta de encontrar el "¿por que?" esa tarea es importante. De esta manera limita la capacidad de mejorar sus habilidades y encontrar nuevas y mejores formas de hacer las cosas. El hecho de interferir con instrucciones sobre el como, claramente le quita autonomía y por ultimo al enfocar a las personas a la tarea quitan de ellos su visión de meta y no pueden visualizar esa gran catedral que están construyendo tras la tarea de pegar un ladrillo.

Dime y tal vez escuche, enséñame y tal vez aprenda, hazme parte y lo haré.

-----------------------------------------------------------------

Hijo: Cada día es un reto fascinante pues junto con tu madre tenemos la misión de orientarte a ser lo que consideramos es un buen ser humano, capaz de tomar sus propias decisiones, de afrontar sus consecuencias y de ser feliz sin importar lo complejo de las situaciones que debas afrontar a diario. Gran dilema pues queremos que te conviertas en lo que aún no somos.

Solo te prometo que cada día trabajaremos incansablemente por sembrar en ti esa visión, porque estés convencido de que es un buen fin y que trataremos siempre de no decirte como llegar allí  Cuando lo requieras estaremos ahí y actuaremos como mentores pero jamás trataremos de imponerte nuestra posición ni nuestra vieja y obsoleta forma de hacer las cosas. Quiero que te conviertas en un ser creativo capaz de afrontar los retos de la vida de forma innovadora y no contaminado por el miedo.

Nuestro objetivo en la vida será mostrarte a través del ejemplo y de tus propias vivencias el "¿por que?" de cada cosa que hagamos contigo y afecte tu visión de la vida.

Soy consciente que nuestros actos solo te influenciarán de manera positiva o negativa, pero también lo soy de que todos los días podremos experimentar nuevas formas de hacer las cosas y aprender a partir de las consecuencias que tanto nuestra influencia como la del ambiente en el que te desenvuelves cause en ti.

Un típico tradeoff de arquitectura

Introducción

¿Alguna vez han necesitado tener dos instancias de una clase que se relacionan entre si en un contexto de negocio y las siguientes premisas para la realización del diseño: Baja complejidad de implementación, mínimo impacto en el código existente, mantenible en el tiempo lo que incluye fácil localización de los segmentos de código que tienen bugs, escalable y buen desempeño?.

Este fue el escenario que nos planteó tal reto de diseño: La arquitectura de referencia definía la ejecución de un proceso de negocio como una serie de pasos no relacionados entre sí (Lector - Completador - Validador). Todos ellos serían orquestados por un ente externo. El proceso consistía en Leer información de archivos Txt, completar la información leída con elementos de la base de datos de la compañía (Esta sería la información real de las entidades de dominio), y validar la información de modo que se pudiera continuar con un proceso de negocio subsiguiente o parar el procesamiento. Las validaciones deberían en algunos casos comparar los valores leídos con los valores completados. El problema radicaba en el hecho de tener un componente inicial (El lector) que leyera la información y un componente intermedio (El completador) que podría reemplazar la información ya leída. En este caso al componente validador solo le llegaría la información completada y no tendría forma de comparar con la información leída. A continuación una imagen que ilustra lo descrito.

Para dar solución a esta problemática se plantearon las siguientes alternativas de diseño:

Diseño 1. Replicar datos en el modelo de dominio

Normalmente cuando tenemos deficiencias en el diseño lo primero que hacemos es empezar a replicar atributos en los objetos de negocio o a utilizar las estructuras que ya tenemos al amaño del proceso de negocio puntual y no como referencia del negocio real.

Ventajas

1. Escalable porque usa menos instancias de objetos en comparación a las siguientes soluciones
2. Baja complejidad de implementación
3. Se requiere pocas líneas de código para su implementación
4. Al existir menor cantidad de objetos habrá menor uso del Garbage collector lo que beneficia en menor medida el desempeño.

Desventajas

1. No es mantenible.
2. Poco flexible.

En la imagen anterior vemos como se adiciona un nuevo atributo llamado "numeroCompletado" cuyo objetivo es que el completador coloque el número cargado de la base de datos y no reemplace el que puso el lector. De esta manera el validador podrá comparar estos dos valores de forma fácil.

El problema con este enfoque es que conforme avance la implementación, el modelo de dominio va a tener cada vez mas adaptaciones puntuales a cada proceso de negocio hasta volverse insostenible.

Diseño 2. Repositorio común a todos los componentes

La siguiente aproximación de diseño planteó tener un espacio de memoria que fuese accesible por todos los componentes (Lector - Completador - Validador), de esta manera cuando el lector reemplazase valores en los objetos de negocio, el validador podría acceder al repositorio y obtener el objeto que originalmente fue leído

Ventajas

1. Incrementa la flexibilidad porque la complejidad del modelo de dominio no aumenta a medida que se implementan nuevos procesos de negocio.
2. Es mas flexible que la opción 1.

Desventajas

1. Es menos escalable porque se crean replicas de los objetos de dominio en el repositorio para hacer la comparación.
2. La complejidad de implementación es media.
3. Se requiere mayor cantidad de líneas de código para su implementación.
4. Impacta minimamente el desempeño porque hay un poco mas de actividad en el garbage collector.
5. Disminuye la mantenibilidad por tener un scope de datos a nivel de todo el proceso de negocio. Dado que todos los componente pueden alterar el estado de los datos en el repositorio tomaría mas tiempo hacer seguimiento cuando se tengan problemas.

Diseño 3. Basado en memento

Esta estrategia se basa en la filosofía del patrón de GOF Memento en el que se puede devolver un objeto a estados previos. Nuestra aproximación solo permite devolverse un estado hacia atrás. El diseño es el siguiente y no entro en mas detalles dada su simplicidad.

Ventajas

1. Las mismas ventajas que en la opción 2.
2. Baja complejidad de implementación
3. Se requieren pocas líneas de código para su implementación.

Desventajas

1. Modifica el modelo de dominio por lo que se hace un poco mas difícil de mantener pero tiene una ventaja respecto a la aproximación inicial dado que esta modificación se hace de forma estándard y no descontrolada como sería el adicionar a tributos de proceso según la necesidad.

Diseño 4. Patrón observador

Se trata de una mejora al diseño planteado en la opción 2 dado que se tendrá un repositorio de datos local al componente que lo requiere  (El Validador) y existirá solo un ente en capacidad de modificar sus datos (El Completador). Esto hará que el seguimiento a los errores esté mucho mas localizado con las ventajas propias del diseño 2.

Ventajas

1. Las mismas que en la opción 2.
2. Se requieren pocas líneas de código para su implementación.
3. Aumenta la mantenibilidad por tener un repositorio con un scope mas reducido.

Desventajas

1. El mismo issue de escalabilidad de la opción 2 porque se crean replicas de los objetos de dominio en el repositorio local.
2. Impacta minimamente el desempeño porque hay un poco mas de actividad en el garbage collector.
3. Alta complejidad de implementación

A continuación un diseño estructural de lo que plantea la solución.

El siguiente es un diagrama dinámico que describe la forma se articula en ejecución

En pocas palabras el diseño plantea lo siguiente: El orquestador se asegura de crear solo una instancia del validador que implementa Observer (Lo cual lo convierte en un objeto observador) y lo asigna a través de ObserverSetter quien tiene una característica especial. Todos los objetos que se almacenen en este vivirán durante la ejecución del hilo (Ver Thread Local).

Los objetos de negocio extenderán de la clase BaseBo la cual a su vez extiende de Observable (Esto hace que los Bo sean susceptibles a ser Observados por otro ente). En el constructor de BaseBo se asignará el Observador del objeto de negocio obteniendo la referencia de ObserverSetter. Es decir, cada vez que se instancie un Bo este se asignará automáticamente al validador como observador de su estado.

Todo lo anterior habilita la aplicación para que cada vez que se haga un cambio sobre el estado de un Bo se notifique al objeto Observer (El validador). Cuando se realice la notificación al validador este internamente guardará el estado anterior del objeto y en el momento que se realice la ejecución de las validaciones podrá obtener para cada objeto de negocio el estado previo.

Conclusiones

Finalmente la alternativa de diseño seleccionada fué la 4 dado que por sus características cumple con lo siguiente: Requiere pocas líneas de código lo cual hace que se tenga un menor impacto en el código construido, la complejidad de implementación es alta por los skills en patrones de diseño mas nó por el código en sí mismo y esto se compensa con la mentoria del arquitecto, es mantenible en el tiempo porque los componentes que afectan el repositorio de datos es limitado y localizado, aunque es menos escalable que otras aproximaciones se asume el impacto y se compensa a través del incremento de memoria RAM en el servidor y el impacto en desempeño es mínimo dado que todo se hace en memoria.

Me gustaría tener su retroalimentación al respecto. Aunque es un diseño que satisface ciertas características siempre existirán opciones alternativas que puede ser mucho mejores.